Re: static linking of C++ apps
On Sun, Aug 19, 2001 at 08:53:52PM +0400, Alexander Kotelnikov wrote:
> >>>>> On Sun, 19 Aug 2001 18:21:15 +1000, Hamish Moffatt <hamish@debian.org> said:
>
> Hamish> I'm trying to compile a C++ app statically, to give a binary to someone
> Hamish> who wants to use it on a cutdown system without all of the libraries
> Hamish> (the Linux Router Project). The app links against libcrypt and libpthread.
> Hamish> When I add -static to the link command, I just get lots of unresolved
> Hamish> symbol errors; it links and runs fine without -static.
>
> Hamish> Here's the error. Can anyone help?
>
> Hamish> thanks,
> Hamish> Hamish
>
> Hamish> g++ -static -lcrypt -lpthread aprsd.o utils.o history.o rf.o serial.o cpqueue.o aprsString.o mic_e.o queryResp.o dupCheck.o crc32.o validate.o -o aprsd
>
> First your objects should _be_ follow by the libraries.
> If it does not help, second: try to exchange -lcrypt and -lpthread, or pass
> "/usr/lib/libpthread.a /usr/lib/libcrypt.a" (or visa versa :)) instead
> of "-static -lcrypt -lpthread".
>
> The order of compiler arguments metters, when you link
> staticly. Actually I'd appreciate if somebody could tell me what this
> order should be.
The order should be references followed by code. So if you have an object file
foo.o, which has an undefined reference to pthread_create, you should use the
order "foo.o -lpthread". This way, the linker sees the reference, and gets the
definition from libpthread. If you use "-lpthread foo.o", the linker processes
libpthread before seeing the reference in foo.o, so the corresponding function
is omitted. That is probably what happened above, combined with the fact that
shared libraries have dependency information while static libraries do not.
The most complex case is where you have mutually referencing shared libraries,
in which case you must use (I think): -lfoo -lbar -lfoo. Though I think GNU
ld's --start-group/--end-group options can sometimes non-portably simplify
those cases.
--
- mdz
Reply to: