Arla 0.42-RC2

[Jeffrey Hutzelman]

On Wednesday, April 05, 2006 05:06:58 PM +0200 Niels Möller 
<nisse at lysator.liu.se> wrote:

> nisse at lysator.liu.se (Niels Möller) writes:
>
>> It's puzzling. I also tried strace -f arlad -n, which says:
>>
>>   5357  open("/lib/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file
>>   or directory) 5357  open("/usr/lib/i686/cmov/libgcc_s.so.1", O_RDONLY)
>>   = -1 ENOENT (No such file or directory) 5357
>>   open("/usr/lib/i686/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such
>>   file or directory) 5357  open("/usr/lib/libgcc_s.so.1", O_RDONLY) = -1
>>   ENOENT (No such file or directory) 5357  write(2, "libgcc_s.so.1 must
>>   be installed "..., 59) = 59 5357  exit_group(127)                   = ?
>>
>> The file /lib/libgcc_s.so.1 exists and is readable, so I really don't
>> understand why open returns ENOENT.
>
> ceder helped me spot the "obvious" problem. Earlier in the strace
> output:
>
>   5332  chroot("/usr/arla/cache")         = 0
>
> So here we have the problem: pthread_cancel wants to use dlopen to
> load libgcc_s.so.1. But by the time it calls dlopen, this file is
> hidden by chroot.
>
> I'm tempted to say it's a bug in glibc to depend on dlopen like this,
> and I wouldn't be surprised if this behaviour is not POSIX-compliant.
>
> Is there any way to force the loading of libgcc earlier? Or how to
> work around this?

You could try linking arlad against libgcc explicitly.
You could also use LD_PRELOAD to get it loaded early.

-- Jeff