Opened 19 months ago

Last modified 19 months ago

#65993 new defect

double-conversion fails to build as +universal: g++-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags

Reported by: barracuda156 Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.7.2
Keywords: powerpc, leopard, ppc64 Cc:
Port: double-conversion

Description

g++-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags
make[2]: *** [CMakeFiles/double-conversion.dir/double-conversion/cached-powers.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/usr/bin/g++-4.2 -Ddouble_conversion_EXPORTS -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_double-conversion/double-conversion/work/double-conversion-3.2.1 -pipe -Os -DNDEBUG -I/opt/local/include -arch ppc -arch ppc64 -mmacosx-version-min=10.5 -fPIC -MD -MT CMakeFiles/double-conversion.dir/double-conversion/bignum.cc.o -MF CMakeFiles/double-conversion.dir/double-conversion/bignum.cc.o.d -o CMakeFiles/double-conversion.dir/double-conversion/bignum.cc.o -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_double-conversion/double-conversion/work/double-conversion-3.2.1/double-conversion/bignum.cc
g++-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags
g++-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags
make[2]: *** [CMakeFiles/double-conversion.dir/double-conversion/bignum-dtoa.cc.o] Error 1
make[2]: *** [CMakeFiles/double-conversion.dir/double-conversion/double-to-string.cc.o] Error 1
g++-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags
make[2]: *** [CMakeFiles/double-conversion.dir/double-conversion/bignum.cc.o] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_double-conversion/double-conversion/work/build'
make[1]: *** [CMakeFiles/double-conversion.dir/all] Error 2
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_double-conversion/double-conversion/work/build'
make: *** [all] Error 2

Change History (5)

comment:1 Changed 19 months ago by kencu (Ken)

you have two choices:

  1. strip out the unsupported flags
  2. use the muniversal PG

MacPorts prefers the first, but it’s often much easier to do the second.

comment:2 in reply to:  1 Changed 19 months ago by barracuda156

Replying to kencu:

you have two choices:

  1. strip out the unsupported flags
  2. use the muniversal PG

MacPorts prefers the first, but it’s often much easier to do the second.

By the way, do we have an idea of how to solve a problem of universal builds with new GCCs? It is a pain now. Whenever I touch Leopard, multiple ports break down on universal builds, and building for ppc32 is not inspiring – the only advantage of 10.5 is ppc64.

From what I understood, adding muniversal is not an option (and admittedly, it looks like a silly mechanical work). Can it be implemented in the base – so that whenever +universal is invoked on a system with non-Apple GCC, muniversal is pulled over? If someone ever happens to fix GCC eventually, such implementation will be easier to revert too, rather than removing muniversal from every port.

comment:3 Changed 19 months ago by kencu (Ken)

Apple-style universal builds with gcc versions newer that gcc-4.2 will require someone upgrading driverdriver.c to support new gcc syntax, and then implementing a nice multi-arch gcc build that can use the new driver.

(By the way, that might an absolutely fantastic project for you to take on, would help Iain greatly, and would be very much appreciated by the entire community. You would learn a lot from doing that project, it is entirely do-able, and you would become a gcc-on-Darwin guru in the process.)

comment:4 Changed 19 months ago by kencu (Ken)

IMHO it is very unlikely that the MacPorts admins would ever agree to have base automatically add the muniversal PortGroup if a non-Apple gcc compiler is being used for the build.

There is too much customization required to make it a general default.

comment:5 Changed 19 months ago by kencu (Ken)

I find Leopard quite solid building i386, x86_64, and ppc. All MacOS is shaky on ppc64 as nobody ever built that arch much, so there are many unhandled pathways in software builds that go wrong.

Building universal on Leopard only really works out well for i386/x86_64, as that pathway is well tested on newer systems.

Building universal i386/ppc is disappointing at present as so much software no longer builds with Apple's gcc-4.2, and newer gcc compilers are broken due to no working driverdriver.c or multi-arch gcc builds in MacPorts.

Building universal ppc/ppc64 is OK sometimes, but the ppc64 builds are often broken as above, so they fail.

For maximum happiness, don't build universal. If you simply must build universal, set the universal_archs to either i386/x86_64 or ppc/ppc64.

If you are on an Intel system, you can also set Leopard to use libc++ and that works really well, just like 10.6.8, if you also set the universal_archs to i386/x86_64. But then if your Leopard Intel system can use that, just install 10.6.8 on it instead.

Note: See TracTickets for help on using tickets.