Menu

#80 RFE: build against a system installed kpathsea

closed
None
5
2010-09-20
2008-01-19
No

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.

Discussion

  • Jonathan Underwood

    Use system kpathsea

     
  • Jonathan Underwood

    Spec file for building RPM using system wide kpathsea

     
  • Jonathan Underwood

    Logged In: YES
    user_id=1982499
    Originator: YES

    File Added: xdvik.spec

     
  • Stefan Ulrich

    Stefan Ulrich - 2008-02-18
    • assigned_to: nobody --> stefanulrich
    • status: open --> pending
     
  • Stefan Ulrich

    Stefan Ulrich - 2008-02-18

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

     
  • SourceForge Robot

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

     
  • SourceForge Robot

    • status: pending --> closed
     

Log in to post a comment.

MongoDB Logo MongoDB