[Zlib-devel] Explicit link to libc

[John Bowler]

From: Enrico Weigelt
>hmm, I guess on GNU that'll happen w/ --no-undefined ?

If you use GNU binutils *and* leave off -lc *and* specify --no-undefined to ld it definitely *should* happen, but the cases I noted in zlib ./configure don't use GNU tools at all, and all the GNU cases use gcc, not ld.

I guess maybe the core point is that doing shared libraries in a portable way is extremely difficult, and this is why 'libtool' exists.  Zlib doesn't use libtool, but that's understandable because libtool itself is not portable: for something as simple as zlib, with no dependencies apart from the runtime the cure may be worse than the disease.

>IMHO there's a global symbol namespace per process, so if the 
>resulting binary is linked against libc, that'll also affect
>the linked-in zlib ... or maybe I'm totally wrong ?

More generally there is a two level namespace of the form module:symbol.  On Windows (which is where this arose, since we're talking about MinGW) zlib can be linked against one 'libc' and the application against another (as discussed previously).

If I've got this correct the behavior of libtool on both Cygwin and MinGW is to disallow shared libraries with unresolved references.  Visual Studio seems to object too, on the pure NT platform, but maybe I just don't know all the options.

In the GNU UN*X world libc is versioned - it contains multiple definitions of the same symbol appropriate to different versions of the library.  Windows does not (so far as I know) support that, instead Windows supports multiple libc DLLs (runtimes; msvcrt.dll etc).  Windows requires more care when complete executables are linked at different times, against different runtime versions; a lot more care!  Both approaches work, whereas using a non-versioned libc (e.g. the BusyBox one) doesn't work in this environment.

Specifying the runtime at link time - by giving the libc or runtime DLL to the linker - ensures that this works.  Otherwise a symbol name like 'fprintf' is ambiguous because it doesn't identify a particular implementation of fprintf(3), quite apart from the fact that the linker may simply fail because it is unresolved.

John Bowler <jbowler at acm.org>