Ticket #578 (closed bug: fixed)
Parrot can't handle linker scripts
Reported by: | Infinoid | Owned by: | jkeenan |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | core | Version: | |
Severity: | medium | Keywords: | dlopen ld script libpcre |
Cc: | Language: | ||
Patch status: | Platform: | linux |
Description
Apparently the libpcre setup on Gentoo is a little weird.
The 3 relevant files on my machine are:
/lib/libpcre.so.0.0.1 - ELF 64-bit LSB shared object, x86-64 /lib/libpcre.so.0 - symlink to libpcre.so.0.0.1 /usr/lib/libpcre.so - ld script file
The ld script is just a text file, with the following contents:
/* GNU ld script Since Gentoo has critical dynamic libraries in /lib, and the static versions in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we run into linking problems. This "fake" dynamic lib is a linker script that redirects the linker to the real lib. And yes, this works in the cross- compiling scenario as the sysroot-ed linker will prepend the real path. See bug http://bugs.gentoo.org/4411 for more info. */ OUTPUT_FORMAT ( elf64-x86-64 ) GROUP ( /lib64/libpcre.so.0 )
This works fine for binaries linked with -lpcre, but it doesn't work for parrot. Parrot sees /usr/lib/libpcre.so and assumes it's found what it looks for, and attempts to dlopen() it directly. Dlopen() opens and reads it, says "hey, this isn't elf" and barfs.
Normally I'd just assume gentoo is broken and fix it by hand, but I can imagine other cases where this will be an issue for parrot, too. I'm not sure how best to fix this; looking for suggestions.