[Zlib-devel] Explicit link to libc

[Enrico Weigelt]

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

> ><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>
> 
> Because the link of the DLL and the final link of the app using 
> that DLL are done at different times in physically distinct 
> locations. Between the two links 'libc' can be upgraded to a 
> new version.

Of course, the toolchain has to fit the target system. The major
problem IMHO is that two incompatible libraries can share the
the same name - this should never happen, but does due the lack
of QM ;-p

The major problem w/ libraries IMHO is that developers often
break ABIs (or even APIs) within between (even minor!) versions
w/o making that thing a _new_ library (with its own name). So
all the fundemental assumptions of dynamic libraries (eg. 
dependency model, etc) totally break down.

To get out of that mess, I'd declare some basic rules (which 
actually are my primary constraints for all my projects):

* each software module (aka library, etc) has a clearly 
  defined interface, using its own namespace (eg. proper
  prefixes, etc)
* newer versions may extend the existing interface, but NEVER
  break the existing one (so old apps always fit the new lib)
* interface extensions should always have a really good reason
  (think carefully if it's not time to create a new library
  ontop of the existing one)
* for the compile process, libraries are referenced via symbolic
  names, which are transformed to the actual one by either
  the toolchain (pkgconfig + friends) - which also includes 
  header files, etc !
* libraries may NOT change the control flow, unless there's
  a DAMN good reason and that's _clearly_ documented
* when it comes to more complex things (frameworks, etc), 
  think _really_ carefully if it wouldn't be better solved 
  in an external service (see glibc-nss, pam, etc, etc)

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