public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* resolving weak symbols.
@ 2024-03-28 22:58 Tom Kacvinsky
  2024-03-30  1:43 ` Alan Modra
  2024-04-12 16:01 ` Nick Clifton
  0 siblings, 2 replies; 3+ messages in thread
From: Tom Kacvinsky @ 2024-03-28 22:58 UTC (permalink / raw)
  To: Binutils

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

HI,

Support I have a static archive libfoo.a that has a weak sym, call it quux.

And the link line I have is

gcc -o foo -L. -lfoo -Wl,--as-needed -lbar -lbaz

Where libbar.so and libbaz.so also have the weak symbol quux.

Then the executable foo has a dynamic dependency on both libbar.so _and_
libbaz.so.

Is this expected behavior?  Is there a way of forcing exactly one of
libfoo.so and libbaz.so to be used?

Thanks,

Tom

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: resolving weak symbols.
  2024-03-28 22:58 resolving weak symbols Tom Kacvinsky
@ 2024-03-30  1:43 ` Alan Modra
  2024-04-12 16:01 ` Nick Clifton
  1 sibling, 0 replies; 3+ messages in thread
From: Alan Modra @ 2024-03-30  1:43 UTC (permalink / raw)
  To: Tom Kacvinsky; +Cc: Binutils

On Thu, Mar 28, 2024 at 06:58:36PM -0400, Tom Kacvinsky wrote:
> HI,
> 
> Support I have a static archive libfoo.a that has a weak sym, call it quux.
> 
> And the link line I have is
> 
> gcc -o foo -L. -lfoo -Wl,--as-needed -lbar -lbaz
> 
> Where libbar.so and libbaz.so also have the weak symbol quux.
> 
> Then the executable foo has a dynamic dependency on both libbar.so _and_
> libbaz.so.
> 
> Is this expected behavior?  Is there a way of forcing exactly one of
> libfoo.so and libbaz.so to be used?

Works fine for me on x86_64-linux.  You'll notice that I'm not using
gcc to link.  Perhaps something in the way your gcc is invoking the
linker is getting in the way.  It pays to check what gcc is doing by
adding -v to the gcc command line.  It is also worthwhile checking
what you think is going on, by creating a little testcase like the
following.

cat > quux.s <<EOF
 .weak quux
 .data
quux: .byte 0
EOF
cat > quuxref.s <<EOF
 .data
 .dc.a quux
EOF
as -o quux.o quux.s
as -o quuxref.o quuxref.s
ld -shared -o lib1.so quux.o
ld -shared -o lib2.so quux.o
ld -o quux quuxref.o --as-needed lib1.so lib2.so
readelf -aW quux | grep NEEDED
ld: warning: type and size of dynamic symbol `quux' are not defined
ld: warning: cannot find entry symbol _start; defaulting to 0000000000401000
 0x0000000000000001 (NEEDED)             Shared library: [lib1.so]

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: resolving weak symbols.
  2024-03-28 22:58 resolving weak symbols Tom Kacvinsky
  2024-03-30  1:43 ` Alan Modra
@ 2024-04-12 16:01 ` Nick Clifton
  1 sibling, 0 replies; 3+ messages in thread
From: Nick Clifton @ 2024-04-12 16:01 UTC (permalink / raw)
  To: Tom Kacvinsky, Binutils

Hi Tom,

> Suppose I have a static archive libfoo.a that has a weak sym, call it quux.
> 
> And the link line I have is
> 
> gcc -o foo -L. -lfoo -Wl,--as-needed -lbar -lbaz
> 
> Where libbar.so and libbaz.so also have the weak symbol quux.
> 
> Then the executable foo has a dynamic dependency on both libbar.so _and_ libbaz.so.
> 
> Is this expected behavior?  Is there a way of forcing exactly one of libfoo.so and libbaz.so to be used?

Probably not, but I think that we will need a full example (source
files + command lines) to be sure.  It would also help if you could
file this as a potential bug report in the bugzilla system so that
we can track it:  https://sourceware.org/bugzilla/

Cheers
   Nick



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-04-12 16:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-28 22:58 resolving weak symbols Tom Kacvinsky
2024-03-30  1:43 ` Alan Modra
2024-04-12 16:01 ` Nick Clifton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).