Ticket #578 (closed bug: fixed)

Opened 13 years ago

Last modified 11 years ago

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.

Change History

  Changed 12 years ago by Infinoid

I've just re-tested, and this issue is still present on my system (because gentoo is still installing a linker script as /usr/lib/libpcre.so).

I notice that runtime/parrot/library/pcre.pir checks for both libpcre.so and libpcre.so.3. However, the libpcre-8.0.0 package on my machine installs as libpcre.so.0.0.1 (symlinked as libpcre.so.0), so it misses it. When I add another clause to pcre.pir to search for libpcre.so.0, t/library/pcre.t now passes, so that seems like an effective workaround for my system.

follow-up: ↓ 3   Changed 12 years ago by NotFound

Check for libpcre.so.0 added in r43047 with a comment pointing to this ticket.

in reply to: ↑ 2 ; follow-up: ↓ 4   Changed 12 years ago by Infinoid

Replying to NotFound:

Check for libpcre.so.0 added in r43047 with a comment pointing to this ticket.

I have verified that t/library/pcre.t passes on my machine with r43047.

in reply to: ↑ 3 ; follow-up: ↓ 6   Changed 12 years ago by jkeenan

Replying to Infinoid:

Replying to NotFound:

Check for libpcre.so.0 added in r43047 with a comment pointing to this ticket.

I have verified that t/library/pcre.t passes on my machine with r43047.

Does this mean this TT is closable? Or are there more general issues here?

kid51

  Changed 11 years ago by jkeenan

  • status changed from new to assigned
  • owner set to jkeenan

in reply to: ↑ 4   Changed 11 years ago by jkeenan

  • status changed from assigned to closed
  • resolution set to fixed

Replying to jkeenan:

Does this mean this TT is closable? Or are there more general issues here?

In 15 months, no one has claimed that this TT is not closable.

So I'm closing it.

Note: See TracTickets for help on using tickets.