On Tue, Jan 20, 2004 at 12:18:30PM +0300, Vladimir Prus wrote: > Daniel Jacobowitz wrote: > > > > > > > g++ -o lib.so -shared -static-libgcc lib.cpp -Wl,-Bstatic > > > > > > g++ -o app app.cpp lib.so -static-libgcc -Wl,-Bstatic > > > > > > > > What is this trying to accomplish? You're going to get shared > > > > versions of some libraries and dynamic versions of others. > > > > > > This is trying to get static version of all "runtime" libraries: such as > > > libstd++, libc and libgcc, but link to dynamic lib.so > > > > I have no idea if that is possible. I don't think that it is. If you > > link to libc.a, then you will not have an initialized dynamic loader, > > and shared libraries will not be properly loaded. > > Okay. The problem, then, is that libc docs never mention this problem.
It's just an assumption. Dynamic linking can not work unless the dynamic loader is dynamically linked. Honestly, I have no idea what the output of that command is going to look like. > In fact, I could find only the following: > > .... since not many platforms support dynamic > loading in statically linked programs. On platforms without this > capability it is therefore not possible to use this interface in > statically linked programs. The GNU C library has, on ELF platforms, no > problems with dynamic loading in these situations; therefore, this > point is moot. > > Which talks about 'dlopen', I guess. In fact, when I try 'dlopen'ing lib.so, > rather than linking to it, everything works, except for the following > warning: > > /tmp/x/app.cpp:9: warning: Using 'dlopen' in statically linked applications > requires at runtime the shared libraries from the glibc version used for > linking > > So, I've three questions: > > 1. Why is it so that 'dlopen' works but direct linking does not. I though they > use the same mechanism... They don't :) They share a lot of common code, but that's not the same thing. Dynamic linked libraries participate in symbol resolution, for instance. > 2. Why 'dlopen' in static application requires shared libc? The shared library you open, if it is correctly built, will reference shared libc.so.6, causing libc.so.6 to be dlopen'd into your application. If it mismatches the included version of glibc unknown things will happen, and in the past, have happened. > 3. Should not the docs say that static linking to libc is not possible if any > dynamic libraries are used? If you had just statically linked to libc, then the result might have been different. Playing with -Bstatic in this way is not a good way to accomplish it. Try adding a libc.so script in an -L directory, like the existing one, but which references libc.a instead of libc_nonshared.a and libc.so.6. I have no idea what that will cause to happen, either. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
