gcc43, gcc44 won't compile with non-default build_arch

[hackdefendr (HackDefendr)]

I've tried and tried and tried .. nothing I do works. GCC 4.2, 4.3, nor 4.4 will build on my Snow Leopard. I have even resorted to starting over, freshly installed Macports 1.8.2. No luck.

I've searched all over the web...not one single educated post about this error. I found a really lazy patch, that did nothing for the Stable branch of Ports.

Attached is the output from: port -v -d install gcc44

checking build system type... i386-apple-darwin10
checking host system type... i386-apple-darwin10
checking target system type... i386-apple-darwin10
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... /usr/bin/gcc-4.2
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /usr/bin/gcc-4.2 accepts -g... yes
checking for /usr/bin/gcc-4.2 option to accept ANSI C... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether /usr/bin/g++-4.2 accepts -g... yes
checking for gnatbind... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... no
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.
Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/build" && ../gcc-4.4.3/configure --prefix=/opt/local --build=i386-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,java,fortran --libdir=/opt/local/lib/gcc44 --includedir=/opt/local/include/gcc44 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --with-system-zlib --disable-nls --program-suffix=-mp-4.4 --with-gxx-include-dir=/opt/local/include/gcc44/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --enable-stage1-checking " returned error 1
DEBUG: Backtrace: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/build" && ../gcc-4.4.3/configure --prefix=/opt/local --build=i386-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,java,fortran --libdir=/opt/local/lib/gcc44 --includedir=/opt/local/include/gcc44 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --with-system-zlib --disable-nls --program-suffix=-mp-4.4 --with-gxx-include-dir=/opt/local/include/gcc44/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --enable-stage1-checking " returned error 1

[hackdefendr (HackDefendr)]

Output from command: port -v -d install gcc44

[hackdefendr (HackDefendr)]

Cc Me!

[jmroot (Joshua Root)]

Please remember to preview and use WikiFormatting and cc the maintainer, and note you do not need to be in cc when you are the reporter.

[jmroot (Joshua Root)]

Works for me. Attach the config.log. What hardware are you on exactly?

[hackdefendr (HackDefendr)]

Replying to jmr@…:

Works for me. Attach the config.log. What hardware are you on exactly?

MacBook Pro 2.33 GHz Core 2 Duo, 3GB 667 MHz DDR2 SDRAM
Snow Leopard 10.6.2
Macports 1.8.2 (Stable)

Config.log claims:

configure:4670: checking for correct version of mpfr.h
configure:4701: /usr/bin/gcc-4.2 -o conftest -O2 -I/opt/local/include -I/opt/local/include -I/opt/local/include -L/opt/local/lib conftest.c  -L/opt/local/lib -L/opt/local/lib -lmpfr -lgmp >&5
ld: warning: in /opt/local/lib/libmpfr.dylib, file is not of required architecture
ld: warning: in /opt/local/lib/libgmp.dylib, file is not of required architecture
Undefined symbols:
  "_mpfr_subnormalize", referenced from:
      _main in ccMdHP6Q.o
  "_mpfr_erfc", referenced from:
      _main in ccMdHP6Q.o
  "_mpfr_atan2", referenced from:
      _main in ccMdHP6Q.o
  "_mpfr_init", referenced from:
      _main in ccMdHP6Q.o
      _main in ccMdHP6Q.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

config.log being attached next ... What I don't get is that I am not doing Universal build, only i386, so there should only be one Arch. Why its complaining about required Arch is way above my head.

[hackdefendr (HackDefendr)]

config.log from command: port -v -d install gcc44

[jmroot (Joshua Root)]

Well, what have you set build_arch to in macports.conf, and what arch are libmpfr.dylib and libgmp.dylib?

[hackdefendr (HackDefendr)]

Both build_arch and universal_archs are solely set to i386. This generation Macbook won't boot 64 bit, never has. I've never built a single 64 bit app in Macports, mainly since my Macbook doesn't boot into 64 bits.

I've explicitly set -universal in my variants.conf .. yet it still complains that GMP/MPFR are of the wrong Architecture. If I have explicitly turned off 64 bit support in Macports, then why is it still trying to build 64 bit?

Is this just going to turn out to be another "it works for me ... something wrong with your computer" deals or can I expect someone to actually take this seriously and try to help?

I may not be a coder, but I am a very technically endowed individual, and definitely not a noob.

[jmroot (Joshua Root)]

I am taking this seriously and trying to help. I am attempting to determine precisely what the problem is. A Core 2 Duo is a 64-bit CPU, and as such your machine can run 64-bit code (and will in fact prefer to do so in 10.6). I asked what arch libmpfr.dylib and libgmp.dylib are in order to determine which port is not applying your chosen build_arch correctly. You can find out with this command:

lipo -info /opt/local/lib/libmpfr.dylib /opt/local/lib/libgmp.dylib

[hackdefendr (HackDefendr)]

Replying to jmr@…:

I am taking this seriously and trying to help. I am attempting to determine precisely what the problem is. A Core 2 Duo is a 64-bit CPU, and as such your machine can run 64-bit code (and will in fact prefer to do so in 10.6). I asked what arch libmpfr.dylib and libgmp.dylib are in order to determine which port is not applying your chosen build_arch correctly. You can find out with this command:

lipo -info /opt/local/lib/libmpfr.dylib /opt/local/lib/libgmp.dylib

I understand my Macbook is technically 64 bit capable .. but Snow Leopard has not, and now I assume will not boot into 64 bit mode for whatever reason. So I just opted to make things simpler for me by turning off Universal builds. Which seemed to work for awhile until I had a need (desire) for something requiring gcc44. Fast forward to right now ...

I am rebuilding GMP/MPFR in steps, to ensure I have full control over the configure arguments used ... When it is done compiling I will run lipo to see what Arch they think they were built as.

[tobypeterson]

It doesn't matter if you're booting K64 or not, that doesn't affect userland.

[hackdefendr (HackDefendr)]

Ok, So I went home and slept, then came back to work to finish these compiles. Below is what lipo reports as the Arch for both GMP and MPFR.

$ lipo -info /opt/local/lib/libmpfr.dylib 
Non-fat file: /opt/local/lib/libmpfr.dylib is architecture: i386

$ lipo -info /opt/local/lib/libgmp.dylib
Non-fat file: /opt/local/lib/libgmp.dylib is architecture: i386

And yet, once again ... Configure Error:

checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... no
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.

Same annoying error in config.log:

ld: warning: in /opt/local/lib/libmpfr.dylib, file is not of required architecture
  "_mpfr_subnormalize", referenced from:
  "_mpfr_erfc", referenced from:
  "_mpfr_atan2", referenced from:
  "_mpfr_init", referenced from:
|     #include <mpfr.h>
|     mpfr_t n;
|     mpfr_t x;
|     mpfr_init (n);
|     mpfr_init (x);
|     mpfr_atan2 (n, n, x, GMP_RNDN);
|     mpfr_erfc (n, x, GMP_RNDN);
|     mpfr_subnormalize (x, t, GMP_RNDN);

[jmroot (Joshua Root)]

OK, so gmp and mpfr are correctly applying your build_arch. This may not be so easy to fix in the gcc ports; you can't just pass '-arch i386' in CFLAGS like normal, since it ends up trying to use those flags with the generated compiler, which doesn't understand -arch (and -m32 has similar problems because of multilib.)

[hackdefendr (HackDefendr)]

OK .. well, I started over again and left Universal variant on. GCC44 compiling now, and is well passed the MPFR check.

So if this has to be fixed upstream then there is no need to keep this defect open. And since I was wrong about being able to build 64 bit on a Snow Leopard that doesn't boot 64 bit, I guess there is no need for me worry about Universal builds anymore.

[kyle-macports@…]

I'm having the same problem, but with a different architecture/OS. I'm trying to build gcc44 on a PowerPC G5 running 10.5, and I'm trying to get a ppc64 build. I set the build_arch to ppc64, and both gmp and mpfr seem to have built correctly:

$ lipo -info /opt/local/lib/lib{gmp,mpfr}.dylib
Non-fat file: /opt/local/lib/libgmp.dylib is architecture: ppc64
Non-fat file: /opt/local/lib/libmpfr.dylib is architecture: ppc64

But when I attempt to build gcc44, the configure phase errors out, complaining that it cannot find libmpfr and libgmp.

For now, I've edited the portfile (via port edit gcc44) to add -m64 via configure.*-append... but that's probably the wrong way to do it, and in any event, I shouldn't have to do that.

[kyle-macports@…]

Actually, having added -m64 to the configure flags, the compiler then proceeds to error out in a new way.

/usr/bin/gcc-4.0  -I../../gcc-4.4.4/libcpp -I. -I../../gcc-4.4.4/libcpp/../include -I../../gcc-4.4.4/libcpp/include -I/opt/local/include -g -fkeep-inline-functions -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long  -I../../gcc-4.4.4/libcpp -I. -I../../gcc-4.4.4/libcpp/../include -I../../gcc-4.4.4/libcpp/include -I/opt/local/include -c -o makedepend.o -MT makedepend.o -MMD -MP -MF .deps/makedepend.Tpo ../../gcc-4.4.4/libcpp/makedepend.c
/usr/bin/gcc-4.0 -g -fkeep-inline-functions -L/opt/local/lib -m64 -o makedepend \
	  makedepend.o libcpp.a ../libiberty/libiberty.a \
	   -liconv
ld: warning in makedepend.o, file is not of required architecture
ld: warning in libcpp.a, file is not of required architecture
ld: warning in ../libiberty/libiberty.a, file is not of required architecture
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [makedepend] Error 1
make[2]: *** [all-stage1-libcpp] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [bootstrap] Error 2
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/build" && /usr/bin/make bootstrap " returned error 2
DEBUG: Backtrace: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/build" && /usr/bin/make bootstrap " returned error 2
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 9)
    invoked from within
"$procedure $targetname"
Warning: the following items did not execute (for gcc44): org.macports.activate org.macports.build org.macports.destroot org.macports.install
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

Checking on libiberty.a reveals:

$ find /opt/ -name libiberty.a -exec lipo -info {} \;
input file /opt//local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/build/build-ppc64-apple-darwin9/libiberty/libiberty.a is not a fat file
Non-fat file: /opt//local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/build/build-ppc64-apple-darwin9/libiberty/libiberty.a is architecture: ppc64
input file /opt//local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/build/libiberty/libiberty.a is not a fat file
Non-fat file: /opt//local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/build/libiberty/libiberty.a is architecture: ppc7400

I have no idea why gcc is building TWO copies of libiberty, much less why it's building one of them without the CFLAGS that the rest of it is built with... but that's what's going on. I'm attaching a full debug log.

[kyle-macports@…]

Debug log when CFLAGS/CXXFLAGS include -m64

[ryandesign (Ryan Carsten Schmidt)]

Replying to gvibe06@…:

Both build_arch and universal_archs are solely set to i386.

FYI, universal_archs must contain at least two architectures. It is not supported to set universal_archs to a single value. This will be enforced in the next version of MacPorts. The purpose of the universal variant is to build for multiple architectures.

[roumbaba]

Hi guys, I do have the exact same problem when trying to compile gcc44 and gcc45 when forcing build_arch i386 in macports.conf.

I started from scracth, removing all installed ports, cleaning, removing macport and erasing all folder related to macports. I reinstalled macports to 1.9.1 on os x 10.6.4 2.66ghz intel Core 2 Duo

I get the following error: sudo port install gcc44 ... info:configure checking for correct version of mpfr.h no :info:configure configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+ ...

but the mpfr version successfully installed by port is 3.0.0_p3 !!!

everything is compiled in 32 bits version: lipo -info /opt/local/lib/lib{gmp,mpfr}.dylib Non-fat file: /opt/local/lib/libgmp.dylib is architecture: i386 Non-fat file: /opt/local/lib/libmpfr.dylib is architecture: i386

I need to have everything compiled in 32 bits version because I will be linking some libraries installed by port against third part SDKs and libraries that are 32 bits only (I do not have the source). For instance I will need to link 32 bits libraries against fftw3 which will need to be 32 bits as well.

I am no expert but I have noticed the following macro in mpfr.h #define MPFR_VERSION_NUM(a,b,c) (((a) << 16L) | ((b) << 8) | (c)) could it be that this is somewhat a problem and would return a wrong MPFR_VERSIOn_NUMBER if it makes wrong wordlength assumption in the i386 case?

could it just be that the i386 macro is wrong in it's shifts? assuming a wrong wordlength? So when configure asks the check the version, the number return is too low? Thanks, baba Since this ticket hasn't been active for a long time, shall I open a new ticket?

[roumbaba]

Cc Me!

[roumbaba]

One hint: The problem should not be too difficult to fix for you because gcc44 builds fine in universal mode with universal set to x86_64 i386

[hackdefendr (HackDefendr)]

Replying to roumbaba@…:

One hint: The problem should not be too difficult to fix for you because gcc44 builds fine in universal mode with universal set to x86_64 i386

It is very difficult if I don't want to build 64-bit. For example...this special circumstance, I am using Crossover Office by Code Weavers, and it requires quartz-wm from X11.pkg via the Install DVD. It won't accept XQuartz from MacOSForge, nor will it accept X11.pkg from the same place. Digging further you would find that Crossover Office is just wine, but its 32-bit wine and seems to choke when it is forced to do what it was not meant to do. So I have to force build 32-bit, forcing i386 as default arch and forcing -universal in order to appease this very necessary application. It runs the Windows programs I need, and is really quite good at it.

The problem hits when I have a need for something (gcc44) for whatever reason, and we end up right back here at this very bug, today. Its truly baffling that everything being asked for and checked by the gcc44 Portfile is met. However, its configure run just can't find a file (mpfr.h) that is in fact located in the same place as gmp.h, a file asked for one step prior, and is found.

Anyway...I just thought I would point out the scenario where 64-bit cannot be used. I understand this may require some upstream help and lots of 5hr-Energy shots to get done, and that the possibility exists it can't/won't be done. Its important for some (me included) that this port work under both arch's. But if it can't then let's state why and close this out.
-- J

[macports@…]

Here is a potential solution/workaround:

I think this is a bug in the configure script for gcc44 (or whatever auto-generates the configure script):

In "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/gcc-4.4.5/configure"

Line 4607:

if test -d ${srcdir}/gcc && test "x$have_gmp" = xno; then

have_gmp=yes

If I understand shell language properly (and I do have a passing familiarity), I think the line should be:

if test -d ${srcdir}/gcc && test "x$have_gmp" = xyes; then

have_gmp=yes

I tried making that change in my local installation, and now my gcc44 build is chugging along.

I am going to sleep now, but I'll see in the morning if it succeeded.

WARNING: I am by no means an expert in macports, but I have worked with shell over the years, and I have compiled a lot of code from fink and macports.

[macports@…]

My previous comment was a mistake. Please disregard it. My workaround was incorrect, all it did was trick macports into skipping the mpfr/gmp test.

The actual cause of the failure on my box is:

  ld: warning: in /opt/local/lib/libmpfr.dylib, file was built for i386 which is not the architecture being linked (x86_64)
  ld: warning: in /opt/local/lib/libgmp.dylib, file was built for i386 which is not the architecture being linked (x86_64)
Undefined symbols:
  "_mpfr_subnormalize", referenced from:
      _main in ccSIThFg.o
  "_mpfr_erfc", referenced from:
      _main in ccSIThFg.o
  "_mpfr_atan2", referenced from:
      _main in ccSIThFg.o
  "_mpfr_init", referenced from:
      _main in ccSIThFg.o
      _main in ccSIThFg.o
  ld: symbol(s) not found

as noted in an earlier comment.

I apologize for adding any confusion.

[macports@…]

The workaround that *does* seem to work is to force your native system compiler to use the desired CFLAGS, since something is wrong with the code/config in the gcc44@4.4.5 port itself:

​http://stackoverflow.com/questions/4367248/how-to-compile-gcc44-in-i386-mode-in-macports

The explanation in the stackoverflow post is a bit unclear, but here is what I did

cd usr/bin

sudo mv gcc-4.2 gcc-4.2-real

Create a new file  gcc-4.2.sh  with content:
#!/bin/sh
/usr/bin/gcc-4.2-real -m32 "$@"
 
sudo chmod a+x  gcc-4.2.sh

sudo ln -s gcc-4.2.sh gcc-4.2

This way, when the port tries to call /usr/bin/gcc4.2 without the desired "-m32" flag, the gcc-4.2.sh forcibly re-inserts it.

This approach might work for other CFLAGS as well, but I have not tested that.

Take this advice with a grain of salt, since my gcc is still compiling. I'll see tomorrow if it succeeded.

[macports@…]

Following up to my previous post.

The port install succeeded:

--->  Installing gcc44 @4.4.5_0
--->  Activating gcc44 @4.4.5_0
--->  Cleaning gcc44
--->  Removing work directory for gcc44

[petrrr]

Cc Me!

[petrrr]

gcc42 was removed in r131452, so this does not apply to gcc42 any more.

[kencu (Ken)]

It appears that the issue the user was having here was primarily that he wanted to build 32bit code on a machine that defaults to 64bit, and wanted gcc to build as 32bit to allow that.

Our gcc setup is not designed to work this way. The compiler is always built for the native arch. The support libraries are built to the target arch, and can be built multilib to support different bit depths if +universal is selected.

So the proper fix here would have been to build gcc44 +universal, and that gcc44, built for the native arch, could build 32bit or 64bit Intel code as desired.

There is nothing to fix here.

This ticket is ancient history now, and this information is of use to probably no-one, but just cleaning up.