gcc42, gcc43 on snow leopard: in libmpfr.dylib, libgmp.dylib, libiconv.dylib, file is not of required architecture

[ram@…]

full build log attached

[ram@…]

full debug log

[ryandesign@…]

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
ld: warning: in /opt/local/lib/libiconv.dylib, file is not of required architecture

I see the same with gcc43. These libraries are x86_64 on my system. Perhaps gcc doesn't realize it's supposed to be building x86_64 things.

[luis.beca@…]

Cc Me!

[kevin.way@…]

Cc Me!

[faisal.moledina@…]

Cc Me!

[hans@…]

Cc Me!

[nick@…]

Cc Me!

[thomas.mccullough@…]

This is the same as #20974. I noted the same thing regarding these three dylibs. I don't know who to contact to point out the redundancy.

[mmoll@…]

Cc Me!

[epimetheus314@…]

Replying to ryandesign@…:

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
ld: warning: in /opt/local/lib/libiconv.dylib, file is not of required architecture

I see the same with gcc43. These libraries are x86_64 on my system. Perhaps gcc doesn't realize it's supposed to be building x86_64 things.

I had the same problem. Since my iMac with Core 2 Duo is an old model, the kernel runs in a 32bit mode while Apple's gcc produces x86_64 executables.

I found the problem is that 'config.guess' in gcc's source directory returns 'i386-apple-darwin10.0.0' based on the output of uname -p. So I took the following procedure, which worked fine for me:

1) Add three lines to 'configure.args' section in Portfile like:

80,81c80,84
<         --with-mpfr=${prefix}
< # do NOT use MacPorts binutils -- they do not work
---
>         --with-mpfr=${prefix} \
> 	--build=x86_64-apple-darwin10 \
> 	--host=x86_64-apple-darwin10 \
> 	--target=x86_64-apple-darwin10
>       # do NOT use MacPorts binutils -- they do not work

2) Install gcc43. This time it does not yield dylibs incompatibilities mentioned above, but yields the same error with #20816.

3) cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc43/work/gcc-4.3.4/gcc/cp/

4) Edit line 76 of 'Make-lang.in' and remove 'tree-inline.o' from CXX_C_OBJS.

5) Resume compiling.

[epimetheus314@…]

Replying to epimetheus314@…: On second thought, my solution above might produce another problem in configuring other ports, since uname -p always returns i386.

Discarding 1) above and using the procedure in Comment 6 of #20816 by Sean might be better, although it produces 32bit executables for gcc43.

[ryandesign@…]

Cc'ing watchers of duplicate #20974.

[ryandesign@…]

Replying to epimetheus314@…:

Since my iMac with Core 2 Duo is an old model, the kernel runs in a 32bit mode while Apple's gcc produces x86_64 executables.

 Apparently all Macs except Xserve use a 32-bit kernel by default in Snow Leopard, so this is not unusual or a problem.

[jmhuttun@…]

Cc Me!

[swinbank@…]

Cc Me!

[nthomas@…]

Cc Me!

[brian.gyss@…]

Cc Me!

[brian.gyss@…]

Cc Me!

[tamyrvoll@…]

Cc Me!

[ksaito11+macport@…]

Cc Me!

[patrickrose@…]

Cc Me!

[bigwhaledork@…]

Cc Me!

[bigwhaledork@…]

Cc Me!

[brian.gyss@…]

Cc Me!

[stefan.janecek@…]

Cc Me!

[akim.demaille@…]

Cc Me!

[akim.demaille@…]

For what it's worth, I seem to have been asking for troubles by myself. For instance, I could not compile simple boost programs:

$ cat conftest.cc
#include <boost/test/unit_test.hpp>
using boost::unit_test::test_suite;
test_suite* init_unit_test_suite(int argc, char ** argv)
{
  return NULL; 
}

int
main ()
{
  BOOST_CHECK(2 == 2);
  return 0;
}
$ i686-apple-darwin10-g++-4.2.1 -o conftest   -isystem /opt/local/include   -L/opt/local/lib -L/opt/local/lib conftest.cc -lboost_unit_test_framework-mt
ld: warning: in /opt/local/lib/libboost_unit_test_framework-mt.dylib, file is not of required architecture
Undefined symbols:
  "vtable for boost::unit_test::unit_test_log_t", referenced from:
      __ZTVN5boost9unit_test15unit_test_log_tE$non_lazy_ptr in cccVDvae.o
  "boost::test_tools::tt_detail::check_impl(boost::test_tools::predicate_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)", referenced from:
      _main in cccVDvae.o
  "boost::unit_test::unit_test_log_t::set_checkpoint(boost::unit_test::basic_cstring<char const>, unsigned long, boost::unit_test::basic_cstring<char const>)", referenced from:
      _main in cccVDvae.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

I have always used completely qualified compiler names, because I use distcc, and I even used it with PPC/Intel machines cross-compiling for the other arch.

It turns out that if I under-specify the compiler I want use, it works.

$ g++-4.2 -o conftest   -isystem /opt/local/include   -L/opt/local/lib -L/opt/local/lib conftest.cc -lboost_unit_test_framework-mt
$ 

So in my case I just have to change my scripts from using i686-apple-darwin10-g++-4.2.1 to using g++-4.2. Both are from the same suite though.

$ which i686-apple-darwin10-g++-4.2.1
$ i686-apple-darwin10-g++-4.2.1 --version
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ which g++-4.2
/usr/bin/g++-4.2
$ g++-4.2 --version
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$

[tim.stoop@…]

Cc Me!

[akim.demaille@…]

I'm not sure I completely understand what are the problem people are willing to solve here, but every port that had this "file is not of required architecture" problem could be solved, at least on my machine, by asking for a reintall of the package.

for i in gmp mpfr gcc45
do
  sudo port uninstall -f $i
  sudo port install $i
done

did it for me.

[hans@…]

akim, this is, in my case at least, from a clean macports installation. The port in question was never installed, nor were any of its dependencies.

[rabbielvis@…]

Cc Me!

[mark_everitt@…]

Cc Me!

[alejandro.aragon@…]

Cc Me!

[dubmarauder@…]

Cc Me!

[m@…]

Cc Me!

[m@…]

Cc Me!

[brody1@…]

Cc Me!

[dave@…]

I think this thread may hold the answer:  http://gcc.gnu.org/ml/gcc-bugs/2009-08/msg02240.html

[dave@…]

Replying to dave@…:

I think this thread may hold the answer:  http://gcc.gnu.org/ml/gcc-bugs/2009-08/msg02240.html

Along with making the patch mentioned in that thread (I didn't try without the patch) I was able to build g++4.4 by using the following:

~/src/gcc-4.4.1/configure --enable-languages=c++ --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --with-gmp=/opt/local --with-mpfr=/opt/local --with-libiconv-prefix=/opt/local --prefix=/usr/local/gcc-4.4.1 CC="/opt/local/libexec/ccache/gcc -L/opt/local/lib" CXX=/opt/local/libexec/ccache/g++ && make -j3

[trevor.bain@…]

Cc Me!

[rafael@…]

Cc Me!

[rafael@…]

Cc Me!

[nicholas.d.pate@…]

Cc Me!

[snc@…]

Cc Me!

[carl@…]

Cc Me!