James Robertson jwrober at
Thu Dec 9 06:47:44 PST 2004

Randy McMurchy wrote:
> Bruce Dubbs
>>Randy McMurchy wrote:
>>>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.
> Yes, I agree. As I mentioned in my first message, I didn't
> see the need for them to be executable, but the large
> majority of them are, so I thought there was some valid
> reason for this.
>>>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.
> I don't find it unusual at all that one may be running the
> named daemon and then use dig or nslookup or some other BIND
> utility. In fact, this seems quite common.
>>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.
> Most likely an error in configure that identifies the shared
> libs as being the default. The build instructions specifically
> say you must use the --with-libtool to build the shared libs.
>>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
> If you say so.  :-)
>>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.
> It really doesn't matter to me. I simply posted the original
> message as a topic of discussion as I didn't really have a
> *good* handle on the pros and cons.
> Thanks for your insight, Bruce.

Since we have the BIND daemon on one page and the utils on another 
completely seperate from each other, why not have two methods.  Use 
static for the daemon (if that is default) and dynamic for the utils.

My $0.02  Keep up the good work!


More information about the blfs-dev mailing list