Re: ICEs, libc6, yp

[Adam C Powell IV <hazelsct@mit.edu>]

Adam C Powell IV wrote:

> Jim Pick wrote:
>
> > Adam C Powell IV <hazelsct@mit.edu> writes:
> >
> > > Also, on the assertion problem with GNOME apps ("BUG IN DYNAMIC LINKER
> > > ld.so: ... Assertion `! "unexpected dynamic reloc type"' failed!"),
> >
> > One of the libraries was built without -fPIC.
> >
> > > is there a way I can figure out which library was not built
> > > properly?  The gnome-hello test programs all run fine, but
> > > e.g. e-conf does not.
> >
> > objdump --dynamic-reloc <library>
>
> > Make sure you don't have R_ARM_PC24 records.
>
> Akha!  The last lib I checked, libIIOP.so, has these symbols, but none of the
> other six which e-conf links but gnome-hello-... doesn't has them, so that is
> the only culprit.  I'll have to check on ssh later.
>
> They look like system calls though- things like strcasecmp and eval_hostname.
> I'll look into the Makefiles.  Thanks!

Okay, here's the problem...  To build libIIOP.so, libtool does the following:

   * Build each of the new .lo object files using -fPIC, the way it should be.
   * ar x /usr/lib/libwrap.a
   * for I in some list of old objs; do mv $I.o $I.lo; done
   * ar x /usr/lib/libwrap.a
   * gcc -shared new objs and old objs

So, it seems the culprit is the objects in libwrap.a, from the netbase package
(3.12-2.1).  Why is there no libwrap.so?  Is it possible that that library could
have its objects built -fPIC?  Is there another way to get libwrap objects into
libIIOP.so that will work? :-)

And why does this trick work on other platforms?  Is this really just a bug in
ld.so for ARM (1.9.11-2), as the error message would suggest?

Thanks again,

-Adam P.