[MPlayer-dev-eng] [PATCH] directfb -> pkg-config

[Rich Felker]

On Tue, Feb 28, 2006 at 04:19:06AM +0100, Enrico Weigelt wrote:
> * Rich Felker <dalias at aerifal.cx> schrieb:
> 
> <snip>
> 
> > This is because static SDL and Kerberos are incorrectly built. If they
> > need numerous other libraries which the caller is not supposed to know
> > about, these libraries should be _included_ in libSDL.a.
> 
> ... which will end up in duplicate linkages if the caller also 
> links in one of the included libraries ?

No, objects from a .a file are only used if they satisfy an unresolved
symbol. Otherwise they're completely ignored, so only the first one
found will be used.

> <snip>
> 
> > Before pkg-config, it was so difficult to link against such crap 
> > that no one would use it if you released such a monstrosity. 
> 
> Please give us a clear definition of "crap".

Programs with random dependencies on libraries which alter the state
of the calling program in unpredictable ways that violate proper
library design principles and cause random bugs, vulnerabilities, and
overall confusion. Some examples:

- libarts linking in glib2, possibly conflicting with the calling
  program's glib1.
- libSDL linking in libarts, causing the above to happy indirectly.
- libSDL redefining main() and treating the whole calling program as
  an "SDL app" rather than a generic caller
- libalsa secretly forking behind the caller's back and creating nasty
  bugs with child processes that the caller is unaware of
- libalsa (at least in old versions) opening the audio device without
  FD_CLOEXEC, causing deadlock if the caller forks and execs.

...

Of course none of these problems come from pkg-config. What they _are_
representative of, however, is crap that wrecklessly links in lots of
unnecessary libraries and does stuff behind the caller's back in ways
that necessarily lead to bugs. I would go so far as to say that it's
bad practice for any library to depend on another library without a
well-established stable interface, and further that it's absolutely
wrong for a library to do anything that alters the global state of the
caller unless the fact that it does so is explicitly part of the
documented interface.

[ If a library does absolutely need to use another library without a
stable interface, it should import the full source of the needed
library and rename all the interfaces to prevent conflicting with
other versions. ]

Rich