Re: [xml] Re: The DSO dilemna

[Joel Reed <joelwreed comcast net>]

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:
 
snip

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

<grin>

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.

jr