Bug 6760 - error on gstreamer with USE="doc"
|
Bug#:
6760
|
Product: Gentoo Linux
|
Version: 1.3
|
Platform: x86
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: nick@capital-internet.net
|
Reported By: spider@gentoo.org
|
|
Component: Applications
|
|
|
URL:
|
|
Summary: error on gstreamer with USE="doc"
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2002-08-20 03:55 0000
|
make[3]: Entering directory
`/mnt/reiser/portage/gstreamer-0.4.0-r1/work/gstreamer-0.4.0/docs/manual'
fig2dev -Lpng filter-element-multi.fig filter-element-multi.png
make[3]: fig2dev: Command not found
make[3]: *** [filter-element-multi.png] Error 127
I cant figure out whats wrong with my gstreamer :/
is transfig emerged spider?
epm -ql transfig
<SNIP>
/usr/X11R6/bin/fig2dev
/usr/X11R6/bin/fig2ps2tex
/usr/X11R6/bin/fig2ps2tex.sh
</SNIP>
Seemant is right, fig2dev is what you need Spider,
Rigo
Yes, I've got fig2dev installed :/
seems I can't get this to work.
reassigning to bug-wranglers
*** Bug 8089 has been marked as a duplicate of this bug. ***
Interesting. I get a different fig2dev error:
make[3]: Entering directory
`/var/tmp/portage/gstreamer-0.4.0-r1/work/gstreamer-0.4.0/docs/manual'
fig2dev -Lpng bin-element-ghost.fig bin-element-ghost.png
fig2dev -Lpng bin-element.fig bin-element.png
Unknown device: png16m
Unknown device: png16m
fig2dev: broken pipe (GhostScript aborted?)
*Sigh* Looks like gs is compiled w/o png16m support. Tossing to raker
now that he's a gs expert! (/me crosses fingers)
this now works for me with gstreamer 0.4.1
With gstreamer version 0.4.1 I get the same
error as Grant Goodyear in Comment #6.
I am running the latest ghostscript (7.05.5 - currently masked) and I get
through the png conversions without a problem.
I get an error here though...
<snip>
fig2dev -Lpng queue.fig queue.png
fig2dev -Lpng sink-element.fig sink-element.png
fig2dev -Lpng src-element.fig src-element.png
fig2dev -Lpng state-diagram.fig state-diagram.png
fig2dev -Lpng thread.fig thread.png
rm -f *.html
rm -f -r gstreamer-manual
mkdir gstreamer-manual
cp magic-png magic
xsltproc ./../xsl/html.xsl gstreamer-manual.xml
warning: failed to load external
entity "file:///usr/share/sgml/docbook/yelp/docbook.0/xhtml/chunk.xsl"
compilation error: file ./../xsl/html.xsl line 10 element import
xsl:import : unable to load
http://docbook.sourceforge.net/release/xsl/1.50.0/xhtml/chunk.xsl
make[3]: *** [gstreamer-manual] Error 5
make[3]: Leaving directory `/var/tmp/portage/gstreamer-0.4.1/work/gstreamer-
0.4.1/docs/manual'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/gstreamer-0.4.1/work/gstreamer-
0.4.1/docs'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/gstreamer-0.4.1/work/gstreamer-
0.4.1'
make: *** [all] Error 2
!!! ERROR: The ebuild did not complete successfully.
!!! Function src_compile, Line -123, Exitcode 2
!!! compile failed
</snip>
warning: failed to load external
entity "file:///usr/share/sgml/docbook/yelp/docbook.0/xhtml/chunk.xsl"
This file is actually on the system
as /usr/share/sgml/docbook/yelp/docbook/html/chunk.xsl
I modified html.xsl in the gstreamer source to reference the proper chunk.xsl
file. It now gets past that point.
It is now failing on lots of declarations of what seem to be xml elements
created by the gstreamer people and then a final bang here...
<snip>
./html2xml.py ../libs/html
make[4]: Leaving directory `/var/tmp/portage/gstreamer-0.4.0-r1/work/gstreamer-
0.4.0/docs/gst'
./html2xml.py ../gst/html
sed 's@base=""@base="/usr/share/gtk-doc/html/gstreamer-libs"@g' html.devhelp >
gstreamer-libs.devhelp
perl -i -p -e 's/name="html"/name="gstreamer-libs"/' gstreamer-libs.devhelp
rm html.devhelp
sed 's@base=""@base="/usr/share/gtk-doc/html/gstreamer"@g' html.devhelp >
gstreamer.devhelp
sed: can't read html.devhelp: No such file or directory
make[3]: *** [gstreamer.devhelp] Error 2
make[3]: Leaving directory `/var/tmp/portage/gstreamer-0.4.0-r1/work/gstreamer-
0.4.0/docs/devhelp'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/gstreamer-0.4.0-r1/work/gstreamer-
0.4.0/docs'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/gstreamer-0.4.0-r1/work/gstreamer-
0.4.0'
make: *** [all] Error 2
!!! ERROR: The ebuild did not complete successfully.
!!! Function src_compile, Line -123, Exitcode 2
!!! compile failed
</snip>
html.devhelp has shown up missing on both the 0.4.0-r1 and the 0.4.1 ebuilds...
I then patched ${S}/docs/devhelp/Makefile.in. I commented out the html.devhelp
refrences and just let perl process the gstreamer-libs.devhelp. The ebuild now
finishes installing and emerges successfully.
I have added the patch and new ebuild as gstreamer-0.4.1-r1. Please emerge the
lateset ghostscript (7.05.5) and the latest gstreamer (0.4.1-r1) and test.
gstreamer-0.4.1-r1 and ghostscript-7.05.5 fixed that "doc" bug here. Thanks.
Cool. The ebuild has been unmasked.
May be unrelated but I now get a sandbox violation with the doc USE setting with
0.4.1-r2:
mkdir -p --
/var/tmp/portage/gstreamer-0.4.1-r2/image//usr/share/gtk-doc/html/gstreamer-libs
-- Installing ./html/book1.html
-- Installing ./html/gstreamer-libs-gstcolorspace.html
-- Installing ./html/gstreamer-libs-gstgetbits.html
-- Installing ./html/gstreamer-libs-gstidct.html
-- Installing ./html/gstreamer-libs-gstputbits.html
-- Installing ./html/gstreamer-libs-gstriff.html
-- Installing ./html/gstreamer-libs-gstvideoscale.html
-- Installing ./html/gstreamer-libs.html
-- Installing ./html/index.sgml
-- Fixing Crossreferences
ACCESS DENIED open_wr: /usr/share/gtk-doc/html/gstreamer-libs/book1.html.new
Can't open /usr/share/gtk-doc/html/gstreamer-libs/book1.html: Permission denied
at /usr/bin/gtkdoc-fixxref line 134.
make[3]: Leaving directory
`/var/tmp/portage/gstreamer-0.4.1-r2/work/gstreamer-0.4.1/docs/libs'
make[2]: Leaving directory
`/var/tmp/portage/gstreamer-0.4.1-r2/work/gstreamer-0.4.1/docs/libs'
Package installs fine if sandbox is turned off. Should I file a seperate bug or
is this related to recent work?
I have just done a 'USE="doc" emerge gstreamer' without a problem. I am on an
up to date gcc-3.2 system.
What version of gcc and portage are you using?
hm.. documentation generation seems to work now, but :::
-- Installing ./html/gstreamer-libs-gstvideoscale.html
-- Installing ./html/gstreamer-libs.html
-- Installing ./html/index.sgml
-- Fixing Crossreferences
ACCESS DENIED open_wr:
/usr/share/gtk-doc/html/gstreamer-libs/gstreamer-libs-gstriff.html.new
Can't open /usr/share/gtk-doc/html/gstreamer-libs/gstreamer-libs-gstriff.html:
Permission denied at /usr/bin/gtkdoc-fixxref line 134.
make[3]: Leaving directory
`/mnt/build/portage/gstreamer-0.4.1-r2/work/gstreamer-0.4.1/docs/libs'
The png conversion bug is there again.
This is on a freshly installed system with
gstreamer 0.4.1-r2 and ghostscript 7.05.5.
Part from the output:
make[3]: Entering directory
`/var/tmp/portage/gstreamer-0.4.1-r2/work/gstreamer-0.4.1/docs/manual'
fig2dev -Lpng bin-element.fig bin-element.png
fig2dev -Lpng bin-element-ghost.fig bin-element-ghost.png
Unknown device: png16m
fig2dev: broken pipe (GhostScript aborted?)
command was: gs -q -dSAFER -sDEVICE=png16m -r80 -g577x192
-sOutputFile=bin-element.png -
make[3]: *** [bin-element.png] Error 1
make[3]: *** Waiting for unfinished jobs....
Unknown device: png16m
fig2dev: broken pipe (GhostScript aborted?)
command was: gs -q -dSAFER -sDEVICE=png16m -r80 -g577x192
-sOutputFile=bin-element-ghost.png
>>> media-libs/gstreamer-0.4.1-r2 merged.
>>> Recording media-libs/gstreamer in "world" favorites file...
<snip>
ns1 portage # emerge -s ghostscript libpng
Searching...
[ Results for search key : ghostscript ]
[ Applications found : 1 ]
* app-text/ghostscript
Latest version available: 7.05.5
Latest version installed: 7.05.5
Homepage: http://www.easysw.com/
Description: ESP Ghostscript -- an enhanced version of GNU Ghostscript
with better printer support
Searching...
[ Results for search key : libpng ]
[ Applications found : 1 ]
* media-libs/libpng
Latest version available: 1.2.4
Latest version installed: 1.2.4
Homepage: http://www.libpng.org/
Description: libpng
My conversions went without any errors...
emerge rsync
emerge libpng
emerge clean
emerge ghostscript
Maybe ghostscript is not aware of png's abilities?
--- Unknown device: png16m ---
This is just a guess. If it doesn't work for you please don't flame me :)
Although I have media-libs/libpng-1.2.5 installed,
ghostscript's configure test does not see it:
....
checking for local png library source... no
checking for png_check_sig in -lpng... no
configure: disabling png output devices
....
and hence build without png support.
Here the respective part of config.log:
configure:4245: checking for local png library source
configure:4260: result: no
configure:4262: checking for png_check_sig in -lpng
configure:4295: i686-pc-linux-gnu-gcc -o conftest -march=athlon-xp -O3
-mfpmath=sse -pipe conftest.c -lpng -lm >&5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference
to `deflate'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference
to `inflate'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference
to `inflateInit_'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference
to `crc32'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference
to `deflateInit2_'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference
to `inflateReset'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference
to `deflateReset'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference
to `inflateEnd'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference
to `deflateEnd'
collect2: ld returned 1 exit status
From the ChangeLog of libpng I read that libpng
stoped since version 1.2.5 to link against zlib.
This is the cause of missing libpng support of gs
when using the newest png lib.
I have added a patch to ghostscript-7.05.5 which should allow libpng to be
detected properly.
Please test and let me know. I have verified it working even with the newest..
still marked unstable... libpng-1.2.5
Yes, the patch works fine. :-)