bdubbs at swbell.net
Wed Dec 8 20:37:45 PST 2004
Randy McMurchy wrote:
>Bruce Dubbs wrote:
>>Randy McMurchy wrote:
>>>Anyone have any comments with any of these issues?
>>Well .a and .la files shouldn't be executable. The .so files should be
>>executable. The documentation and threaded versions should be
>>installed, but I'm not sure about the need for shared libraries. Do we
>>want to do it on principle or are there specific advantages for this
>I didn't mention the .a libraries. :-)
I was just trying to be complete.
>I mentioned the shared
>libraries and accompanying .la files. As far as .la files being
>executable, I don't see why they should be either. But it must
>be a libtool thing because of the over 300 .la files I have on
>one of my systems here, only 18 of them are 644 permissions. All
>others are 755.
My system has a combination of 644 and 755 permissions too, but look at
the files! They are text data files, not executable. I believe the
executable bit is set incorrectly in all the cases where it is set.
>As far as shared versus static libs, I'm not sure if any packages
>build against BIND9 libs, but there are some out there that look
>for the BIND8 resolver library. Requires passing --enable-libbind
>to configure to build it, though.
Nothing in BLFS uses libbind. We don't do bind8 anyway.
>With the 12 binaries built by the BIND package it would seem to
>be a performance thing if there were shared libs, as all of the
>binaries link against the shared libs. Seems like loading a bunch
>of redundant code if one uses the bind utilities frequently.
It would be highly unusual for these binaries to be used simultaneously.
The only thing I see is that the shared library may save some disk space.
Answering my own question, I went ahead and downloaded 9.3 and tried
compiling, but it disn't make the .so files without the --with-libtool,
even though the --help says dynamic libraries are built by default.
Perhaps this is an error in configure or the Makefile.
This is what I found:
-rwxr-xr-x 1 root root 1187991 Dec 8 21:57
-rwxr-xr-x 1 root root 32899 Dec 8 21:58
-rwxr-xr-x 1 root root 264026 Dec 8 21:53
-rwxr-xr-x 1 root root 32005 Dec 8 21:54
-rwxr-xr-x 1 root root 74076 Dec 8 21:58
These are the libraries I found. I didn't check if all the files used
all the libraries, but I suspect most do.
In the case of bind, multiple files using the same library would rarely
be invoked, so there would be little gain from loading time or memory
space. The only issue would be how much space is saved on disk, so this
looks like about 1.5*(#executables - 1), or about 15MB.
>But I am no authority of dynamic versus static libraries. If
>someone would care to enlighten me, I would appreciate the learning
Shared libraries generally are more efficient. If multiple programs
need the same library, only one copy needs to be loaded into memory for
each different app thus saving memory space. Loading time is also
reduced if the library is already in memory. The shared library code
doesn't have to be stored multiple times with each app, saving disk space.
I'm not really arguing against using a shared library. Since configure
says its the default and we save 15MB of disk space, we might as well
build it that way.
More information about the blfs-dev