[Zlib-devel] Explicit link to libc

[Enrico Weigelt]

* John Bowler <jbowler at frontiernet.net> schrieb:

Hi,

> 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.

Ah, now I remember again ... the "gcc" command (which is just a 
frontend to the actual toolchain programs) automatically adds 
the proper libc (aka "-lc") ld the command line when it calls 
ld - that's why you can easily produce a ready2run executable 
from a simple .c file w/o additional options (when no other 
libs are needed).

> I guess maybe the core point is that doing shared libraries 
> in a portable way is extremely difficult, and this is why 
> 'libtool' exists.  

Well, but libtool isn't what I'd consider a clean design :P
For example, it just acts as a filter between traditional
toolchain commands and the actual ones, rewriting parameters
in quite dubios ways. It's no abstraction at all.

That's one of the reasons why I wrote "unitool" some years ago:
it has an very simple syntax (list of keywords + values) which
specify the task on a quite high level (eg. "c-compile sourcefile
X to object file Y using symbols [...]) and derives all the 
platform / toolchain specific stuff on that - these are now 
completely hidden from the developer. Unitool also handles 
.la files and other things. 

BTW: it is also the underlying toolchain abstraction in TreeBuild
(what the treebuild.xml file is for)

> 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).

<naive>
Why can that happen at all ? (assuming we're taking about dynamic
linking). Wouldn't this be exactly the major reason, why the 
toolchain should decide which libc to link against ?
</naive>

> In the GNU UN*X world libc is versioned - it contains multiple 
> definitions of the same symbol appropriate to different versions 
> of the library. 

I guess this is one of the things which makes it so fat (despite the 
fact that it contains a lot of stuff, I'd never put into a libc).
If it would be small - and contain only the fundamental things needed
for program startup, we simply could have several completely 
separate libc's, each executable could use another one. This also 
should reduce the amount of version conflicts dramatically.

Of course, that would mean a HUGE change, not just in libc, but the
whole toolchain (at least some additional linker intelligence)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------