Update apple-gcc42 to rev 5564 and include c++ support

[illogical1@…]

The apple-gcc42 Portfile has two problems which this ticket hopes to address. The first is that, by default it does not create a c++ compiler and is thus unable to create c++ code. This in turn affects projects which require at least version 4.2 of apple's gcc to compile (like various parts of KDE 4).

The second problem is that 5531 the version currently being used craps on itself when it hits some inline-asm code. This happens w/ the boost headers when compiling kdepimlibs. There might also be problems with multimedia programs such as mplayer/ffmpeg/xine. 5563, released june 2008, reportedly fixes these problems. I'll actually check and confirm this later on.

[illogical1@…]

Modified Portfile which builds apple-gcc42 with c++ support

[illogical1@…]

The Portfile will need to be modified for the correct ${prefix} directory and Documentation location to fit in properly w/ the macports environment. A reinplace line can fix the docs problem. I'm not so good w/ sed though. I, myself, wanted it to integrate w/ Xcode 2.5 on 10.4 so that's why I built it this way.

[illogical1@…]

Cc Me!

[mf2k (Frank Schima)]

Assigning to maintainer.

[illogical1@…]

I can now confirm that apple-gcc42 rev 5564 (not 5563) fixes the bug experienced when compiling inline-asm code. As stated before the older apple-gcc42 (rev 5551?) which is currently in macports has problems with this type of code.

[illogic-al@…]

ping?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[raimue (Rainer Müller)]

Cc Me!

[jjstickel@…]

Cc Me!

[andrea.bedini@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Obviously we can't have a port installing a compiler to /usr so that will have to be fixed before this can be accepted. There seem to also be a number of other to-dos mentioned in the new portfile's comments.

[illogic-al@…]

I was young and inexperienced back in the day and was hoping the maintainer take care of those issues or at least discuss how to do it "the right way". But here's a fixed version which should be suitable IMO. I suppose the final part left, if this is ok, is to create a file that gcc_select can use to make the correct symlinks.

[jm@…]

I am compiling and trying Portfile.2 and will report back.

[ryandesign (Ryan Carsten Schmidt)]

Portfile.2 expressed as a diff against the current Portfile

[ryandesign (Ryan Carsten Schmidt)]

I attached apple-gcc42.diff​ which is Portfile.2​ expressed as a diff against the current Portfile, so we can see what changed.

I'm confused by the line "set prefix ${prefix}"; that seems to be a no-op.

I'm concerned about the lines "destroot {}" and "destroot.violate_mtree yes". Why does the port now have no destroot? Where do the files install, and is that a change from the previous version of the port?

[illogic-al@…]

The destroot phase doesn't do anything because everything is specified in the build command. Documentation is installed to the xcode /Developer directory.

[ryandesign (Ryan Carsten Schmidt)]

It sounds like this new port is ignoring the destroot completely. Does "port uninstall apple-gcc42" correctly remove all parts that were installed by "port install apple-gcc42"? It sounds like it won't, which would be a problem, and the reason why we have the destroot and why it must be used.

[illogic-al@…]

Can't log in to the website using my "normal" user account in safari. It's showing some python error after i log in. So I can't overwrite the original Portfile with the new one I'm about to attach.

[illogic-al@…]

New apple-gcc42 Portfile

[illogic-al@…]

Yes this new port is ignoring the destroot, but not completely. Check out the new port, I don't see why uninstallation wouldn't work properly.

[ryandesign (Ryan Carsten Schmidt)]

It's hard to get a diff between the current Portfile and your Portfile.3​ because you've changed changed a lot of the whitespace. Let's leave the whitespace the way the maintainer has it, or you can file another ticket if you'd like the maintainer to consider reformatting the whitespace.

In Portfile.3 you've added this:

pre-activate {
    system "mkdir -p ${destroot}${prefix}"
    system "mv -f ${destroot}${build_prefix}/* ${destroot}${prefix}"
    system "rmdir ${destroot}${build_prefix}"
}

I'm not sure how that can work, since by the time the pre-activate code is run, everything from the destroot has already been installed into its final destination in ${prefix}/var/macports/software/${name}/... It might work if you change "pre-activate" to "destroot". Though you don't need to use "system" for any of these tasks, I think.

I had not seen before that the build.cmd includes a reference to the destroot location, so maybe that is enough for the files to get to the right place. I'll try it.

There are just a lot of changes in the portfile. Were there a lot of changes upstream between 5531 and 5564 that made this necessary?

[illogic-al@…]

I had it as a post-destroot step before. I can change it back and see what happens. The whitespace is already changed so there's not much I can do about that. If you know how to do it without system then feel free to change it. I'm only familiar with the normal filesystem commands.

I have no idea what the changes upstream were made. All I know is bugs were fixed and 5564 works better (as in, at all).

[illogic-al@…]

Final portfile. Compiles apple gcc4.2 with c++ and objc++ compiler.

[jm@…]

I could compile and install Porfile.4 without problem.

[jm@…]

How can we ask configure.compiler to use the apple-gcc42 compiler?

[ryandesign (Ryan Carsten Schmidt)]

Replying to jm@…:

How can we ask configure.compiler to use the apple-gcc42 compiler?

It appears that an option for that has not yet been added to MacPorts. I filed #18426 for this request and will commit a fix in a moment, but you should not use it in a Portfile until MacPorts 1.7.1 is released. Until then, manually do what setting configure.compiler does -- set configure.cc, configure.cxx etc. as needed.

[illogic-al@…]

Replying to ryandesign@…:

Replying to jm@…:

How can we ask configure.compiler to use the apple-gcc42 compiler?

It appears that an option for that has not yet been added to MacPorts. I filed #18426 for this request and will commit a fix in a moment, but you should not use it in a Portfile until MacPorts 1.7.1 is released. Until then, manually do what setting configure.compiler does -- set configure.cc, configure.cxx etc. as needed.

The portfile creates gcc, g++, cc and c++ executables. No apple- pre/postfix is added on and I don't know how that would be done.

[ryandesign (Ryan Carsten Schmidt)]

build log of Portfile.4 on Leopard on Intel with all four archs enabled

[ryandesign (Ryan Carsten Schmidt)]

patch to improve livecheck to tell us what new version number is available

[ryandesign (Ryan Carsten Schmidt)]

patch to update the port to version 5566

[ryandesign (Ryan Carsten Schmidt)]

patch to enable C++ support

[ryandesign (Ryan Carsten Schmidt)]

Replying to illogic-al@…:

I have no idea what the changes upstream were made. All I know is bugs were fixed and 5564 works better (as in, at all).

What I was trying to figure out was why your proposed portfile changes the entire port -- changes how it builds, makes it build universal all the time, causes it to violate the mtree, no longer appends the customary suffix to the binaries -- when your original request was simply to enable C++ support and to update to a newer version.

I think the universal support you've added is what's causing the port to fail to build for me. I'm on Leopard on Intel but my universal_archs contains all four architectures (i386 ppc x86_64 ppc64), and with your Portfile.3​ and Portfile.4​ I get the message:

/mp/var/macports/build/_Users_rschmidt_macports_dports_lang_apple-gcc42/work/gcc_42-5564/obj-i686-ppc64/./gcc/as: line 2: exec: ppc64: not found

The full log is attached​.

We should keep in mind that this is not our port. Although the maintainer has not responded to this issue within the prescribed 72 hour period, we should not take this to mean that we can completely rearrange his port.

I would like to scale back and make just a few precise changes to the portfile, for which I'm attaching patches:

1. Change the livecheck​ to more reliably tell us when the version is out of date.
2. Update the version to 5566​ which seems to be the latest now.
3. Enable the C++ and Objective C++ languages​.

Do these meet your needs? I would be comfortable committing patches 1 and 2. Patch 3 I'm not comfortable committing without input from the maintainer, because the portfile contains a note that enabling C++ causes the build to fail, which I was not able to reproduce. So I would first like to know under which circumstances or on what machines Marcus observed the build to fail with C++ before we go enabling it.

[illogic-al@…]

Without c++ support this port is useless for us. If ppc64 fails then i can just change the line back to "i386 ppc". It's a compiler so it should be able to compile for at least those two archs. I might as well just submit it under a different name then in the interest of time.

[illogic-al@…]

Replying to ryandesign@…:

Replying to illogic-al@…:

I have no idea what the changes upstream were made. All I know is bugs were fixed and 5564 works better (as in, at all).

What I was trying to figure out was why your proposed portfile changes the entire port -- changes how it builds, makes it build universal all the time, causes it to violate the mtree, no longer appends the customary suffix to the binaries -- when your original request was simply to enable C++ support and to update to a newer version.

Because as it states in the portfile, it won't work (for whatever reason). Whatever apple's doing

I think the universal support you've added is what's causing the port to fail to build for me. I'm on Leopard on Intel but my universal_archs contains all four architectures (i386 ppc x86_64 ppc64), and with your Portfile.3​ and Portfile.4​ I get the message:

This is not universal support, it is building a compiler which is capable of compiling universal code. It creates an x86 code compiler and a ppc code compiler (for me as those are the only universal archs I have set). As I said above I can just change it back to be "i386 and ppc" which would be better than the current option of nothing on 10.4

/mp/var/macports/build/_Users_rschmidt_macports_dports_lang_apple-gcc42/work/gcc_42-5564/obj-i686-ppc64/./gcc/as: line 2: exec: ppc64: not found

The full log is attached​.

I added x86_64 and ppc64 to my universal section in macports.conf so I'll check this out.

We should keep in mind that this is not our port. Although the maintainer has not responded to this issue within the prescribed 72 hour period, we should not take this to mean that we can completely rearrange his port.

I would like to scale back and make just a few precise changes to the portfile, for which I'm attaching patches:

1. Change the livecheck​ to more reliably tell us when the version is out of date.

Fine by me.

2. Update the version to 5566​ which seems to be the latest now.

Haven't tested this, why 5566 and not 5564 which we know works?

3. Enable the C++ and Objective C++ languages​.

Did you try this (actively use this compiler) and get it to work (with kde).

Do these meet your needs? I would be comfortable committing patches 1 and 2. Patch 3 I'm not comfortable committing without input from the maintainer, because the portfile contains a note that enabling C++ causes the build to fail, which I was not able to reproduce. So I would first like to know under which circumstances or on what machines Marcus observed the build to fail with C++ before we go enabling it.

See previous comment. Ultimately we'd have to ask jm if it meets his needs. My needs are already met with xcode 3.1 :-)

[jm@…]

KDE4 does not compile under MacOs 10.4 without this patch. Why not commit this patch to SVN quickly and then improve the patch until we get anything in order.

[jm@…]

What configure lines can be used for testing these compilers when building automoc and kde4?

[jm@…]

​http://trac.macports.org/ticket/16666 has too many portfiles. Could there be an update corresponding to the latest discussions, please? thanks.

[jm@…]

There are many differences between illogic-al and Ryan proposales. In illogic-al, you can read "use configure" set to no. I am confused trying to merge all patches.

[jm@…]

Portfile.5 is an attempt to upgrade portfile.4 with regex livecheck and version 5566.

[jm@…]

Portfile.5 fails with the following error:

/opt/local/var/macports/build/_opt_mports_trunk_dports_lang_apple-gcc42/work/gcc_42-5566/src/libiberty/md5.c:237: error: invalid use of void expression
/opt/local/var/macports/build/_opt_mports_trunk_dports_lang_apple-gcc42/work/gcc_42-5566/src/libiberty/md5.c:251: warning: incompatible implicit declaration of built-in function 'bcopy'
make[2]: *** [md5.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [all-target-libiberty] Error 2
make: *** [all] Error 2
+ exit 1

Warning: the following items did not execute (for apple-gcc42): org.macports.activate org.macports.build org.macports.destroot org.macports.install
Error: Status 1 encountered during processing.

[jm@…]

Could someone come out with a suitable solution? Thanks for help.

[(none)]

Milestone Port Bugs deleted

[illogic-al@…]

Fixed by apple-gcc42-devel port and ryan's addition of apple-gcc-4.2 as an option in portconfigure.tcl