Currently there is no mechanism for building xdvik against a system installed kpathsea - the tarball includes it's own version of kpathsea and forces you to build against that. This is a major headache for distro packagers since xdvik is not the upstream for kpathsea.
In order to build against a system installed kpathsea when packaging xdvik for Fedora, I had to use the attached patch. But it's worse than that, because the bundled kpathsea library still ends up being compiled because of the file dependencies. I am also attaching the RPM spec file that we use to build xdvik which includes the ugly workarounds for this - basically we have to regenerate the file dependencies during %build.
Use system kpathsea
Spec file for building RPM using system wide kpathsea
Logged In: YES
user_id=1982499
Originator: YES
File Added: xdvik.spec
Logged In: YES
user_id=177175
Originator: NO
[Moving this ticket to 'feature requests']
Attempted to fix this in the CVS version 22.84.14-CVS5. There's still an open issue with kpathsea's libtool which seems to insist on picking a specific version of the library .a file, regardless of the -L option specified via --with-kpathsea-lib=xyz for some strange reason; e.g. in my tests:
-L/tmp/kpathsea/lib -lkpathsea
was expanded to:
-L/tmp/kpathsea/lib /usr/local/lib/libkpathsea.a
Maybe the place of the installed .a file is recorded somewhere in the configuration ...? Also kpathsea's --enable-shared seems broken at least in the texlive 2007 sources, it always compiles the static version, that could be related as well.
This diff makes some changes to configuration scripts in the toplevel and texk dirs which will make it harder to merge back updates from upstream (should probably try to get these diffs into the upstream sources, they shouldn't break the default build).
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 730 days (the time period specified by
the administrator of this Tracker).