Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 377379 - dev-lang/parrot-3.6.0[pcre]: Failed to load libpcre
Summary: dev-lang/parrot-3.6.0[pcre]: Failed to load libpcre
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Perl team
URL: http://trac.parrot.org/parrot/ticket/...
Whiteboard:
Keywords: Inclusion
: 377067 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-08-02 07:03 UTC by Martin von Gagern
Modified: 2011-12-27 10:08 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
strace fragment (parrot.libpcre.strace,5.22 KB, text/plain)
2011-08-02 07:06 UTC, Martin von Gagern
Details
Proposed fix (parrot-TT2107a.patch,1.27 KB, patch)
2011-08-02 14:10 UTC, Martin von Gagern
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2011-08-02 07:03:35 UTC
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.
Comment 1 Martin von Gagern 2011-08-02 07:06:05 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.
Comment 2 Martin von Gagern 2011-08-02 08:34:12 UTC
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.
Comment 3 Juergen Rose 2011-08-02 08:56:21 UTC
Even if the analysis is more careful I suppose that this bug is a duplicate of  Bug 377067.
Comment 4 Agostino Sarubbo gentoo-dev 2011-08-02 13:48:08 UTC
*** Bug 377067 has been marked as a duplicate of this bug. ***
Comment 5 Martin von Gagern 2011-08-02 14:10:41 UTC
Created attachment 281837 [details, diff]
Proposed fix

OK, this patch does the trick for me. Will propose it upstream as well.
Comment 6 Martin von Gagern 2011-08-02 14:36:45 UTC
(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.
Comment 7 Martin von Gagern 2011-08-02 15:47:35 UTC
(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.
Comment 8 Martin von Gagern 2011-08-12 09:18:49 UTC
(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?
Comment 9 Martin von Gagern 2011-08-31 09:29:56 UTC
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.
Comment 10 Patrick Lauer gentoo-dev 2011-12-27 05:34:17 UTC
Is this still an issue with 3.9.11 ?
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-12-27 10:08:04 UTC
Yes, it builds fine now.