Alan Mackenzie
29-09-2005, 07:53 AM
Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote on Wed, 21 Sep 2005
09:50:31 -0700:
> Alan Mackenzie <acm@muc.de> writes:
>> A bit of grepping through my /lib directory turns up the file
>> "libdl.so.1.9.9" which does indeed contain the string "dlopen".
> That is in fact the library in which dlopen() and friends are normally
> found. However, the linker will not look in that file: there should
> also be a symlink lidbl.so -> libdl.so.1.9.9, which is probably
> missing.
There was a symlink libdl.so.1 pointing to it. Sorry, I should have
mentioned that.
>> However, running nm libdl.so.1.9.9 returns the message "nm:
>> libdl.so.1.9.9: no symbols". This suggests to me that this library is
>> corrupt. Is this the case or have I misunderstood something?
> This library has been stripped, but it is probably not corrupt.
> What does "nm -D libdl.so.1.9.9 | grep dlopen" tell ?
000006d0 T _dlopen
000006d0 W dlopen
Let me guess: this probably means the library is fine, but because the
symbols have been stripped, it's no good for linking with (only running).
>> Am I missing something important here? (Apart from the fact that I
>> should have upgraded several centuries ago. ;-)
> You probably are not installing glibc-devel packages, but you need
> them if you are going to do any development on that box.
>> Would rebuilding this library from the source be the best way of going
>> forward?
> Not unless you can't find glibc-devel packages.
I think I've found them. In /usr/i486-linux-libc6/lib I have libdl.so.2.
(This is _not_ a symbolic link.) If I run
nm libdl.so.2 | grep dlopen
, I get
00000fe0 T dlopen
00000fa0 t dlopen_doit
.. So I tweaked my Makefile, adding "-L/usr/i486-linux-libc6/lib" to the
LDFLAGS macro. This didn't make any difference - the linker _still_
couldn't find dlopen and friends.
I then took the failed linker call from the screen, pasted it in, adding
an explicit -ldl, as follows:
gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o \
sshconnect2.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib \
-L/usr/i486-linux-libc6/lib -lssh -lopenbsd-compat -lcrypto -lbsd -lz -ldl
^^^^
This linked without error. Why does "-L/i486-linux-libc6/lib" not enable
the linker to find libdl.so.2 itself?
I'd just to love to read all about this in a fantastic manual somewhere.
A tutorial manual, that is, one that says things like "if you get
unsatisfied references while linking, check the following things .....".
The best I've found one on my system is "The Linux GCC Howto" from May
1999. This, although very helpful, doesn't seem to be this tutorial.
Are there any such manuals?
For a second time, thanks in advance!
> Cheers,
--
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").
09:50:31 -0700:
> Alan Mackenzie <acm@muc.de> writes:
>> A bit of grepping through my /lib directory turns up the file
>> "libdl.so.1.9.9" which does indeed contain the string "dlopen".
> That is in fact the library in which dlopen() and friends are normally
> found. However, the linker will not look in that file: there should
> also be a symlink lidbl.so -> libdl.so.1.9.9, which is probably
> missing.
There was a symlink libdl.so.1 pointing to it. Sorry, I should have
mentioned that.
>> However, running nm libdl.so.1.9.9 returns the message "nm:
>> libdl.so.1.9.9: no symbols". This suggests to me that this library is
>> corrupt. Is this the case or have I misunderstood something?
> This library has been stripped, but it is probably not corrupt.
> What does "nm -D libdl.so.1.9.9 | grep dlopen" tell ?
000006d0 T _dlopen
000006d0 W dlopen
Let me guess: this probably means the library is fine, but because the
symbols have been stripped, it's no good for linking with (only running).
>> Am I missing something important here? (Apart from the fact that I
>> should have upgraded several centuries ago. ;-)
> You probably are not installing glibc-devel packages, but you need
> them if you are going to do any development on that box.
>> Would rebuilding this library from the source be the best way of going
>> forward?
> Not unless you can't find glibc-devel packages.
I think I've found them. In /usr/i486-linux-libc6/lib I have libdl.so.2.
(This is _not_ a symbolic link.) If I run
nm libdl.so.2 | grep dlopen
, I get
00000fe0 T dlopen
00000fa0 t dlopen_doit
.. So I tweaked my Makefile, adding "-L/usr/i486-linux-libc6/lib" to the
LDFLAGS macro. This didn't make any difference - the linker _still_
couldn't find dlopen and friends.
I then took the failed linker call from the screen, pasted it in, adding
an explicit -ldl, as follows:
gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o \
sshconnect2.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib \
-L/usr/i486-linux-libc6/lib -lssh -lopenbsd-compat -lcrypto -lbsd -lz -ldl
^^^^
This linked without error. Why does "-L/i486-linux-libc6/lib" not enable
the linker to find libdl.so.2 itself?
I'd just to love to read all about this in a fantastic manual somewhere.
A tutorial manual, that is, one that says things like "if you get
unsatisfied references while linking, check the following things .....".
The best I've found one on my system is "The Linux GCC Howto" from May
1999. This, although very helpful, doesn't seem to be this tutorial.
Are there any such manuals?
For a second time, thanks in advance!
> Cheers,
--
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").