dev-lang/parrot-3.6.0[pcre] fails to build for me: Compiled: parrot_nci_thunk_gen.o x86_64-pc-linux-gnu-gcc -o parrot_nci_thunk_gen "parrot_nci_thunk_gen.o" "/var/tmp/portage/dev-lang/parrot-3.6.0/work/parrot-3.6.0/src/parrot_config.o" -L"/var/tmp/portage/dev-lang/parrot-3.6.0/work/parrot-3.6.0/blib/lib" -lparrot -Wl,-E -Wl,--as-needed -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lreadline -lffi -lpthread -ldl -lm -L/usr/lib64 -licuuc -licudata -lpthread -ldl -lm Linked: parrot_nci_thunk_gen ./parrot_nci_thunk_gen \ --loader-name=Parrot_glut_nci_loader \ --loader-storage-class=PARROT_DYNEXT_EXPORT \ --output=src/glut_nci_thunks.c \ <src/glut_nci_thunks.nci Failed to load libpcre current instr.: 'parrot;PCRE;init' pc 249 (runtime/parrot/library/pcre.pir:162) called from Sub 'read_one_sig' pc 1982 (tools/dev/nci_thunk_gen.pir:861) called from Sub 'read_sigs' pc 1903 (tools/dev/nci_thunk_gen.pir:823) called from Sub 'main' pc 40 (tools/dev/nci_thunk_gen.pir:48) make: *** [src/glut_nci_thunks.c] Error 1 emake failed I've already mentioned this in bug #349297 comment #4, but I've decided to file a separate bug report. Bug #349297 is about runtime problems, while this here appears as a build-time problem. Furthermore, there is an upstream bug report at http://trac.parrot.org/parrot/ticket/2107 which apparently describes this issue here, and also concentrates on the build-time aspect of things.
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.