Re: [libgo, build] Use convenience libraries to create .gox files

[Rainer Orth]

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

[Rainer Orth]

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

[Rainer Orth]

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

[Rainer Orth]

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