ace: use the right compiler and -arch flags

[ryandesign (Ryan Carsten Schmidt)]

ace doesn't ensure it's UsingTheRightCompiler or -arch flags.

[ryandesign (Ryan Carsten Schmidt)]

The universal variant also fails for this reason.

[lockhart (Thomas Lockhart)]

I have already been looking at the univeral variant problem. The ACE (and TAO) build is done in Only One Way using an internal build system. But it does seem to support a configuration variable "buildbits" which I think allows "univeraal" as a value. I have heard that when built outside of the port system this works. But I have not yet been able to reproduce a successful build within the port system. Will continue poking at it.

[lockhart (Thomas Lockhart)]

Replying to ryandesign@…:

ace doesn't ensure it's UsingTheRightCompiler or -arch flags.

ACE (and TAO) use an internal build system which Is The Only Way. Compilers etc can be overridden but would it not be better to use whatever choice is already recommended by the ACE developers? In any case how would I verify that they have chosen the Right One rather than The One They Think Is Best?

[ryandesign (Ryan Carsten Schmidt)]

This build system of theirs isn't specifying any particular compiler though. It's just using "g++" and that's the problem. Here's an example of what ace is running:

g++ -g -m64 -DACE_HAS_CUSTOM_EXPORT_MACROS=0   -I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_devel_ace/ace/work/ACE_wrappers -D__ACE_INLINE__ -I.. -DACE_BUILD_DLL  -c  -o .shobj/Local_Name_Space.o Local_Name_Space.cpp

"g++" could be anything: by default, it's g++-4.0 on Tiger and Leopard, g++-4.2 on Snow Leopard with Xcode 3, and llvm-g++-4.2 with Xcode 4, but the user could have set it to any other value by using "sudo port select gcc". Read the wiki page UsingTheRightCompiler to understand the problem further, and see the section at the end of it for a change you can make to your MacPorts installation to make builds fail in such cases, so that you can spot them, instead of having them proceed.

Note that tao has already been modified to use the right compiler; the same change just needs to be made to ace probably.

The same problem exists for -arch flags, though we don't have a way to detect that automatically. Actually I see in the output that they are using "-m64" which is equivalent on Intel systems to "-arch x86_64", but I'll bet that if the user requested a 32-bit build, by setting build_arch to i386 in their macports.conf file, that ace would still use -m64, which wouldn't be correct then. So either these -m flags need to be removed and replaced with the -arch flags MacPorts is already providing the port with, or if 32-bit builds are not acceptable for ace, then the port needs to so indicate using the supported_archs setting. And in that case perhaps removing the universal variant is the simplest solution for that part of the problem.

[lockhart (Thomas Lockhart)]

Replying to ryandesign@…:

This build system of theirs isn't specifying any particular compiler though. It's just using "g++" and that's the problem...

For lion the ACE (and TAO) build system forces the use of clang++ etc. For other releases it apparently uses whatever is the default as you have noticed (there is an explicit comment to that effect in ACE_wrappers/include/makeinclude/platform_macosx_tiger.GNU but the compiler is overridden to be clang++ in platform_macosx_lion.GNU).

"g++" could be anything: by default, it's g++-4.0 on Tiger and Leopard, g++-4.2 on Snow Leopard with Xcode 3, and llvm-g++-4.2 with Xcode 4, but the user could have set it to any other value by using "sudo port select gcc". Read the wiki page UsingTheRightCompiler to understand the problem further, and see the section at the end of it for a change you can make to your MacPorts installation to make builds fail in such cases, so that you can spot them, instead of having them proceed.

Note that tao has already been modified to use the right compiler; the same change just needs to be made to ace probably.

On lion this does not have an effect; see above.

The same problem exists for -arch flags, though we don't have a way to detect that automatically. Actually I see in the output that they are using "-m64" which is equivalent on Intel systems to "-arch x86_64", but I'll bet that if the user requested a 32-bit build, by setting build_arch to i386 in their macports.conf file, that ace would still use -m64, which wouldn't be correct then. So either these -m flags need to be removed and replaced with the -arch flags MacPorts is already providing the port with, or if 32-bit builds are not acceptable for ace, then the port needs to so indicate using the supported_archs setting. And in that case perhaps removing the universal variant is the simplest solution for that part of the problem.

This seems to be addressed using build options the ACE (and TAO) developers intend to be used to build a universal variant. I am testing a build of ACE using this feature now (initial indications are good; I have some libraries which have two architectures in them). One worry: when specifying +universal the port system constructs two build trees and I'm not sure what port will try to do with the orphan build tree for i386.

[lockhart (Thomas Lockhart)]

Replying to lockhart@…:

Replying to ryandesign@…:

This build system of theirs isn't specifying any particular compiler though. It's just using "g++" and that's the problem...

So to clarify: this is a problem even though that is WhatTheBuildersIntended?

... One worry: when specifying +universal the port system constructs two build trees and I'm not sure what port will try to do with the orphan build tree for i386.

Well, port is not actually orphaning that i386 build tree but is forcing a second build of the entire app in that tree too. This is NotWhatTheDevelopersIntended and makes a slow build twice as slow...

Ooh, that did not go well; the port system apparently tries to slam both trees together and uses libtool to merge libraries, each of which already contains both i386 and x86_64 code. See log snippets below.

Is there any way to get the port build system to keep its hands off the build and not try that goofy merge when doing a universal variant? TheOriginalDevelopersOfACE have the build figured out but port is forcing extra steps which are failing. Maybe another possibility is to get it to do two legit configuration steps so there really is just i386 object code in one tree and x86_64 code in another? I could get that to happen if I can do a separate reinplace substitution for each tree.

DEBUG: universal: merge: merging /opt/local/lib/libACE.dylib from /opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-i386 and /opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-x86_64
/opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-i386//opt/local/lib/libACE.dylib /opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-x86_64//opt/local/lib/libACE.dylib differ: char 23, line 1
Command failed: /usr/bin/cmp "/opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-i386//opt/local/lib/libACE.dylib" "/opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-x86_64//opt/local/lib/libACE.dylib" && /bin/cp -v "/opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-i386//opt/local/lib/libACE.dylib" "/opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-intel//opt/local/lib"
Exit code: 1
/usr/bin/lipo: /opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-i386//opt/local/lib/libACE.dylib and /opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-x86_64//opt/local/lib/libACE.dylib have the same architectures (i386) and can't be in the same fat output file
Command failed: /usr/bin/lipo -create "/opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-i386//opt/local/lib/libACE.dylib" "/opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-x86_64//opt/local/lib/libACE.dylib" -output "/opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-intel//opt/local/lib/libACE.dylib"
Exit code: 1

and

/usr/bin/libtool: file: /opt/local/var/macports/build/_Users_lockhart_ports_devel_ace/ace/work/destroot-i386//opt/local/lib/libACE.dylib is a dynamic library, not added to the static library

[pixilla (Bradley Giesbrecht)]

Ooh, that did not go well; the port system apparently tries to slam both trees together and uses libtool to merge libraries

Tom: Remove "PortGroup muniversal 1.0".

[ryandesign (Ryan Carsten Schmidt)]

Replying to lockhart@…:

Replying to lockhart@…:

Replying to ryandesign@…:

This build system of theirs isn't specifying any particular compiler though. It's just using "g++" and that's the problem...

So to clarify: this is a problem even though that is WhatTheBuildersIntended?

Yes, it's still a problem. The developers of a program often are not aware of the considerations a package management system like MacPorts considers important. Using "g++" when you don't know what that is means different users might get subtly different builds of the software, or might even encounter build failures if they happen to have a completely broken build of a compiler installed. Better to lock that down to a specific known-good compiler, the one identified by the MacPorts variable ${configure.cxx}. These guidelines have come into effect after years of actual users actually encountering this type of problem; following these guidelines should thus end up decreasing the problems users encounter, and thus decreasing the tickets you (and we) have to respond to.

[lockhart (Thomas Lockhart)]

OK, I think I have a good build using your guidance; thanks for babysitting me through it. Will post patches and files to implement +universal and +ssl. Currently testing the same fix ups for TAO.

[lockhart (Thomas Lockhart)]

Complete file to replace current "patch file" to help with configuration.

[lockhart (Thomas Lockhart)]

Patch to enable +universal and +ssl support relative to current svn repo. Similar to previous version posted here but slight cleanup in approach to modifying files to set compilers.

[lockhart (Thomas Lockhart)]

The current portfile sets parameters as requested in this ticket. This issue can be closed.