Common error message: "Can't locate MRTG_lib.pm"
Install puts libs in /usr/lib64/mrtg2 but /usr/lib/mrtg2 is added to @INC.
Can be temporarily fixed by creating a symlink:
ln -s /usr/lib64/mrtg2 /usr/lib/mrtg2
/usr/lib should be a relative symlink to lib64 on a native amd64 system. @INC is therefor correct.
Well it isn't on my system. It's a dir and it contains files. I think you are confusing with /lib that is symlinked to /lib64.
tg3 usr # ls -lgGi
1032069 drwxr-xr-x 2 12288 Aug 15 09:19 bin
981325 drwxr-xr-x 49 4096 Aug 15 09:19 include
915787 drwxr-xr-x 9 4096 Aug 15 09:35 lib
899362 drwxr-xr-x 18 8192 Aug 15 09:24 lib64
915777 drwxr-xr-x 4 4096 Aug 9 13:03 libexec
983442 drwxr-xr-x 10 4096 Aug 11 13:19 local
1001672 drwxr-xr-x 156 4096 Aug 8 12:37 portage
967558 drwxr-xr-x 2 4096 Aug 14 13:10 sbin
983462 drwxr-xr-x 54 4096 Aug 15 09:19 share
967556 drwxr-xr-x 3 4096 Aug 8 02:27 src
899802 lrwxrwxrwx 1 8 Aug 7 06:36 tmp -> /var/tmp
934454 drwxr-xr-x 6 4096 Feb 21 23:39 x86_64-pc-linux-gnu
Alan, please provide your emerge --info. lib should in fact really be a symlink to lib64, but that doesn't change the fact that this bug is valid.
That's strange though, why is /lib a symlink and /usr/lib not? But that probably is a different problem.
Portage 2.1-r2 (hardened/amd64, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-hardened-r11 x86_64)
System uname: 2.6.16-hardened-r11 x86_64 AMD Opteron(tm) Processor 246
Gentoo Base System version 1.6.15
app-admin/eselect-compiler: [Not Present]
dev-util/ccache: [Not Present]
dev-util/confcache: [Not Present]
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
CFLAGS="-O3 -pipe -fomit-frame-pointer -march=opteron"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer -march=opteron"
FEATURES="autoconfig distlocks metadata-transfer sfperms strict"
GENTOO_MIRRORS="ftp://ftp.gtlib.gatech.edu/pub/gentoo http://www.gtlib.gatech.edu/pub/gentoo "
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
USE="amd64 apache berkdb crypt dlloader gd hardened hardenedphp justify mysql nls pam pcre php pic pop3d readline session sockets ssl tcpd tls unicode userlocales vda xorg zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux userland_GNU"
Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Where exactly is the bug now? That Perl include paths are set to generic libdirs?
(In reply to comment #5)
> Where exactly is the bug now?
That perl does not honour $(get_libdir).
(In reply to comment #4)
> That's strange though, why is /lib a symlink and /usr/lib not? But that
> probably is a different problem.
> emerge --info:
> Portage 2.1-r2 (hardened/amd64, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-hardened-r11
Ah, yes, hardened. It's a known problem with the hardened stages. I recommend you to replace it with a link, otherwise you'll see all kinds of strange brokiness
Yeah I eventually figured that out, but still either mrtg shoul be installing to lib or perl should be including lib64. Seems more coherent if both do the same thing, and, I figure, since the lib symlink is there to make things work in a multilib environment, then maybe mrtg should be installing to lib?
Just supposing though...
2.11.1 isn't even in the tree anymore, but the newer (2.14.x, 2.15.x) ones seem to have the same behaviour.
Is this issue really mrtg specific? Including ../lib seems like a sane thing to do since it _should_ be a symlink to lib64 (in this specific case), or is there any information i've overlooked?
(In reply to comment #8)
> Is this issue really mrtg specific? Including ../lib seems like a sane thing to
> do since it _should_ be a symlink to lib64 (in this specific case), or is there
> any information i've overlooked?
More perl-specific. Note that lib is not always a link to lib64, so it's generally NOT save. However, in this case, it doesn't really matter one way or the other.
net-analyzer/mrtg-2.16.1 the newest version in portage works fine. this version isn't anymore in portage-tree.
(In reply to comment #10)
> net-analyzer/mrtg-2.16.1 the newest version in portage works fine. this version
> isn't anymore in portage-tree.
So closing the bug