#34603: ace: use the right compiler and -arch flags -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: lockhart@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Keywords: | Port: ace -------------------------------------+-------------------------------------- Comment(by lockhart@…): Replying to [comment:4 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. -- Ticket URL: <https://trac.macports.org/ticket/34603#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS