[prev in list] [next in list] [prev in thread] [next in thread] 

List:       flightgear-devel
Subject:    Re: [Flightgear-devel]
From:       Mathias =?iso-8859-1?q?Fr=F6hlich?= <Mathias.Froehlich () gmx ! net>
Date:       2011-09-24 12:16:42
Message-ID: 201109241416.42837.Mathias.Froehlich () gmx ! net
[Download RAW message or body]


Hi,

On Saturday, September 24, 2011 10:38:28 James Turner wrote:
> On 24 Sep 2011, at 09:04, Mathias Fröhlich wrote:
> > Yes, I can see that libGL and libz is just pulled indirectly which no
> > longer works on very new linux ld variants.
> 
> Arrgh, really? That's news to me.

I do not know the real version where this was introduced, nor do I know if it 
was introduced with increments.
But if your shared object (library or executable) directly depends on some 
symbols in an other shared library, you need to explicitly link against this 
library. If you do only indirectly depend on something indirect linking is 
also sufficient.

This is what you really want to have.
For example:

Say, libfontconfig is something you need but libfontconfig.so depends for some 
internals of reading its own configuration files on libexpat. In that case you 
just need to link -lfontconfig.
But if you also need expat for your own xml stuff, you need to link also 
against -lexpat. It is *not* sufficient to say, expat is already pulled by 
fontconfig so I don't need that anymore.

This behavour already fixes the following case:
Now think what happens when the fontconfig guys would decide to use libxml2 for 
their config files. Since the xml reader nowhere appears in fontconfigs api it is 
safe to do that without an api change. Then with this scheme, fontconfig pulls 
itself a different xml library. And, since you already link yourself explicitly 
against libexpat, your symbols are still resolved too.
Which kind of xml parser fontconfig uses is something you do not want to know 
about and is something you no longer see under the hood and you can no longer 
make use of this by accident.

Greetings

Mathias

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[prev in list] [next in list] [prev in thread] [next in thread]