| Summary: | perl doesnt respect lib64 and such | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
| Component: | [OLD] Core system | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cab, releng |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
current perl-5.8.7-r3/CONTENTS
9329-perl-5.8.7-r3.log libperl-multilib.patch updated libperl ebuild corresponding perl ebuild new perl CONTENTS |
||
|
Description
SpanKY
2006-01-10 19:48:02 UTC
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 |