Fog Creek Software
Discussion Board

obscure GNU libtool question.

As a follow up to our TSR question, here's an obscure GNU programming question. 

This might be a stretch, but I was wondering if anybody here has a good understanding of linking with libtool and glibc.  My Linux app links in two thirdparty libraries.  I want to statically link those libraries, so I don't have to install or depend on those libraries being installed on the client machine.  Basically I want to avoid DLL hell. 

To do this I passed -static-all to libtool at link time.  Great it created a statically linked executable.  The problem is it statically links in glibc as well, and I got some warnings about gethostbyname() not really being static.

I did some research and realized that the DNS subsystem in glibc isn't statically linkable and uses something called NSS to provide a dynamic level of indirection to name services.  I have to admit even after years of Linux admining, I've never messed around with NSS configuration. 

Anyway, now I am willing to compromise.  Statically link in the thirdparty libs and dynamically link in glibc.  Unfortunately I can't figure out what switches libtool requires to do this. 

Any suggestions?

christopher (
Tuesday, July 13, 2004

Or you could use any of the async resolvers out there, I don't think they use NSS properly. (NSS is to make address lookups dynamic, not everybody uses DNS.)

Jonas B.
Tuesday, July 13, 2004

Christopher, I don't know which libtool you are using, but GNU libtool doesn't have a "-static-all" optioon -

Tuesday, July 13, 2004

sorry -all-static

christopher (
Tuesday, July 13, 2004

Maybe a weird idea, but can't you statically link the libs you depend on except glibc into a new library, then dynamically link to that and glibc? To be honest I've never really encountered dll hell on *n*x since libraries tend to be identified by version numbers in the name anyway...

Tuesday, July 13, 2004

You say something along the lines of

g++/gcc <objectfile specs> -static <static libraries specs> -dynamic -lc

{Read the manpage for the specifics of the option names -- I can't recall them offhand.}

Basically the "static" and "dynamic" options affect the next things on the command line until there's another directive the other way.

The other option, if you have the source, is to build the library as a .a instead of a .so and link that -- .a libraries are automatically statically linked.

Katie Lucas
Tuesday, July 13, 2004

Oh yes -- and have the compiler do the linking -- it'll launch ld to do the work, but it adds a whole load of extra configuration options.

Katie Lucas
Tuesday, July 13, 2004

Actually, the analogy of DLL hell on UNIX is where to put the libs:

Put them in "/lib" or "/usr/lib" and the app needs to be installed by root. Not necessarily good.

Put them in the app directory and you can't run the app from somewhere else.

Put them in an arbitrary library directory, and the user has to mess about playing with the LD_LIBRARY_PATH environment variable, which isn't friendly.

Put them in a known directory and have a shell script launch the binary with LD_LIBRARY_PATH set, which is the usual solution, but still isn't fantastic, and now there's even more files to the installation and if you move the installation it breaks...

The best option is to have the app go looking for its own DLLs, using PATH and it's binary's location and so on and then dlopen them, but that's a lot of work and not terribly convenient.

Katie Lucas
Tuesday, July 13, 2004

It's been a little while, but I ran into a very similar problem. My solution was much like what Katie mentioned.

If I can recall properly, it involved -static lib1.a, lib2.a, ... -dynamic -lnostdlib -lgcc

Best of luck.

Tuesday, July 13, 2004

Sometimes Libtool doesn't behave as expected when order-dependent linker flags are added to the link line.  The way around this is to quote the entire series of linker flags, i.e.

-Wl,' -static -l3rdpty1  -l3rdpty2 -dynamic'

Although this will defeat Libtool's nifty linking features that deal with the two thrid party libraries, the 3rd party libs probably weren't built with Libtool anyway.

Another solution: temporarily  remove/rename the shared versions of the libraries you want static.

Robert Boehne
Tuesday, July 13, 2004

Thanks for your help.  I'm on the verge of just ditching libtool.  It seems to be more hassle than it is worth.

> Or you could use any of the async resolvers out there

I thought about that, and I may end up going that route eventually, but I looked at the available options and couldn't find one I liked.  One had a weird GPL variant that I didn't want to use. The second had a license I could use, but required starting a separate daemon process to handle DNS requests.  I wouldn't mind starting a separate process as long as it was forked from the parent.  Ease of installation and administration is a high priority for me.  Personally I think that is one way to get a leg up in the *nix market.

> On DLL hell.

Yes on Linux DLL hell isn't nearly as bad as windows, since DLLs are versioned.  Why uSoft hasn't learned this lesson yet, I'll never understand.  With that said, the reason I want to statically link is to simplify installation and support.  This is a server side application that I accept to be run stand alone, so there isn't much benefit in dynamically linking anyway. 

christopher (
Tuesday, July 13, 2004

*  Recent Topics

*  Fog Creek Home