so people have apparently been hacking around the issue instead of simply getting perl fixed
gimme something real to work on spanky, i don't have a lib64, so without input i do nothing. is $(get_libdir) nor valid?
$(get_libdir) is valid, but the build or install of perl isnt respecting the options given to it ive looked into perl build system before and everytime ive walked away a broken man
Actually, looking at this more, it appears that it was just baselayout that was broken. I'll investigate more and report back here. Fi anyone has any evidence to prove me wrong, go for it.
i'm going by the CONTENTS of perl which says it installed into /usr/lib $ qlist -e dev-lang/perl | grep ^/usr/lib64 | wc 0 0 0 $ qlist -e dev-lang/perl | grep ^/usr/lib | wc 1469 1469 64521
(In reply to comment #4) > i'm going by the CONTENTS of perl which says it installed into /usr/lib > > $ qlist -e dev-lang/perl | grep ^/usr/lib64 | wc > 0 0 0 > $ qlist -e dev-lang/perl | grep ^/usr/lib | wc > 1469 1469 64521 > Based on which ebuild install? Are we talking 5.8.7 (which should be fixed) or 5.8.6 (which may not be in the tree)?
$ qlist -I -v dev-lang/perl dev-lang/perl-5.8.7-r3 i'll go ahead and re-emerge it now to be sure
Created attachment 77041 [details] current perl-5.8.7-r3/CONTENTS
Created attachment 77042 [details] 9329-perl-5.8.7-r3.log just cvs-ed up to latest tree and emerged perl-5.8.7-r3
hrm, i was forced to debug libperl as it was failing to build on amd64/uClibc and i noticed that -Dlibpth is not being passed correctly config.sh quotes all of its args with '': config_arg1='-des' config_arg2='-Darchname=-linux' config_arg3='-Dcccdlflags=-fPIC' config_arg4='-Dccdlflags=-rdynamic' ... the multilib logic in the ebuild also attempts to use '' to pass a list of lib paths, but this of course breaks and explains all of these random messages in my build log: ./config.sh: line 1019: /lib64: is a directory
Created attachment 77048 [details, diff] libperl-multilib.patch this seems to fix libperl on my machine: $ qlist libperl | grep /usr/lib /usr/lib64/libperl.so.1.5.8 /usr/lib64/libperl.so.1
As requested on #gentoo-perl by mcummings : # grep -c lib64 /var/db/pkg/dev-lang/perl*/CONTENTS 3 # grep lib64 /var/db/pkg/dev-lang/perl*/CONTENTS sym /usr/lib/perl5/5.8.7/x86_64-linux-thread-multi/CORE/libperl.so.1.5.8 -> ../../../../../lib64/libperl.so.1.5.8 1133946648 sym /usr/lib/perl5/5.8.7/x86_64-linux-thread-multi/CORE/libperl.so.1 -> ../../../../../lib64/libperl.so.1.5.8 1133946648 sym /usr/lib/perl5/5.8.7/x86_64-linux-thread-multi/CORE/libperl.so -> ../../../../../lib64/libperl.so.1.5.8 1133946648
your arch isn't getting defined when you build perl according to the CONTENTS - you should never, ever, ever, have /-linux as a dir (should be something like i686-linux, or sparc-linux). myarch is defined by get_abi_CHOST, which is obviously broken on your box, which leads me to suspect that the result of get_libdir isn't much more reliable.
the output of $(get_libdir) is correct regardless of whether my system is broken, the patch i posted is correct read the config.sh file and you'll see that the quoting is all screwed up
(In reply to comment #13) > the output of $(get_libdir) is correct > > regardless of whether my system is broken, the patch i posted is correct > > read the config.sh file and you'll see that the quoting is all screwed up > I saw that - agreed and quickly fixable. But get_abi_CHIOST isn't filling in any values for some reason on your box (either a bad copy of the ebuild, or something else) so this patch only fixes the lib part of the problem (sure, that's what the bug was for :) but not your install of perl.
> I saw that - agreed and quickly fixable. But get_abi_CHIOST isn't filling in > any values for some reason on your box it's because i've been screwing around with my env, it isnt a bug outside of my box
Created attachment 77135 [details] updated libperl ebuild fixes all /usr/lib refs, including the one multiline in spanky's patch
Created attachment 77136 [details] corresponding perl ebuild the other half the perl ebuild itself
Created attachment 77139 [details] new perl CONTENTS the libperl ebuild works for me but my perl ends up with some stuff in /usr/lib
this is all fixed 5.8.8.
confirmed, CONTENTS looks great with 5.8.8 i'm content to let 5.8.8 filter down to stable
