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

Daniel Veillard wrote:

On Thu, Jun 13, 2002 at 02:30:08PM +0100, Gary Pennington 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.

For instance, if I have foo.c:

#include <libxml/parser.h>
   xmlDocPtr doc = NULL;
   doc = xmlNewDoc(BAD_CAST "1.0");
   (void) printf("hello world\n");
   <do things which are completely unrelated to networking>
   return (0);

And I compile it as:

cc -o foo foo.c -I/usr/local/libxml/include/libxml2 -R/usr/local/libxml/sparc/lib -L/usr/local/libxml/sparc/lib -lxml2

That will work. It's the job of the linker to work out the libxml2 uses networking libraries and needs to also link -lsocket (etc) at runtime.

 xmlNewDoc can dereference the socket code. Moreover not all system
have shared library, some don't even have dynamic ones.

This statement is completely opaque to me. If you are saying that it is possible that you may invoke a function in libxml2 that then invokes a function in libsocket, fine. That's the job of the linker.

With respect to older platforms which don't have shared objects, how about --static-libs. That would be a good solution and would allow the more modern platforms to keep things clean whilst still catering for legacy platforms.

i.e. the application is only dependant on lxml2, but the linker has

 The application you shown may have to use the network. If there is
a catalog and the filename you gave is redirected to a network URL
libxml2 will use the ftp/http stack accordingly.

I appreciate that. However, as I said, when libxml2 is built it is linked with the necessary libraries (socket, etc) and there is no need for the application itself to also express this dependancy. Or at least there isn't on Solaris.

worked out (correctly) that libxml2 in turn depends on a number of libraries (e.g. libz, libsocket, etc..)

 Some linkers can't.

I'm intrigued. Which linkers don't support this?

As I said in my earlier mail, I find it hard to believe that you have to specify a libraries dependant libraries when you link an application with the library in order for it to work. What happens if you miss a library out because you don't know about it?

 The make stops complaining about missing symbols. And honnestly
I prefer this to happen at compile time than at run-time !


This is not a big thing. I just wanted to clear up some untidyness that a Solaris customer had brought to my attention. If it causes problems on other platforms or a Solaris specific fix isn't acceptable, then fine.

I'd rather tidy it up, but I know that it's not good to fragment the distribution.

I guess it's my ignorance of other platforms thats showing though here.


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