gcc43 @4.3.4 build failure - ld: duplicate symbol in libbackend.a and tree-inline.o

[faisal.moledina@…]

On Macbook aluminum (Core 2 Duo), Snow Leopard 10.6, Macports 1.8.99

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc43/work/build/./prev-gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc43/work/build/./prev-gcc/ -B/opt/local/i386-apple-darwin10.0.0/bin/   -g -O2 -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 				     -Wno-overlength-strings    -DHAVE_CONFIG_H  -o cc1plus-dummy \
	      cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o darwin-c.o c-pretty-print.o c-opts.o c-pch.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o c-omp.o tree-inline.o dummy-checksum.o main.o  libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a  -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/opt/local/lib -L/opt/local/lib -lmpfr -lgmp
ld: duplicate symbol _init_inline_once in libbackend.a(tree-inline.o) and tree-inline.o
collect2: ld returned 1 exit status
make[3]: *** [cc1plus-dummy] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] 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 gcc43): org.macports.activate org.macports.build org.macports.destroot org.macports.install
Error: Status 1 encountered during processing.

This occurred whether or not I used the +universal variant (where +universal includes x86_64 in my config file).

[faisal.moledina@…]

I forgot to add, this is with the new Xcode from the Snow Leopard install disc, so Xcode 3.2.0.

[gjznituv@…]

cc me

[faisal.moledina@…]

gcc43 build after fresh install of MacPorts 1.8.0

[faisal.moledina@…]

Attachment is on my same system as in the original post, but now with a fresh install of MacPorts and without using the universal variant, as x86_64 builds are apparently the default.

[ram@…]

Cc Me!

[sean@…]

After much searching, it's possible to fix this problem with the patch described here:

 http://www.nabble.com/-Bug-c%2B%2B-41180---New:-can-not-build-gcc-4.4.1-on-Snow-Leopard-Mac-OS-X-10.6-td25183434.html

My install procedure (I rm -rf'ed /opt/local after 10.6) was:

1. port install libiconv +universal
2. port install mpfr +universal
3. port install gcc43
4. [wait until it breaks]
5. 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/
6. Edit line 76 of the file and remove tree-inline.o from CXX_C_OBJS
7. Resume compiling

I can put together a complete patch if necessary but didn't create a .orig file to diff from when getting this to work.

[nthomas@…]

Cc Me!

[mmoll@…]

Cc Me!

[faisal.moledina@…]

Is this a possible solution moving forward? I haven't tried it yet. I really need the gcc43 port for both the octave and py26-scipy ports.

[cedric.foellmi@…]

I tried this solution, also because I need scipy (with python2.5). I had to install first libiconv +universal, mpfr +universal and some other ports needed to be upgraded to +universal variants, then I compiled gcc43 until it breaks, and followed the instructions. I have been able to compile gcc43. But compilation of scipy failed, with an error message I cannot handle myself (still a newbie on theses matters).

[mmoll@…]

This is not really a solution, but you can download a binary of gfortran 4.2 that can *produce* universal binaries here:  http://r.research.att.com/tools. If you're able to get scipy and octave to compile as universal binaries, at least you'll know that the problem is with the gcc43 port. I used to get fftw-3 to compile as a universally binary (haven't tested yet if it works correctly).

[macports@…]

Cc Me!

[vince@…]

Since only this version of gfortran (I mean, the one available on the webpage you cited) is able to build universal binaries, would it be admissible to exceptionally modifies the Portfile of scipy in order to allow for the use of this compiler instead of mac-ports ones? I can confirm fftw-3 runs universal.

[cedric.foellmi@…]

Replying to mmoll@…:

This is not really a solution, but you can download a binary of gfortran 4.2 that can *produce* universal binaries here:  http://r.research.att.com/tools. If you're able to get scipy and octave to compile as universal binaries, at least you'll know that the problem is with the gcc43 port. I used to get fftw-3 to compile as a universally binary (haven't tested yet if it works correctly).

I don't really understand how this is a solution. Scipy compile very well on SnowLeo (see  http://blog.hyperjeff.net/?p=160 with easy_install). So how and what for a new gfortran compiler come into the picture?

My only problem is that I want to use py-biggles port. Macport seems the only one to build biggles correctly (i.e. with a correct build of plotutils+x11), although I have attempted many built by my own. However, macport is unable to build scipy itself, not talking that it requires to recompile gcc (which sounds crazy to me).

[ram@…]

Replying to cedric.foellmi@…:

I don't really understand how this is a solution. Scipy compile very well on SnowLeo (see  http://blog.hyperjeff.net/?p=160 with easy_install). So how and what for a new gfortran compiler come into the picture?

Which will lead to problems in the future, those instructions tell you to move Apples NumPy out of the way and reinstall a new NumPy in the same location. This will lead to a broken NumPy in future Apple patches and lead to potential unexpected behaviour.

[cedric.foellmi@…]

Cc Me!

[jvliwanag@…]

Cc Me!

[stefan.janecek@…]

Cc Me!

[swinbank@…]

Cc Me!

[francois@…]

Cc Me!

[anand.prabhakar.patil@…]

Cc Me!

[jmr@…]

r57794

[anand.prabhakar.patil@…]

Thanks! I heart Macports!

[faisal.moledina@…]

Thanks a lot! Now I can continue trying to build octave.

[stephane.bachelier@…]

Cc Me!