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
