Message ID | 20110201064025.GA26325@gmx.de |
---|---|
State | New |
Headers | show |
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes: >> Ultimately, this turned out to be a libtool issue: it doesn't handle >> Solaris 2/x86 at all, and Solaris 2/SPARC with GNU ld is incomplete in >> that it doesn't account for the new *_sol2 emulations in gld 2.21. All >> this second-guessing the compiler suggests to me that it's a bad idea to >> call the linker directly if gcc is in use. > > I know libtool bashing is hitting an easy target, but IIRC we still had > user reports last year of (probably older) GCC installations where > partial linking did not work when using the gcc driver, as opposed to > using ld directly (note! for partial linking). Ok, I see. It still seems like a bad idea to reconstruct what the compiler would do instead of letting it do its job. This may be difficult for vendor compilers, but GCC should have the necessary switches to do without. > Anyway, I'm applying your patch to upstream Libtool, as below. Great, thanks. Ian, could you check this into libgo, too? Thanks. Rainer
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes: > Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes: > >>> Ultimately, this turned out to be a libtool issue: it doesn't handle >>> Solaris 2/x86 at all, and Solaris 2/SPARC with GNU ld is incomplete in >>> that it doesn't account for the new *_sol2 emulations in gld 2.21. All >>> this second-guessing the compiler suggests to me that it's a bad idea to >>> call the linker directly if gcc is in use. >> >> I know libtool bashing is hitting an easy target, but IIRC we still had >> user reports last year of (probably older) GCC installations where >> partial linking did not work when using the gcc driver, as opposed to >> using ld directly (note! for partial linking). > > Ok, I see. It still seems like a bad idea to reconstruct what the > compiler would do instead of letting it do its job. This may be > difficult for vendor compilers, but GCC should have the necessary > switches to do without. > >> Anyway, I'm applying your patch to upstream Libtool, as below. > > Great, thanks. Ian, could you check this into libgo, too? Done. Ian
Ian Lance Taylor <iant@google.com> writes: >>> Anyway, I'm applying your patch to upstream Libtool, as below. >> >> Great, thanks. Ian, could you check this into libgo, too? > > Done. Excellent, thanks. Rainer
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 033c9a0..5cc027b 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -1374,14 +1374,27 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*) CFLAGS="$SAVE_CFLAGS" fi ;; -sparc*-*solaris*) +*-*solaris*) # Find out which ABI we are using. echo 'int i;' > conftest.$ac_ext if AC_TRY_EVAL(ac_compile); then case `/usr/bin/file conftest.o` in *64-bit*) case $lt_cv_prog_gnu_ld in - yes*) LD="${LD-ld} -m elf64_sparc" ;; + yes*) + case $host in + i?86-*-solaris*) + LD="${LD-ld} -m elf_x86_64" + ;; + sparc*-*-solaris*) + LD="${LD-ld} -m elf64_sparc" + ;; + esac + # GNU ld 2.21 introduced _sol2 emulations. Use them if available. + if ${LD-ld} -V | grep _sol2 >/dev/null 2>&1; then + LD="${LD-ld}_sol2" + fi + ;; *) if ${LD-ld} -64 -r -o conftest2.o conftest.o >/dev/null 2>&1; then LD="${LD-ld} -64"