Re: [libgo, build] Use convenience libraries to create .gox files
Ralf Wildenhues 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, Center for Biotechnology, Bielefeld University
Support 64-bit default GCC on Solaris/x86
In version 4.7, GCC will gain a 64-bit default Solaris/x86 configuration, similar to the existing sparcv9-sun-solaris2 configurations. In order for that to work with GNU ld (Sun ld works out of the box), I had to make the following minor patch to libtool.m4. This patch has been tested with a slightly earlier version already included in the gcc repository for Go support. There's an effort underway to upgrade the libtool in gcc to 2.4.2. A gcc bootstrap with 64-bit gld and this patch included completed without regressions. If the patch is accepted, it would be good if it could be included in libtool 2.4.3 so by the time gcc 4.7 is released, a corresponding version of libtool is available. Thanks. Rainer 2011-10-31 Rainer Orth * libltdl/m4/libtool.m4: Handle x86_64-*-solaris2.1[0-9]* like i?86-*-solaris* when determining GNU ld flags to pass for 64-bit objects. --- libtool.m4.dist 2011-10-30 19:21:35.014541633 +0100 +++ libtool.m4 2011-10-30 21:37:43.361978987 +0100 @@ -1383,7 +1383,7 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux* case $lt_cv_prog_gnu_ld in yes*) case $host in -i?86-*-solaris*) +i?86-*-solaris* | x86_64-*-solaris2.1[[0-9]]*) LD="${LD-ld} -m elf_x86_64" ;; sparc*-*-solaris*) -- --------- Rainer Orth, Center for Biotechnology, Bielefeld University
Patch for bug#16452: opt_duplicate_compiler_generated_deps is harmful on Solaris
As reported in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16452 the default for opt_duplicate_compiler_generated_deps can cause exception handling/unwinding failures on 64-bit Solaris 10+/x86 when the underlying gcc bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788 is fixed. The libtool bug report already contains the fix for the version of libtool bundled in the gcc repo. I'd like to include the patch from the gcc bug report in the upcoming next gcc release, 4.9.0. gcc policy requires that such patches have to be accepted for upstream libtool first, so here's the patch to git libtool: diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index f452e54..85b4e0c 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -497,7 +497,7 @@ libtool_validate_options () test : = "$debug_cmd" || func_append preserve_args " --debug" case $host in - *cygwin* | *mingw* | *pw32* | *cegcc*) + *cygwin* | *mingw* | *pw32* | *cegcc* | *solaris2* ) # don't eliminate duplications in $postdeps and $predeps opt_duplicate_compiler_generated_deps=: ;; It has been tested on i386-pc-solaris2.10 with gcc 4.8 without testsuite regressions. Rainer -- --------- Rainer Orth, Center for Biotechnology, Bielefeld University
Re: bug#16452: opt_duplicate_compiler_generated_deps is harmful on Solaris
Hi Gary, > I took the liberty of writing a ChangeLog on your behalf. I usually provide ChangeLog entries myself, but seeing there ins't a ChangeLog in libtool anymore, I forgot to check the git log messages instead. Sorry about that. > Pushed, this will be in the incoming release as long as testing doesn't find > any issues. Thanks. Thanks for the quick turnaround. Rainer -- --------- Rainer Orth, Center for Biotechnology, Bielefeld University