#61779 closed defect (fixed)
libxslt @1.1.34_2: man xsltproc gives corrupted (uncompiled?) man page
Reported by: | JDLH (Jim DeLaHunt) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.4 |
Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt) | |
Port: | libxslt |
Description
The man page for xsltproc is corrupted, perhaps uncompiled, or compiled for the wrong target.
Steps to reproduce:
% man xsltproc
Observed behaviour:
XSLTPROC(1) xsltproc Manual XSLTPROC(1) NAME xsltproc - command line XSLT processor SYNOPSIS .HP 216u xsltproc [ [ | -V | --version ] [ | -v | --verbose ] [ { | -o | --output } { | FILE | DIRECTORY } ] | --timing | --repeat | --debug | --novalid | --noout | --maxdepth VALUE | --html | --encoding ENCODING | --param PARAMNAME PARAMVALUE | --stringparam PARAMNAME PARAMVALUE | --nonet | --path "PATH(S)" | --load-trace | --catalogs | --xinclude | [ | --profile | --norman ] | --dumpextensions | --nowrite | --nomkdir | --writesubtree PATH | --nodtdattr ] [STYLESHEET] { | XML-FILE... | - } DESCRIPTION .PP xsltproc is a command line tool for applying XSLT stylesheets to XML documents. It is part of libxslt(3), the XSLT C library for GNOME. While it was developed as part of the GNOME project, it can operate independently of the GNOME desktop.
…[rest of man page elided]…
Problems: the spacing is wrong. Directives like .HP 216u and .PP are present in the output.
Expected behaviour: a properly formatted man page.
Change History (12)
comment:1 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Summary: | libxslt @1.1.34_2+universal: man xsltproc gives corrupted (uncompiled?) man page → libxslt @1.1.34_2: man xsltproc gives corrupted (uncompiled?) man page |
---|
comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign added |
---|
It was #56354.
comment:4 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Well it was a memorable problem. And now I'd be very interested to know why we're having it again when I thought I fixed it years ago. I will try to investigate tomorrow.
comment:5 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Or I'll investigate now. Thankfully it's nothing we did: The developers of libxslt made the same mistake in 1.1.34 that we made a couple years ago, mapping the old SourceForge docbook XSL URL to the wrong new CDN URL. See https://gitlab.gnome.org/GNOME/libxslt/-/issues/31. They fixed it by switching back to the old URL but haven't released a new version. We can apply a patch for that in the mean time.
comment:6 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Owner: | set to ryandesign |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:7 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
That worked locally but failed to make a difference on the build system. I see it failed to regenerate xsltproc.1 on the build system but ignored that error. I need to fix whatever's preventing it from regenerating it, and delete the old xsltproc.1 beforehand so that a failure to regenerate it is not ignored.
comment:8 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:9 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
comment:10 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Good grief. In addition to still not regenerating the manpage on current systems, on older systems it said:
dyld: Symbol not found: _xsltMaxVars Referenced from: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_textproc_libxslt/libxslt/work/libxslt-1.1.34/doc/./../xsltproc/xsltproc Expected in: /usr/lib/libxslt.1.dylib
That would be fixed by setting DYLD_LIBRARY_PATH but I don't know right now why it doesn't want to regenerate on newer systems.
comment:11 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Confirmed. The problem is not specific to the universal variant. I think we had a similar problem at some point before, don't remember what port though. I wonder if I can find that...