Re: Forcing symbol resolution in lib rather than bin
On 2005-08-19 20:13, Jonathon McKitrick [EMAIL PROTECTED] wrote: I have a binary that links to a shared object library. That .so calls a routine in an archive library (.a). When I link the main app with -lar-a it works fine, even though the function is actually called in the .so. But when I link the .so with -lar-a, the linker doesn't resolve the symbol! So, here's the call graph: bin -- shared -- archive If I link bin to shared and archive, it works. But if I link shared to archive, and then bin to shared, it doesn't, even though the shared object calls the archived function, rather than bin. What basic link concept am I missing here? Strange. How are you building these libraries and the program? I've uploaded a minimal test at: http://people.freebsd.org/~keramida/files/jcm-lib.tar.gz This contains three parts: libfoo/ which defines libfoo_init() and builds as a non-shared libfoo.a libbar/ which defines libbar_init() and calls libfoo_init() foobar/ a program that links with libbar.so and calls only libbar_init() Here's the output of ldd on the foobar binary and the output of running the foobar program: # flame:/tmp/jcm-lib/foobar$ LD_LIBRARY_PATH=`pwd`/../libbar ldd foobar # foobar: # libbar.so.1 = /tmp/jcm-lib/foobar/../libbar/libbar.so.1 (0x80062a000) # libc.so.6 = /lib/libc.so.6 (0x80072b000) # flame:/tmp/jcm-lib/foobar$ LD_LIBRARY_PATH=`pwd`/../libbar ./foobar # libfoo initialized at 0x80062a8a0 # libbar initialized at 0x4004e4 # flame:/tmp/jcm-lib/foobar$ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing symbol resolution in lib rather than bin
On Fri, Aug 19, 2005 at 10:47:48PM +0300, Giorgos Keramidas wrote: : # flame:/tmp/jcm-lib/foobar$ LD_LIBRARY_PATH=`pwd`/../libbar ./foobar : # libfoo initialized at 0x80062a8a0 : # libbar initialized at 0x4004e4 : # flame:/tmp/jcm-lib/foobar$ Hmmm. I'm using my own makefile setup rather than the standard one. I know you're a big fan of bsd.xxx.mk ;-) Doesn't ld *statically* link code from .a archives? Jonathon McKitrick -- Hoppiness is a good beer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing symbol resolution in lib rather than bin
On 2005-08-19 21:03, Jonathon McKitrick [EMAIL PROTECTED] wrote: On Fri, Aug 19, 2005 at 10:47:48PM +0300, Giorgos Keramidas wrote: : # flame:/tmp/jcm-lib/foobar$ LD_LIBRARY_PATH=`pwd`/../libbar ./foobar : # libfoo initialized at 0x80062a8a0 : # libbar initialized at 0x4004e4 : # flame:/tmp/jcm-lib/foobar$ Hmmm. I'm using my own makefile setup rather than the standard one. I know you're a big fan of bsd.xxx.mk ;-) Doesn't ld *statically* link code from .a archives? 'statically' is such an overloaded term I prefer to avoid using it. The C linker will include the body of functions defined in non-shared libraries into every shared object that references them, AFAIK. This is obvious if you run nm(1) on libbar.so of the example above, because the libfoo_init() function is listed as 'T'. I think that's what you want by making the libfoo.a library non-shared in the first place. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing symbol resolution in lib rather than bin
On Fri, Aug 19, 2005 at 11:14:40PM +0300, Giorgos Keramidas wrote:
: Doesn't ld *statically* link code from .a archives?
:
: 'statically' is such an overloaded term I prefer to avoid using it.
:
: The C linker will include the body of functions defined in non-shared
: libraries into every shared object that references them, AFAIK. This is
: obvious if you run nm(1) on libbar.so of the example above, because the
: libfoo_init() function is listed as 'T'. I think that's what you want
: by making the libfoo.a library non-shared in the first place.
I can see from nm(1) that the function I want is there ('T'). And reading
about ld(1) talks about the '-(' option for searching the .a archives until
there are no unresolved symbols. But it still doesn't find mine unless I
link it with the binary, not the calling shared object.
Jonathon McKitrick
--
Hoppiness is a good beer.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing symbol resolution in lib rather than bin
On Fri, Aug 19, 2005 at 11:14:40PM +0300, Giorgos Keramidas wrote: : On 2005-08-19 21:03, Jonathon McKitrick [EMAIL PROTECTED] wrote: : On Fri, Aug 19, 2005 at 10:47:48PM +0300, Giorgos Keramidas wrote: : : # flame:/tmp/jcm-lib/foobar$ LD_LIBRARY_PATH=`pwd`/../libbar ./foobar : : # libfoo initialized at 0x80062a8a0 : : # libbar initialized at 0x4004e4 : : # flame:/tmp/jcm-lib/foobar$ : : Hmmm. I'm using my own makefile setup rather than the standard one. I know : you're a big fan of bsd.xxx.mk ;-) : : Doesn't ld *statically* link code from .a archives? : : 'statically' is such an overloaded term I prefer to avoid using it. : : The C linker will include the body of functions defined in non-shared : libraries into every shared object that references them, AFAIK. This is : obvious if you run nm(1) on libbar.so of the example above, because the : libfoo_init() function is listed as 'T'. I think that's what you want : by making the libfoo.a library non-shared in the first place. Got it! I recalled something des or phk wrote me a while ago, then I skimmed the manpage again. I have to put the .a files AFTER the object files where the unresolved symbol is found. Jonathon McKitrick -- Hoppiness is a good beer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing symbol resolution in lib rather than bin
On 2005-08-19 21:19, Jonathon McKitrick [EMAIL PROTECTED] wrote:
On Fri, Aug 19, 2005 at 11:14:40PM +0300, Giorgos Keramidas wrote:
: Doesn't ld *statically* link code from .a archives?
:
: 'statically' is such an overloaded term I prefer to avoid using it.
:
: The C linker will include the body of functions defined in non-shared
: libraries into every shared object that references them, AFAIK. This is
: obvious if you run nm(1) on libbar.so of the example above, because the
: libfoo_init() function is listed as 'T'. I think that's what you want
: by making the libfoo.a library non-shared in the first place.
I can see from nm(1) that the function I want is there ('T'). And reading
about ld(1) talks about the '-(' option for searching the .a archives until
there are no unresolved symbols. But it still doesn't find mine unless I
link it with the binary, not the calling shared object.
I think I'll have to see a minimal example that reproduces the problem.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing symbol resolution in lib rather than bin
On 2005-08-19 21:26, Jonathon McKitrick [EMAIL PROTECTED] wrote: Got it! I recalled something des or phk wrote me a while ago, then I skimmed the manpage again. I have to put the .a files AFTER the object files where the unresolved symbol is found. Ah! Yes, of course. I didn't realize you were doing that, because I never saw the build commands. Glad it's fixed now :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing symbol resolution in lib rather than bin
On Fri, Aug 19, 2005 at 11:29:26PM +0300, Giorgos Keramidas wrote: : On 2005-08-19 21:26, Jonathon McKitrick [EMAIL PROTECTED] wrote: : : Got it! I recalled something des or phk wrote me a while ago, then I skimmed : the manpage again. I have to put the .a files AFTER the object files where : the unresolved symbol is found. : : Ah! Yes, of course. I didn't realize you were doing that, because I : never saw the build commands. : : Glad it's fixed now :) It just looks so... so ugly without the object at the *end* of the line... ;-) Jonathon McKitrick -- Hoppiness is a good beer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
