BIND-9.3.0

Bruce Dubbs 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
>>application?
>>    
>>
>
>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 
./lib/dns/.libs/libdns.so.20.0.0                   
-rwxr-xr-x    1 root     root        32899 Dec  8 21:58 
./lib/bind9/.libs/libbind9.so.0.0.4
-rwxr-xr-x    1 root     root       264026 Dec  8 21:53 
./lib/isc/.libs/libisc.so.9.1.4
-rwxr-xr-x    1 root     root        32005 Dec  8 21:54 
./lib/isccc/.libs/libisccc.so.0.2.1
-rwxr-xr-x    1 root     root        74076 Dec  8 21:58 
./lib/lwres/.libs/liblwres.so.1.2.1

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
>experience.
>  
>
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.

  -- Bruce









More information about the blfs-dev mailing list