#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 ryandesign@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/34603#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS