objcopy --weaken

objcopy --weaken

[Peter S. Mazinger]

Hello!

The objcopy --weaken command suggests that it is able to change all 
(global) symbols to weak. Running it against an object file it does it, 
but running it against a shared lib does not change anything.

Is this correct behaviour (tested 2.15.92.0.2/2.16.1/2.16.91.0.7)?

I have also tried to do it w/ objcopy -w -W * lib.so, but that returns the 
help (this should work as of man page)

Creating a list and using --weaken-symbols=list does not solve it either.

Thanks, Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: objcopy --weaken

[Daniel Jacobowitz]

On Wed, Apr 12, 2006 at 01:05:48AM +0200, Peter S. Mazinger wrote:
> Hello!
> 
> The objcopy --weaken command suggests that it is able to change all 
> (global) symbols to weak. Running it against an object file it does it, 
> but running it against a shared lib does not change anything.

What do you expect it to do?

In modern shared library lookup, dynamic exported symbols are the same
whether they are strong or weak.

-- 
Daniel Jacobowitz
CodeSourcery

Re: objcopy --weaken

[Peter S. Mazinger]

On Tue, 11 Apr 2006, Daniel Jacobowitz wrote:

> On Wed, Apr 12, 2006 at 01:05:48AM +0200, Peter S. Mazinger wrote:
> > Hello!
> > 
> > The objcopy --weaken command suggests that it is able to change all 
> > (global) symbols to weak. Running it against an object file it does it, 
> > but running it against a shared lib does not change anything.
> 
> What do you expect it to do?

I would have expected to change all global(strong) to weak.

> In modern shared library lookup, dynamic exported symbols are the same
> whether they are strong or weak.

That is true if modern=glibc (there is though some compat  
option/environment setting to disable this behaviour).

At link time if libpthread.so and libc.so provide the same symbol (could 
happen w/ any other 2 libs, the example is "real-life", the linker fails, 
if one of them is not weak.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: objcopy --weaken

[Daniel Jacobowitz]

On Wed, Apr 12, 2006 at 01:56:50AM +0200, Peter S. Mazinger wrote:
> That is true if modern=glibc (there is though some compat  
> option/environment setting to disable this behaviour).

(A) I believe Solaris does the same thing nowadays.  (B) I believe
they've threatened several times to remove the option.

> At link time if libpthread.so and libc.so provide the same symbol (could 
> happen w/ any other 2 libs, the example is "real-life", the linker fails, 
> if one of them is not weak.

Er, is this really true?  Why should it be?

If there's a good reason for it, e.g. detecting non-deterministic
binding, weakening one is just going to give you unpredictable bugs
later.  The strong one will not be reliably picked at runtime.

-- 
Daniel Jacobowitz
CodeSourcery

Re: objcopy --weaken

[Peter S. Mazinger]

On Wed, 12 Apr 2006, Daniel Jacobowitz wrote:

> On Wed, Apr 12, 2006 at 01:56:50AM +0200, Peter S. Mazinger wrote:
> > That is true if modern=glibc (there is though some compat  
> > option/environment setting to disable this behaviour).
> 
> (A) I believe Solaris does the same thing nowadays.  (B) I believe
> they've threatened several times to remove the option.
> 
> > At link time if libpthread.so and libc.so provide the same symbol (could 
> > happen w/ any other 2 libs, the example is "real-life", the linker fails, 
> > if one of them is not weak.
> 
> Er, is this really true?  Why should it be?
> 
> If there's a good reason for it, e.g. detecting non-deterministic
> binding, weakening one is just going to give you unpredictable bugs
> later.  The strong one will not be reliably picked at runtime.

for the libc.so libpthread.so pair the symbol has to be weakened in 
libc.so, then linker does not complain and ld.so takes care of the rest, 
because libc.so is last in the scanned libs, so the app will find the 
libpthread.so version first.

For other lib combos it is indeed unreliable, depending on the order ld.so 
loads them.

Peter 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2