Re: [xml] Re: The DSO dilemna

On Fri, Dec 31, 2004 at 04:12:06AM -0500, Daniel Veillard wrote:
On Thu, Dec 30, 2004 at 06:02:58PM -0500, Joel Reed wrote:
On Thu, Dec 30, 2004 at 04:44:43PM -0500, Daniel Veillard wrote:

here's my preferred solution:

  thanks Joel to put your suggestions forward !

1) xmlmodule.h would be roughly what it is now

  IMHO we should just add the flags options to xmlModuleOpen signature.
Even if we don't implement it right now, I think it makes sense though 
apparently ltdl.c doesn't allow to pass the options ...

ok, will do.

2) xmlmodule.c would use libltdl DSO API to implement 
   xmlModuleOpen, xmlModuleClose, etc.


3) we would not include ltdl.{c,h} with libxml2, not use awk scripts
   to hack the ltdl apis, etc. but would instead require libltdl
   to be installed if module support is enabled. if you want module
   support, libltdl must be installed.

  This is the most controversial point. It is clean in the sense that
if available on the platform we benefit from the update. But I'm afraid it
will be a mess on exotic platforms, and even on linux. For example right
now it's provided by libtool on my installation. But libtool is part of the
developpement environment not of the runtime platform. So if I ship libxml2
compiled that way, it will require to install libttool on target boxes which
should not have development tools. 

we could just tell them to switch to debian. 


all kidding aside, anyway we can get fedora/redhat to emulate
debian here?

does this work for everyone? (fingers crossed)

  We can make this a configuration flag or option, --with-sys-ldtl ...
which if activated will try to do what you suggest and if not found or
not activated will fallback to a locally modified copy. This is very
similar to the current approach taken for the trio library. Except I
will be very tempted to use the local copy even on Linux. The point
being that if for some reason we don't embed the latest version users
still have the option to use their version they know work for them in
their specific environment.
  I'm fine doing the mess of embedding the local copy and adding the
special configure option if you provide the configure lookup and the
ldtl based version.  And if we can't pass the flags to xmlModuleOpen
then too bad but it should not stop us from trying that approach.

ok, i can do this. you're not suggesting we awk ltdl to 
change the exported symbol names though (i think). while creative, 
i cringe at the thought of doing that.


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