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

[ adding libtool-patches ]

* Rainer Orth wrote on Mon, Jan 31, 2011 at 03:54:29PM CET:
> GNU ld testing failed initially for the 64-bit multilib:
> 
> libtool: link: /vol/gcc/obj/gcc-4.6.0-20110128/11-gcc-gas-gld-go/./gcc/collect-ld -r -o crypto/libsubtle.o    --whole-archive crypto/.libs/libsubtle.a --no-whole-archive
> /vol/gcc/bin/gld-2.21: Relocatable linking with relocations from format elf64-x86-64-sol2 (sort/.libs/libsort.a(libsort.a.o)) to format elf32-i386-sol2 (sort/libsort.o) is not supported
> make[7]: *** [sort/libsort.lo] Error 1
> 
> 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).

Anyway, I'm applying your patch to upstream Libtool, as below.

Thanks,
Ralf

2011-02-01  Rainer Orth  <ro@...>  (tiny change)

	Fix LD setting for 64-bit Solaris 2/x86.
	* libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*):
	Determine GNU ld options for 64-bit Solaris 2/x86.  Detect gld
	2.21 _sol2 emulations.

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