Proliferation of Expat bundled into various packages
may be considered as an unnecessary duplication. Here
is a patch to configuration scripts that provides
uption to demand use of an external Expat library.
This requires an additional m4 macro file, which I
named expat.m4, that is supplied in a separate patch
upload.
To build, you have either to put this file into the
common include directory for aclocal, or provide this
file or a symlink to it in both macros/ and
jabberoo/macros within the Gabber source tree.
Apply this with -p1
Logged In: YES
user_id=9539
I've been pretty busy this summer... sorry about that.
What exactly would be the advantage of dynamically linking?
I think it would lead to more problems than the
slightly-smaller-binary-size would be worth...
Logged In: YES
user_id=19497
Advantage might be the ability to take advantage of improvements in newer version of expat (speed or bug
fix maybe). Isn't this how the included libsigc++ is handled now, only using the packaged version if an
installed version isn't found? If the person is compiling gabber themself I see no reason for there not to
be an option to allow use of a newer version if one is installed. For binary distribution it would porbably be
best to remain static since that would just add another dependency to gabber's rather large list.
Logged In: YES
user_id=9539
Well, except that the changes to expat are (as far as I
know) quite minimal these days. libjudo is fairly closely
tied to expat, and allowing people's installed expat to be
used would only really introduce another variable that could
cause something to go wrong... It's probably more important
that I get jabberoo updated to the new libjudo than that we
keep up with current expat.