Confused about static link

[Richard Munn]

I have a program that would like to be linked to be totally static (i.e. does not use any shared library). The program must be linked against libc, libX11 and LibXt. What are the correct CC switches and/or ld swicthes to get the correct end result? All my attempts so far seem to still reference shared libraries.

[Rajeev Shukla]

When you compile a program with CC you can specify the library to use with the -l option. Say to use libc use -lm to use libm use -lm. You can specify all in one option like -lX for libX. Now if you want to link with the archive(static) libraries then you have to use -a option i.e
-a archive
or you can change the shared library search path you have all you'r static library somewhere else say in /usr/contrib/lib with -L option

Rajeev

[Richard Munn]

I'm afraid that does not work.
If I use:

cc -Wl,-a,archive -c x1.c
cc -Wl,-a,archive -c x2.c
cc -o x x1.o x2.o -Wl,-a,archive -lXt,-lX11,-lc

I get unsatisfied symbols from ld:

shl_load
shl_unload
shl_findsym

which are to do with shared library loading I think.

[Adam J Markiewicz]

Hi

You assume correct.
These are functions from libdld.sl, which is library to manage dynamic library linking.

However mayby this helps?
man ld

-noshared This option forces the linker to create a fully
archive bound program.


Good luck
Adam

[ranganath ramachandra]

one of those libraries wants to dynamically load a shared library (hence the unsatisfied shl_* symbols). you need -ldld in your link line. you cannot build your a.out fully archived in this situation.

you can suspect libc.a:
nm /usr/lib/libc.a | grep shl_load

[ranganath ramachandra]

one of those libraries wants to dynamically load a shared library (hence the unsatisfied shl_* symbols). you need -ldld in your link line. you cannot build your a.out fully archived in this situation.

you can suspect libc.a:
nm /usr/lib/libc.a | grep shl_load

[ranganath ramachandra]

one of those libraries wants to dynamically load a shared library (hence the unsatisfied shl_* symbols). you need -ldld in your link line. you cannot build your a.out fully archived in this situation.

[ranganath ramachandra]

one of those libraries wants to dynamically load a shared library (hence the unsatisfied shl_* symbols). you need -ldld in your link line. you cannot build your a.out fully archived in this situation.

[ranganath ramachandra]

looks like libc.a is shl_load'ing some shared libraries. you can get over the unsatisfied symbols by adding -ldld to your compile/link line. you cannot make it a fully static link, though.

[ranganath ramachandra]

looks like libc.a is shl_load'ing some shared libraries. you can get over the unsatisfied symbols by adding -ldld to your compile/link line. you cannot make it a fully static link, though.

[ranganath ramachandra]

looks like libc.a is shl_load'ing some shared libraries. you can get over the unsatisfied symbols by adding -ldld to your compile/link line. you cannot make it a fully static link, though.

[Richard Munn]

This seems all a bit bizare to me. What's the point of having a libc.a that's dependant upon shared libraries?

Then again, the programs in /slib should all be static. I assume that most of them are programs linked against libc so how do they get to be non-shared if libc has shared library dependancies?????

[Umapathy S]

Richard,
As far as I know, libc.a doesnt depend on any other shared library. It shouldnt be also.

For your problem, check the executable with chatr or ldd. Use the option as Adam said. This will work fine.

HTH
Umapathy

[Adam J Markiewicz]

Hi

One comment which would fit here.

The difference between shared library and archive library (I realized it also reading some comment from other smarter guy, but I cannot recall the thread):

When you use shared library everything from it must be attached, as every program is allowed to use anything that was declared for it.

However archive libaries are resolved at compile time and thats the moment when everything is clear - what is used by the programmer, and what is not.
Basing on this knowledge linker is able to attach only really needed code, not always the whole library.

What I'm going to say is that:
Are there any references to shl_ functions inside libc.a? So what? It doesn't mean any of it will be really needed or linked to your executable.

Good luck
Adam

P.S.: Thanks to that Smart Someone who said it explicity in that some thread. I guess it was unbeatable A. Clay and the problem was related to the fact that size of executable compiled as shared version was bigger than executable compiled as compliete stand-alone (like yours).

[Adam J Markiewicz]

...

but the bigger problem is I cannot find archive versions of X libraries.
If you want to use them it looks like you have no choice.

Good luck
Adam

[Mike Stroyan · Accepted solution]

libXt.a uses setlocale. If you check "man setlocale" you will find a
warning that it has a dependency on libdld.sl. (It uses shl_load to
bring in libraries that provide locale-specific functions.)

[Richard Munn]

Adam & Mike were right.

After pulling the program apart, with the Xt, Xlib and libc functions seperated, nothing I was using in libc requires a shared library
so the -Wl,-shared,-a,archive options built a fully static image. The culprit appears to be Xlib. Xlib references setlocale and it appears there is virtually no Xlib function you can call without requiring the load of a shared library.

You cannot even use -l:libdld.sl. The link works with this but the first Xlib call you hit (like XOpenDisplay) causes a segmentation fault. So it appears than under HP-UX it's shared or it's nothing!