Re: link sqlite against dietlibc

Thus spake Michael Graßl ([email protected]):
> Yeah that was what i tried and it compiled with warnings but now i
> have the Problem that it want link the whole app togehter because it
> seems to miss libdl and pthread allthough  i add them with
> "-ldl....". whats going wrong at the linking process?

libdl is not available when you link statically.
The whole idea of libdl is that you link dynamically, not statically.

You can either patch sqlite to not depend on dlopen and friends, or use
the experimental dynamic dietlibc (make dyn).

> gcc -nostdlib -static -L/usr/lib/diet/lib-x86_64
> /usr/lib/diet/lib-x86_64/start.o -Wall -ggdb3 -o browse2.cgi
> browse.o sqlite3.o gui.o filter.o content.o render.o -lpthread -ldl
> -isystem /usr/lib/diet/include -D__dietlibc__
> /usr/lib/diet/lib-x86_64/libc.a -lgcc
> sqlite3.o: In function `closePendingFds':
> /var/dev/sqlite3.c:23204: warning: >>> your multithreaded
> code uses errno! <<<

This is a VERY bad sign.  It means you did not compile multithreaded
code with -D_REENTRANT.  This will probably fail at runtime, possibly in
mysterious and hard to reproduce ways.

> sqlite3.o: In function `unixDlOpen':
> /var/dev/sqlite3.c:27217: warning: Using 'dlopen' in statically
> linked applications requires at runtime the shared libraries from
> the glibc version used for linking

This means the linker tried to link in libdl from glibc, which tells you
that using libdl with static linking is not a concept that makes sense
in the first place.

Felix