Bug 68044 - Bad path in Ghostscript
Bug#: 68044 Product:  Gentoo Linux Version: unspecified Platform: x86
OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2
Resolution: TEST-REQUEST Assigned To: printing@gentoo.org Reported By: neil@cfconline.co.uk
Component: Applications
URL: 
Summary: Bad path in Ghostscript
Keywords:  
Status Whiteboard: 
Opened: 2004-10-18 12:35 0000
Description:   Opened: 2004-10-18 12:35 0000 
Emerging from scratch several times, I get that the search path in Ghostscript
has the original Gentoo build directory embedded within it, concequently it
cannot find some of it's files when I try to run it:

-------------------------------------------------------

Search path:
   . :
   /var/tmp/portage/ghostscript-7.07.1-r7/image//usr/share/ghostscript/7.07/lib
:
   /usr/share/fonts/default/ghostscript/ : /usr/share/fonts :
   /usr/share/fonts/ttf/zh_TW : /usr/share/fonts/ttf/zh_CN :
   /usr/share/fonts/arphicfonts : /usr/share/fonts/ttf/korean/baekmuk :
   /usr/share/fonts/baekmuk-fonts : /usr/X11R6/lib/X11/fonts/truetype :
   /usr/share/fonts/kochi-substitute
For more information, see
/var/tmp/portage/ghostscript-7.07.1-r7/image//usr/share/ghostscript/7.07/doc/Use.htm.

-------------------------------------------------------

Everything works fine when I "cd /usr/share/ghostscript/7.07" since it can then
find the files.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

------- Comment #1 From chris-gentoo@drspirograph.com 2004-10-23 20:37:57 0000 ------- 
I can confirm this also
gs --help gives

Search path:
   . :
   /tmp/portage/portage/ghostscript-7.07.1-r7/image//usr/share/ghostscript/7.07/lib :
   /usr/share/fonts/default/ghostscript/ : /usr/share/fonts :
   /usr/share/fonts/ttf/zh_TW : /usr/share/fonts/ttf/zh_CN :
   /usr/share/fonts/arphicfonts : /usr/share/fonts/ttf/korean/baekmuk :
   /usr/share/fonts/baekmuk-fonts : /usr/X11R6/lib/X11/fonts/truetype :
   /usr/share/fonts/kochi-substitute
For more information, see /tmp/portage/portage/ghostscript-7.07.1-r7/image//usr/share/ghostscript/7.07/doc/Use.htm.

------- Comment #2 From Heinrich Wendel (RETIRED) 2004-10-24 17:04:57 0000 ------- 
remerging ghostscript will help

------- Comment #3 From Neil Moore 2004-10-28 12:30:10 0000 ------- 
Even after re-merging, I have this same problem.

gs -help:

---------------------------------------------

Search path:
   . :
   /var/tmp/portage/ghostscript-7.07.1-r7/image//usr/share/ghostscript/7.07/lib :
   /usr/share/fonts/default/ghostscript/ : /usr/share/fonts :
   /usr/share/fonts/ttf/zh_TW : /usr/share/fonts/ttf/zh_CN :
   /usr/share/fonts/arphicfonts : /usr/share/fonts/ttf/korean/baekmuk :
   /usr/share/fonts/baekmuk-fonts : /usr/X11R6/lib/X11/fonts/truetype :
   /usr/share/fonts/kochi-substitute
For more information, see /var/tmp/portage/ghostscript-7.07.1-r7/image//usr/share/ghostscript/7.07/doc/Use.htm.

---------------------------------------------

------- Comment #4 From Mamoru KOMACHI (RETIRED) 2004-10-30 06:35:59 0000 ------- 
Please paste the output of `emerge info`.

------- Comment #5 From Neil Moore 2004-10-30 06:51:00 0000 ------- 
Output of `emerge info`:

Portage 2.0.51-r2 (default-x86-1.4, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.6.8.1-ck4 i686)
=================================================================
System uname: 2.6.8.1-ck4 i686 Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz
Gentoo Base System version 1.5.3
Autoconf: sys-devel/autoconf-2.59-r4
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.14.90.0.8-r1
Headers:  sys-kernel/linux-headers-2.4.19-r1,sys-kernel/linux-headers-2.4.21-r1
Libtools: sys-devel/libtool-1.4.3-r4
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -march=pentium4 -funroll-loops -pipe -fprefetch-loop-arrays"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=pentium4 -funroll-loops -pipe -fprefetch-loop-arrays"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache distlocks sandbox"
GENTOO_MIRRORS="http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/home/[myuser]/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X aalib acpi alsa apm arts avi berkdb bitmap-fonts cdr crypt cups dvd dvdr encode esd f77 foomaticdb gdbm gif gnupg gphoto2 gpm gtk gtk2 imap imlib java jpeg libg++ libwww mad mikmod mmx motif mpeg msn ncurses nls oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline sdl slang spell sse ssl svga tcltk tcpd tetex truetype usb usb2 x86 xinerama xml2 xmms xv zlib"

------- Comment #6 From Mamoru KOMACHI (RETIRED) 2004-10-30 07:38:40 0000 ------- 
I couldn't reproduce the bug with almost the same environemnt :(

Please define PORT_LOGDIR and attach the log of `emerge ghostscript` 
created in that directory.

------- Comment #7 From Neil Moore 2004-10-30 08:24:07 0000 ------- 
Created an attachment (id=42911) [details]
emerge log

Here is the log of an emerge

------- Comment #8 From Mamoru KOMACHI (RETIRED) 2004-10-30 11:20:47 0000 ------- 
Thanks, the log helped me finding the bug. I reproduced it with 
MAKEOPTS="-j2". I think I fixed the bug with the latest -r7, 
so please test it and report back whether it works.

------- Comment #9 From Mike Kleshov 2004-11-01 02:36:40 0000 ------- 
Same problem here, with the latest -r7 ebuild. I put MAKEOPTS="j1" into my
make.conf and it didn't make any difference. Still getting
"/var/tmp/portage/ghostscript-7.07.1-r7/image//usr/share/ghostscript/7.07/lib"
as output of "gs -?"
I could generate some logs if that would be helpful.

------- Comment #10 From Mamoru KOMACHI (RETIRED) 2004-11-01 04:59:25 0000 ------- 
All right Mike, I modified -r7 a little more. If that doesn't solve the issue, 
please attach an emerge log.

------- Comment #11 From Mike Kleshov 2004-11-01 06:18:03 0000 ------- 
Created an attachment (id=43070) [details]
gzipped emerge log

Didn't work. Did 'emerge sync' and checked that ebuild file was updated then
'PORT_LOGDIR="/root" emerge ghostscript', and 'gs -?' still gives me
'/var/tmp/portage/ghostscript-7.07.1-r7/image//usr/share/ghostscript/7.07/lib'.

Attaching gzipped emerge log.

------- Comment #12 From Mamoru KOMACHI (RETIRED) 2004-11-01 09:53:33 0000 ------- 
Okay, thanks for testing. I added DESTDIR patch and
this should solve the issue. Please run emerge sync 
and try again.

------- Comment #13 From Mike Kleshov 2004-11-01 10:23:21 0000 ------- 
Actually I think I've found a typo in the ebuild file. Line number 66 needs to
be:
sed -i -e 's:$(gsdatadir)/lib:/usr/share/ghostscript/7.07/$(get_libdir):'\
rather than the original:
sed -i -e "s:\$\(gsdatadir\)/lib:/usr/share/ghostscript/7.07/$(get_libdir):"\
After this change I reemerged ghostscript and the problem was gone.

------- Comment #14 From Mamoru KOMACHI (RETIRED) 2004-11-01 11:03:17 0000 ------- 
Mike, it should not be so. $(get_libdir) is Portage function,
not a Makefile variable. If you change that to single quote,
it will be expanded to null string.

------- Comment #15 From Mike Kleshov 2004-11-01 11:09:46 0000 ------- 
I was a bit too quick with my previous post. I'll try to explain.
I still believe that the line
sed -i -e "s:\$\(gsdatadir\)/lib:/usr/share/ghostscript/7.07/$(get_libdir):"\
does not do what it is supposed to do. I am not familiar with script programming and the syntax of sed, so I experimented a little. I extracted Makefile.in from espgs-7.07.1-source.tar.bz2 and ran the command
sed -i -e "s:\$\(gsdatadir\)/lib:/usr/share/ghostscript/7.07/$(get_libdir):" Makefile.in
in shell. After that I compared the resulting Makefile.in with the original. The files were identical. Apparently the match-and-raplace command didn't match anything.
Then I ran the command
sed -i -e 's:$(gsdatadir)/lib:/usr/share/ghostscript/7.07/$(get_libdir):' Makefile.in
in the shell. This time it did modify the file. So I concluded that the double quotes and backslashes were the problem and modified the ebuild. After reemerging ghostscript the 'gs -?' gave me
/usr/share/ghostscript/7.07/
which is not quite what we want. So I modified the above mentioned line again:
sed -i -e 's:$(gsdatadir)/lib:/usr/share/ghostscript/7.07/lib:' \
and reemerged ghostscript again. This time 'gs -?' gave the expected result:
/usr/share/ghostscript/7.07/lib
I don't know what the significance of $(get_libdir) is. Anyway, I found a fix that works for me. Hope this helps.

------- Comment #16 From Neil Moore 2004-11-01 14:20:27 0000 ------- 
Thanks for all your help. That solves the problem for me, hopefully everyone
else gets their problem solved too.

------- Comment #17 From Mamoru KOMACHI (RETIRED) 2004-11-02 08:18:08 0000 ------- 
Mike: right, 

sed -i -e "s:\$\(gsdatadir\)/lib:/usr/share/ghostscript/7.07/$(get_libdir):" Makefile.in

should be

sed -i -e "s:\$(gsdatadir)/lib:/usr/share/ghostscript/7.07/$(get_libdir):" Makefile.in

$(get_libdir) is a function for 64bit environment. kugelfang: will you have a look
at it, as you seem to change the sed line? It was actually

-       sed -i -e 's:$(gsdatadir)/lib:/usr/share/ghostscript/7.07/lib:' Makefile.in
+       sed -i -e "s:\$\(gsdatadir\)/lib:/usr/share/ghostscript/7.07/$(get_libdir):" \
+       Makefile.in || die "sed failed"

before.