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

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

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.


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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]