Arla 0.42-RC2

[Niels Möller]

Some time ago, I 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?

I've sent a glibc bug report, and this is the response I got:

: ------- Additional Comments From drepper at redhat dot com  2006-08-22 17:08 -------
: Many parts of a program are dynamically linked, not just libgcc_s.  iconv
: modules, nss modules, libcidn, ...  It your responsibility to copy everything
: you need into the chroot.
: 
: -- 
:            What    |Removed                     |Added
: ----------------------------------------------------------------------------
:              Status|NEW                         |RESOLVED
:          Resolution|                            |INVALID
: 
: 
: http://sourceware.org/bugzilla/show_bug.cgi?id=3102

I don't quite agree, I understand that I have to set up a full chroot
environment if I want to exec new programs and stuff, but to have to
do it also for chroot isn't very nice. If nothing else, it makes it a
lot harder to use chroot in portable server programs portable, since
the set names of the files you need to copy into the chroot can be
very different between systems.

But I don't feel I'm the right person to argue about that with the
glibc folks. Either someone else has to do that, or arla needs some
workaround for the problem.

Regards,
/Niels