Bug 90401 – dev-lang/wml-2.0.9 installs perl libs in unreachable location

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Martin Ehmsen (RETIRED) 2005-04-25 11:09:56 UTC]

I have an amd64 machine, but I don't think the problem is specific to that arch, but feel free to mark it as such.
After emerging (this is tried on a fresh amd64 2005.0 install) perl cannot find the perl libs wml installs (perl is called from wml).
# wml
Can't locate File/PathConvert.pm in @INC (@INC contains: /usr/lib/wml/perl/lib/x86_64-linux /usr/lib/wml/perl/lib /etc/perl /usr/lib/perl5/site_perl/5.8.6/x86_64-linux /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.6/x86_64-linux /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/x86_64-linux /usr/lib/perl5/5.8.6 /usr/local/lib/site_perl .) at /usr/bin/wml line 52.
BEGIN failed--compilation aborted at /usr/bin/wml line 52.

The reason is that wml comes with several perl libs of it's own (some of them have newer versions in portage, others dosen't exist in portage), and these libs is installed in a location where perl cannot find them (@INC).

The files are installed in the following locations:

/usr/lib64/perl/lib
/usr/lib64/perl/lib/HTML
/usr/lib64/perl/lib/HTML/Clean.pm
/usr/lib64/perl/lib/File
/usr/lib64/perl/lib/File/PathConvert.pm
/usr/lib64/perl/lib/auto
/usr/lib64/perl/lib/auto/HTML
/usr/lib64/perl/lib/auto/HTML/Clean
/usr/lib64/perl/lib/auto/HTML/Clean/autosplit.ix
/usr/lib64/perl/lib/auto/Getopt
/usr/lib64/perl/lib/auto/Getopt/Long
/usr/lib64/perl/lib/auto/Getopt/Long/GetOptions.al
/usr/lib64/perl/lib/auto/Getopt/Long/config.al
/usr/lib64/perl/lib/auto/Getopt/Long/autosplit.ix
/usr/lib64/perl/lib/auto/Getopt/Long/FindOption.al
/usr/lib64/perl/lib/auto/Getopt/Long/Croak.al
/usr/lib64/perl/lib/auto/Getopt/Long/Configure.al
/usr/lib64/perl/lib/auto/Image
/usr/lib64/perl/lib/auto/Image/Size
/usr/lib64/perl/lib/auto/Image/Size/psdsize.al
/usr/lib64/perl/lib/auto/Image/Size/jpegsize.al
/usr/lib64/perl/lib/auto/Image/Size/gifsize.al
/usr/lib64/perl/lib/auto/Image/Size/bmpsize.al
/usr/lib64/perl/lib/auto/Image/Size/swfsize.al
/usr/lib64/perl/lib/auto/Image/Size/autosplit.ix
/usr/lib64/perl/lib/auto/Image/Size/tiffsize.al
/usr/lib64/perl/lib/auto/Image/Size/xbmsize.al
/usr/lib64/perl/lib/auto/Image/Size/xpmsize.al
/usr/lib64/perl/lib/auto/Image/Size/ppmsize.al
/usr/lib64/perl/lib/auto/Image/Size/pngsize.al
/usr/lib64/perl/lib/Getopt
/usr/lib64/perl/lib/Getopt/Long.pm
/usr/lib64/perl/lib/Image
/usr/lib64/perl/lib/Image/Size.pm
/usr/lib64/perl/lib/x86_64-linux
/usr/lib64/perl/lib/x86_64-linux/IO
/usr/lib64/perl/lib/x86_64-linux/IO/Dir.pm
/usr/lib64/perl/lib/x86_64-linux/IO/Seekable.pm
/usr/lib64/perl/lib/x86_64-linux/IO/Pipe.pm
/usr/lib64/perl/lib/x86_64-linux/IO/Socket
/usr/lib64/perl/lib/x86_64-linux/IO/Socket/UNIX.pm
/usr/lib64/perl/lib/x86_64-linux/IO/Socket/INET.pm
/usr/lib64/perl/lib/x86_64-linux/IO/Poll.pm
/usr/lib64/perl/lib/x86_64-linux/IO/Handle.pm
/usr/lib64/perl/lib/x86_64-linux/IO/Socket.pm
/usr/lib64/perl/lib/x86_64-linux/IO/File.pm
/usr/lib64/perl/lib/x86_64-linux/IO/Select.pm
/usr/lib64/perl/lib/x86_64-linux/Bit
/usr/lib64/perl/lib/x86_64-linux/Bit/Vector.pm
/usr/lib64/perl/lib/x86_64-linux/WML
/usr/lib64/perl/lib/x86_64-linux/WML/GD.pm
/usr/lib64/perl/lib/x86_64-linux/Term
/usr/lib64/perl/lib/x86_64-linux/Term/ReadKey.pm
/usr/lib64/perl/lib/x86_64-linux/auto
/usr/lib64/perl/lib/x86_64-linux/auto/IO
/usr/lib64/perl/lib/x86_64-linux/auto/IO/IO.bs
/usr/lib64/perl/lib/x86_64-linux/auto/IO/IO.so
/usr/lib64/perl/lib/x86_64-linux/auto/IO/.packlist
/usr/lib64/perl/lib/x86_64-linux/auto/Bit
/usr/lib64/perl/lib/x86_64-linux/auto/Bit/Vector
/usr/lib64/perl/lib/x86_64-linux/auto/Bit/Vector/Vector.bs
/usr/lib64/perl/lib/x86_64-linux/auto/Bit/Vector/Vector.so
/usr/lib64/perl/lib/x86_64-linux/auto/Bit/Vector/.packlist
/usr/lib64/perl/lib/x86_64-linux/auto/WML
/usr/lib64/perl/lib/x86_64-linux/auto/WML/GD
/usr/lib64/perl/lib/x86_64-linux/auto/WML/GD/GD.bs
/usr/lib64/perl/lib/x86_64-linux/auto/WML/GD/GD.so
/usr/lib64/perl/lib/x86_64-linux/auto/WML/GD/autosplit.ix
/usr/lib64/perl/lib/x86_64-linux/auto/WML/GD/.packlist
/usr/lib64/perl/lib/x86_64-linux/auto/HTML
/usr/lib64/perl/lib/x86_64-linux/auto/HTML/Clean
/usr/lib64/perl/lib/x86_64-linux/auto/HTML/Clean/.packlist
/usr/lib64/perl/lib/x86_64-linux/auto/File
/usr/lib64/perl/lib/x86_64-linux/auto/File/PathConvert
/usr/lib64/perl/lib/x86_64-linux/auto/File/PathConvert/.packlist
/usr/lib64/perl/lib/x86_64-linux/auto/Term
/usr/lib64/perl/lib/x86_64-linux/auto/Term/ReadKey
/usr/lib64/perl/lib/x86_64-linux/auto/Term/ReadKey/autosplit.ix
/usr/lib64/perl/lib/x86_64-linux/auto/Term/ReadKey/.packlist
/usr/lib64/perl/lib/x86_64-linux/auto/Term/ReadKey/ReadKey.bs
/usr/lib64/perl/lib/x86_64-linux/auto/Term/ReadKey/ReadKey.so
/usr/lib64/perl/lib/x86_64-linux/auto/Getopt
/usr/lib64/perl/lib/x86_64-linux/auto/Getopt/Long
/usr/lib64/perl/lib/x86_64-linux/auto/Getopt/Long/.packlist
/usr/lib64/perl/lib/x86_64-linux/auto/Image
/usr/lib64/perl/lib/x86_64-linux/auto/Image/Size
/usr/lib64/perl/lib/x86_64-linux/auto/Image/Size/.packlist
/usr/lib64/perl/lib/x86_64-linux/IO.pm

Is there a way to fix the install location of these libs?!?
Ideally wml should have its ancient perl libs installed in a seperate location and should be able to use them from there. That approach wouldn't conflict with the libs that have a newer version in portage.

Reproducible: Always
Steps to Reproduce:




Portage 2.0.51.20-r4 (default-linux/amd64/2005.0, gcc-3.4.3-20050110,
glibc-2.3.5-r0, 2.6.12-rc3 x86_64)
=================================================================
System uname: 2.6.12-rc3 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.6.11
ccache version 2.4 [disabled]
dev-lang/python:     2.3.5
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r8
sys-devel/libtool:   1.5.14
virtual/os-headers:  2.6.11
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=athlon64"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-O2 -pipe -march=athlon64"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox strict"
GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo
http://ftp.snt.utwente.nl/pub/os/linux/gentoo"
MAKEOPTS=""
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X Xaw3d acpi aim alsa auctex audiofile avi berkdb bitmap-fonts
cdparanoia cdr crypt cups curl emacs emacs-w3 encode esd fam flac font-server
fortran freetype gd gif gimpprint glade gtk gtk2 imagemagick imap imlib imlib2
jabber java jp2 jpeg libwww lzw lzw-tiff mad maildir mailwrapper md5sum motif
mp3 mpeg mpeg4 nas ncurses network nls nntp nptl nvidia ogg oggvorbis opengl
opens oss pam perl png pnp ppds python qt readline rtc sdl slang ssl tcpd tetex
threads tiff truetype truetype-fonts type1-fonts unicode usb utf8 vanilla vorbis
xml2 xpm xrandr xv zlib"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

[Comment 1 Carsten Lohrke (RETIRED) 2005-04-25 12:02:11 UTC]

We have no maintainer here. Would the perl herd have a look at it, please?

[Comment 2 Michael Cummings (RETIRED) 2005-04-29 18:04:20 UTC]

This is looking like it might be an amd64 problem - on my box it all goes under /usr/lib/wml/* (or /usr/bin/, but *NEVER* under /usr/lib/perl/

[Comment 3 Michael Cummings (RETIRED) 2005-04-29 19:07:16 UTC]

Where did the following dirs get made?
data  exec  include  perl

on an x86, they would have gone under /usr/lib/wml/

FWIW, you shouldn't be overwriting perl's installs - that would be in /usr/lib(64?)/perl5, not perl

amd64 folks - how did blubb get it working to keyword it?

[Comment 4 Simon Stelling (RETIRED) 2005-04-30 01:37:14 UTC]

I can confirm that, I guess I just forgot to execute the binary when testing :(
this is pretty obscure, i can't see a reason why it should install to the wrong locations on a specific arch...

[Comment 5 Martin Ehmsen (RETIRED) 2005-05-01 04:08:30 UTC]

Created attachment 57714 [details]
Files installed by wml on amd64

If I do an "equery files wml" I get the attached output.
Anything else I can do to help?

[Comment 6 Michael Cummings (RETIRED) 2005-05-01 08:43:01 UTC]

amd folks - are you looking at this or should we be? worst case we can just hack and slash - it's all plain text, a bunch of mv and dosed's later and it should be ok for /usr/lib64 :) 'Course, there's probably a nicer way...

[Comment 7 Herbie Hopkins (RETIRED) 2005-05-04 06:05:25 UTC]

The problem seems to be a that their configure scirpt has very weird (broken) interpretation of the --libdir option, defaults to /usr/lib/wml and is set to /usr/lib64 on multilib systems by econf. Following the case of other perl modules /usr/lib/wml is the correct location for these files even on multilib systems as they are arch independant (except for the perl modules which go in an arch dependant subdir). I have therefore just appended --libdir=/usr/lib/wml as an option to econf and am calling this FIXED.