Re: Confusion over library names
Lo, on Thursday, December 28, Michael and Ricia Banther did write:
> The ld program supports a -l<n> command line option.
Why are you calling ld directly? g++ should do that for you--especially
with respect to libstdc++ (see below). (Of course, gcc/g++ supports the
same parameter.)
> Playing around with ld, I've discovered that the -l option does not find
> files that have .a or .so in the middle of the filename. It only finds
> files that have one of these strings at the end. So, for instance
> -lstdc++ doesn't find /usr/lib/libstdc++.so.272.
I think libstdc++ is a bad example; you should let g++ link that in
automatically. (In fact, I think one of the only real differences between
g++ and gcc is that g++ links in libstdc++, while gcc doesn't. They use
the extension on the input filename to determine language.)
However, -lcrypt successfully finds /usr/lib/libcrypt.so on my potato
system.
> My questions then:
>
> 1. Am I using the -l option in ld correctly? Is there some way to make it
> recognize library names with .so or .a in the middle of a name?
Yes, you're using it correctly (but you should be using g++ to link in most
cases), and no, I don't think there's a way to get it to recognize library
names with .so or .a in the middle.
> 2. Should I create symlinks ending with .so (or .a) for any library with a
> name of the form lib<n>.so.blah (or lib<n>.a.blah)?
Those should be there for you; see below. Note that they're not always in
the same directory. For instance, /usr/lib/libcrypt.so is a symlink to
/lib/libcrypt.so.1, which is a symlink to the actual binary,
/lib/libcrypt-2.1.3.so.
> 3. Why do the distribution libraries fail to set up these symlinks for me
> when they include other symlinks to give a specific library several names?
The details of symlinks and shared libraries are a bit tricky; see _Linux
Application Development_ by Michael Johnson & Erik Troan for further
details (especially sections 7.4 through 7.6).
However, so far as I know, most of this *should* be set up for you, so long
as you've installed the necessary packages. As an example, consider
libcrypt.so again:
[minbar:~]$ dpkg -S /usr/lib/libcrypt.so
libc6-dev: /usr/lib/libcrypt.so
[minbar:~]$ dpkg -S /lib/libcrypt.so.1
libc6: /lib/libcrypt.so.1
I guess the logic here is that /usr/lib/libcrypt.so is used only when
building new executables, so it belongs in the development package.
Try making sure you've got the necessary -dev packages installed and
linking again.
(Warning: I understand the details of shared library naming conventions far
better than I understand Debian's packaging system, since I'm new to Debian,
though not to Linux. Therefore, you may have to adjust the last few
paragraphs slightly.)
HTH,
Richard
Reply to: