Summary: | dev-lang/parrot-3.6.0[pcre]: Failed to load libpcre | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | Current packages | Assignee: | Gentoo Perl team <perl> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugs+gentoo, levertond, mgorny, rose, simon, smoothhound |
Priority: | Normal | Keywords: | Inclusion |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://trac.parrot.org/parrot/ticket/2107 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
strace fragment
Proposed fix |
Description
Martin von Gagern
2011-08-02 07:03:35 UTC
Created attachment 281797 [details]
strace fragment
This is part of an strace run of the parrot_nci_thunk_gen binary. I've grepped all lines mentioning libpcre. This shows you the order in which directories are searched. You will notice that /lib or /lib64 does not appear to be among the searched directories.
Ran parrot_nci_thunk_gen through gdb. Apparently there is only a single call to dlopen, which is dlopen("libpcre.so", RTLD_LAZY). Extracted that to a small test program: #include <dlfcn.h> #include <stdio.h> int main(int argc, char** argv) { const char* name = "libpcre.so"; void *lib = dlopen(name, RTLD_LAZY); printf("dlopen(\"%s\", RTLD_LAZY): %s\n", name, lib ? "Success" : dlerror()); return !lib; } When compiled, libked with -ldl, and executed, it will print this line: dlopen("libpcre.so", RTLD_LAZY): /usr/lib64/libpcre.so: invalid ELF header Makes sense, as /usr/lib64/libpcre.so isn't really an ELF shared object, but a linker script generated by gen_usr_ldscript. So I'd say the problem lies either in the way that glibc implements its dlopen (i.e. not handling linker scripts), or in the way libpcre is installed (i.e. not installing a /lib64/libpcre.so symlink). At least I'd expect the above code to work, so unless someone has a good reason why it in fact should not work, then I would rather concentrate on making it work. Apparently parrot has added custom code specifically for the sake of Gentoo: http://trac.parrot.org/parrot/ticket/578 Back then they added searching for libpcre.so.0 as well as libpcre.so. It appears that something recently broke in parrot, making a failed library load abort execution instead of trying the next. Not sure why. Even if the analysis is more careful I suppose that this bug is a duplicate of Bug 377067. *** Bug 377067 has been marked as a duplicate of this bug. *** Created attachment 281837 [details, diff]
Proposed fix
OK, this patch does the trick for me. Will propose it upstream as well.
(In reply to comment #5) > Will propose it upstream as well. Proposed patch to upstream: https://github.com/parrot/parrot/pull/144 http://trac.parrot.org/parrot/ticket/2107#comment:8 Let's see what they make of it. (In reply to comment #3) > I suppose that this bug is a duplicate of Bug 377067. I realize that the new bugzilla automatic duplicate search in the bug entry form is no replacement for a manual search for matching bugs up front. Sorry. (In reply to comment #2) > So I'd say the problem lies either in the way that glibc implements its dlopen > (i.e. not handling linker scripts), or in the way libpcre is installed (i.e. > not installing a /lib64/libpcre.so symlink). At least I'd expect the above > code to work, so unless someone has a good reason why it in fact should not > work, then I would rather concentrate on making it work. Bug #290974 has decided that this general problem is not a bug but a feature. According to bug #290974 comment #4 dlopen("libpcre.so") should not work on Gentoo, because it would fail to work on other systems. I still don't know why the SONAME of libpcre is 0 on Gentoo but 3 on Ubuntu, but I doubt I actually care that much. So fix parrot using comment #5, and leave libpcre as it is. (In reply to comment #6) > Let's see what they make of it. Upstream accepted my patch: https://github.com/parrot/parrot/commit/2d6e52a64f865819d73ed59e37496c0b20d39457 So let's get this fixed in Gentoo without waiting for the next upstream release, shall we? Ping? Hit this again today due to the libffi soname change requiring a rebuild of paarrot. If you are a user and don't want to wait for Gentoo devs to fix this: # ebuild /usr/portage/dev-lang/parrot/parrot-3.6.0.ebuild clean prepare # wget -O- 'https://377379.bugs.gentoo.org/attachment.cgi?id=281837' \ | patch -p0 -d /var/tmp/portage/dev-lang/parrot-3.6.0/work # ebuild /usr/portage/dev-lang/parrot/parrot-3.6.0.ebuild merge Unfortunately, the parrot ebuild does not use epatch_user from eutils.eclass, so dropping the patch into /etc/portage/patches isn't enough to ensure every remerge of parrot will succeed. Is this still an issue with 3.9.11 ? Yes, it builds fine now. |