Ticket #20933 (closed defect: fixed)
gcc42, gcc43 on snow leopard: in libmpfr.dylib, libgmp.dylib, libiconv.dylib, file is not of required architecture
| Reported by: | ram@… | Owned by: | mww@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | snowleopard | Cc: | ryandesign@…, luis.beca@…, kevin.way@…, faisal.moledina@…, hans@…, mmoll@…, eonofri@…, dmonner@…, thomas.mccullough@…, swinbank@…, nthomas@…, tamyrvoll@…, ksaito11+macport@…, patrickrose@…, brian.gyss@…, stefan.janecek@…, akim.demaille@…, tim.stoop@…, rabbielvis@…, mark_everitt@…, alejandro.aragon@…, dubmarauder@…, m@…, brody1@…, trevor.bain@…, rafael@…, nicholas.d.pate@…, snc@…, carl@… |
| Port: | gcc42, gcc43 |
Description
full build log attached
Attachments
Change History
Changed 4 years ago by ram@…
- Attachment gcc42-debug.log.bz2 added
comment:1 follow-ups: ↓ 7 ↓ 9 Changed 4 years ago by ryandesign@…
- Cc ryandesign@… added
- Port changed from gcc42 to gcc42, gcc43
- 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:7 in reply to: ↑ 1 Changed 4 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:9 in reply to: ↑ 1 ; follow-ups: ↓ 10 ↓ 12 Changed 4 years ago by 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.
comment:10 in reply to: ↑ 9 Changed 4 years ago by 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.
comment:11 Changed 4 years ago by ryandesign@…
- Cc eonofri@…, jmhuttun@…, dmonner@…, thomas.mccullough@… added
Cc'ing watchers of duplicate #20974.
comment:12 in reply to: ↑ 9 Changed 4 years ago by 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.
comment:26 in reply to: ↑ 25 Changed 4 years ago by 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:28 Changed 4 years ago by 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 4 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:34 Changed 4 years ago by m@…
Cc Me!
comment:37 follow-up: ↓ 38 Changed 4 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 4 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:40 Changed 4 years ago by rafael@…
Cc Me!
comment:45 Changed 3 years ago by ram@…
I can no longer report this issue, anyone still seeing this?
full debug log