Opened 8 years ago

Closed 7 years ago

#20933 closed defect (fixed)

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

Reported by: skymoo (Adam Mercer) Owned by: mww@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: snowleopard Cc: ryandesign (Ryan Schmidt), luis.beca@…, kevin.way@…, faisal.moledina@…, hans@…, mamoll (Mark Moll), eonofri@…, dmonner@…, thomas.mccullough@…, jdswinbank (John Swinbank), nthomas@…, tamyrvoll@…, ksaito11+macport@…, patrickrose@…, brian.gyss@…, stefan.janecek@…, akimd (Akim Demaille), tim.stoop@…, rabbielvis@…, mark_everitt@…, alejandro.aragon@…, dubmarauder@…, m@…, brody1@…, trevor.bain@…, rafael@…, nicholas.d.pate@…, nerdling (Jeremy Lavergne), carl@…
Port: gcc42, gcc43

Description

full build log attached

Attachments (1)

gcc42-debug.log.bz2 (42.4 KB) - added by skymoo (Adam Mercer) 8 years ago.
full debug log

Download all attachments as: .zip

Change History (47)

Changed 8 years ago by skymoo (Adam Mercer)

full debug log

comment:1 follow-ups: Changed 8 years ago by ryandesign (Ryan Schmidt)

  • Cc ryandesign@… added
  • Port gcc43 added
  • Summary changed from gcc42 fails to build on snow leopard to gcc42, gcc43 on snow leopard: in libmpfr.dylib, libgmp.dylib, libiconv.dylib, file is not of required architecture
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.

comment:2 Changed 8 years ago by luis.beca@…

  • Cc luis.beca@… added

Cc Me!

comment:3 Changed 8 years ago by kevin.way@…

  • Cc kevin.way@… added

Cc Me!

comment:4 Changed 8 years ago by faisal.moledina@…

  • Cc faisal.moledina@… added

Cc Me!

comment:5 Changed 8 years ago by hans@…

  • Cc hans@… added

Cc Me!

comment:6 Changed 8 years ago by nick@…

Cc Me!

comment:7 in reply to: ↑ 1 Changed 8 years ago by 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.

comment:8 Changed 8 years ago by mamoll (Mark Moll)

  • Cc mmoll@… added

Cc Me!

comment:9 in reply to: ↑ 1 ; follow-ups: Changed 8 years ago by MasakiOita

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.

comment:10 in reply to: ↑ 9 Changed 8 years ago by MasakiOita

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.

comment:11 Changed 8 years ago by ryandesign (Ryan Schmidt)

  • Cc eonofri@… jmhuttun@… dmonner@… thomas.mccullough@… added

Cc'ing watchers of duplicate #20974.

comment:12 in reply to: ↑ 9 Changed 8 years ago by ryandesign (Ryan Schmidt)

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.

comment:13 Changed 8 years ago by jmhuttun@…

  • Cc jmhuttun@… removed

Cc Me!

comment:14 Changed 8 years ago by jdswinbank (John Swinbank)

  • Cc swinbank@… added

Cc Me!

comment:15 Changed 8 years ago by nthomas@…

  • Cc nthomas@… added

Cc Me!

comment:16 Changed 8 years ago by brian.gyss@…

  • Cc brian.gyss@… added

Cc Me!

comment:17 Changed 8 years ago by brian.gyss@…

  • Cc brian.gyss@… removed

Cc Me!

comment:18 Changed 8 years ago by tamyrvoll@…

  • Cc tamyrvoll@… added

Cc Me!

comment:19 Changed 8 years ago by ksaito11+macport@…

  • Cc ksaito11+macport@… added

Cc Me!

comment:20 Changed 8 years ago by patrickrose@…

  • Cc patrickrose@… added

Cc Me!

comment:21 Changed 8 years ago by bigwhaledork@…

  • Cc bigwhaledork@… added

Cc Me!

comment:22 Changed 8 years ago by bigwhaledork@…

  • Cc bigwhaledork@… removed

Cc Me!

comment:23 Changed 8 years ago by brian.gyss@…

  • Cc brian.gyss@… added

Cc Me!

comment:24 Changed 8 years ago by stefan.janecek@…

  • Cc stefan.janecek@… added

Cc Me!

comment:25 follow-up: Changed 8 years ago by akimd (Akim Demaille)

  • Cc akim.demaille@… added

Cc Me!

comment:26 in reply to: ↑ 25 Changed 8 years ago by akimd (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.

$

comment:27 Changed 8 years ago by tim.stoop@…

  • Cc tim.stoop@… added

Cc Me!

comment:28 Changed 8 years ago by akimd (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.

comment:29 Changed 8 years ago by 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.

comment:30 Changed 8 years ago by rabbielvis@…

  • Cc rabbielvis@… added

Cc Me!

comment:31 Changed 8 years ago by mark_everitt@…

  • Cc mark_everitt@… added

Cc Me!

comment:32 Changed 8 years ago by alejandro.aragon@…

  • Cc alejandro.aragon@… added

Cc Me!

comment:33 Changed 8 years ago by dubmarauder@…

  • Cc dubmarauder@… added

Cc Me!

comment:34 Changed 8 years ago by m@…

Cc Me!

comment:35 Changed 8 years ago by m@…

  • Cc m@… added

Cc Me!

comment:36 Changed 8 years ago by brody1@…

  • Cc brody1@… added

Cc Me!

comment:37 follow-up: Changed 8 years ago by dave@…

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

comment:38 in reply to: ↑ 37 Changed 8 years ago by 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

comment:39 Changed 8 years ago by trevor.bain@…

  • Cc trevor.bain@… added

Cc Me!

comment:40 Changed 8 years ago by rafael@…

Cc Me!

comment:41 Changed 8 years ago by rafael@…

  • Cc rafael@… added

Cc Me!

comment:42 Changed 8 years ago by nicholas.d.pate@…

  • Cc nicholas.d.pate@… added

Cc Me!

comment:43 Changed 8 years ago by nerdling (Jeremy Lavergne)

  • Cc snc@… added

Cc Me!

comment:44 Changed 7 years ago by carl@…

  • Cc carl@… added

Cc Me!

comment:45 Changed 7 years ago by skymoo (Adam Mercer)

I can no longer report this issue, anyone still seeing this?

comment:46 Changed 7 years ago by skymoo (Adam Mercer)

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.