bug#14364: Bug Report: Lacking '=' when specifying -soname

[Peter Rosin]

On 2013-05-08 13:13, Bob Fischer wrote:
>>
>>
>> So, the problem does not appear to be the command line libtool is
>> generating. I.e., the problem appears to be elsewhere.
> 
> At the end of the day, things don't work.  I run the following on my 
> configure script, and then things do work:
>     sed -i 's/-soname \$wl/-soname=/g' configure

I'm sure there are other places you can patch to make this work.

> Thanks for digging up the stuff in the manuals.  Unfortunately, manuals don't 
> always match reality.  This is not a stock GNU ld 2.20, but rather one that's 
> been hacked by SLSE 11.
>    GNU ld (GNU Binutils; SUSE Linux Enterprise 11) 2.20.0.20100122-0.7.9
> 
> That would make it technically a SUSE bug.  But maybe they don't care.  Or 
> they've already fixed it  Or they think it's a feature, not a bug.  At the 
> end of the day, scripts generated by libtool are broken.  Upgrading libtool 
> is much easier than upgrading ld.  This is a shared system and I can't 
> realistically use a different GNU ld; however, I can use a different libtool.

Saying that this problem is caused by libtool is not really fair, when libtool
uses a construct that is documented and presumably works for "everybody else".

Have you even verified if your ld groks -soname libfoo.so.0 without the equal
sign before pointing fingers at ld? Have you checked if it is some interaction
with the g++ compiler driver stomping arguments?

Trying to run the g++ command printed by libtool manually, but inserting
a -v to see how g++ invokes the low level tools might be illuminating.

> Since the two forms are supposed to be equivalent, would it be possible to 
> change libtool to use the '=' form?  Or maybe make a change with smaller 
> scope: use the '=' form for certain versions of GNU ld, maybe specific to 
> SLES?

Maybe, doesn't sound too exotic, but it's not my area of expertise.

> I'd also be relatively happy if there was a way I could build the 
> configure.ac file to work around this problem --- in essence, override the 
> '-soname' with '-soname=' coming from the standard libtool.  However, libtool 
> looks like it's a little all-or-nothing, and not quite amenable to 
> incremental overrides (hence the see hack).  I'm wondering if maybe 
> generating '-soname=' for specific versions of SUSE ld would be the most 
> expedient way to solve this problem.

I'm not so sure the SLES ld is to blame, it even seems unlikely.

Cheers,
Peter