Re: [xml] Generating a correct xml2-config for use with --libs

[Gary Pennington <Gary Pennington sun com>]

Justin Fletcher wrote:

> In message <3D089E60 2040700 sun com>
>          Gary Pennington <Gary Pennington sun com> wrote:
>
>  
>
> > Stefan Kost wrote:
> >
> >    
> >
> > > Hi Gary,
> > >
> > > but libxml2 does networking (see nanoftp and the likes).
> > >
> > > Stefan
> > >      
> > I know, which is why libxml2 links with the appropriate libraries
> > (-lsocket etc). However, that doesn't mean that any application which
> > links with libxml2 must also link with the networking libraries.
> >    
>
> In the first place, if you link a library (xml) against another library
> (sockets) then you have added a chunk to that former library which is
> unnecessary duplication.
I'm not sure I understand your point. What you describe sounds like what 
would happen with static linking, but not with dynamic linking. You 
would simply be adding a dependancy to libxml2 to an existing dynamic 
library. Sure there may be an entry in a linker table, but you wouldn't 
be adding in any executable code.

What is the point you are making? The library (libxml2) is already 
linked against multiple libraries (-lsocket, etc.). You aren't saying 
that linking a library with other libraries is bad are you? That 
statement would take some defending.

> In the second place, some linkers complain if you attempt to link a library
> which contains symbols already provided in another library - ie linking your
> program that uses sockets against a libxml linked with sockets will have two
> sets of symbols for the things in sockets. This produces problems for some
> linkers who will refuse to link such things because it cannot be certain that
> the symbols in both the files are identical, and in any case it causes
> greater problems when the core library (sockets) is updated as libraries
> which have been linked against it must be relinked (regardless of whether
> you're keeping binary compatibility).
Again, you are describing behaviour which is what you would expect with 
static linking. With dynamic linking, this would not be a problem as the 
symbols would be resolved out of the same library by the runtime linker. 
However, you would always have a problem if you defined the same symbol 
in multiple locations. That can't be fixed whatever you do.

Gary

> This issue is very similar to that of assuming that the linker will 'know'
> what to do with duplicated symbols as was the case with the original
> versions of xsldebug.
>
>