dlopen / dlsym issue ?

[Joakim Tjernlund]

> 
> Hi Joakim,
> 
> I basically took a lot of time reading and browsing the source code 
> difference between 0.9.27 and latest snapshot focusing on 
> libdl and ldso 
> stuff. This is something which is easily upgradable as ld-so 
> and libdl are 
> statically linked shared object and are mostly independant of 
> the other 
> parts of the code.
> So I applied some upgrade from 0.9.27 source tree to libdl.c, ldso.c 
> dl-elf.c and elfinterp.c.

OK.

> It is hard for me to have a look with 0.9.28 source tree, as 
> there is huge 
> amount of software compiled on top of the 0.9.27. It will 
> take very long 
> time to check that stuff.
> What I could try to do is implementing a shorter 
> implementation of the bug 
> as to provide a reproducer to people having a 0.9.28 library.
> Does anyone know where I could download an ext2 image of a 
> working 0.9.28 
> version ?
> In the meantime here is the DT_NEEDED list from the evas_buffer_test.
>    NEEDED      libevas.so.1
>    NEEDED      libdl.so.0
>    NEEDED      libeet.so.0
>    NEEDED      libjpeg.so.62
>    NEEDED      libfontconfig.so.1
>    NEEDED      libfreetype.so.6
>    NEEDED      libz.so.1
>    NEEDED      libexpat.so.0
>    NEEDED      libm.so.0
>    NEEDED      libc.so.0

I don't know if this list is complete. It is for you to check.

> but it is a normal behavior not seeing in this output any 
> module.so shared 
> object as they are automatically discovered during the execution and 
> dlopen is called directly by the application itself.

Do you pass RTLD_GLOBAL to dlopen? if not it is important that
all deps are accounted for. uclibc is picky about this and glibc is not.
Usally one get an error about unresolved syms if the dep list is
incomplete.

> 
> Regarding RTLD_XXX I used the fault value and RTLD_NEXT as 
> handle without 
> too much success on this.

Ahh, I think the RTLD_NEXT impl. in libdl is somewhat broken, especially
if you do dlsym from within the exe. The tpnt->loadaddr doesn't hold the
load
address. It holds the load offset, that is, load address - link address.
For
an app tpnt->loadaddr is mostly zero.

You could try using tpnt->ppnt, but this is a quick and dirty workarond.
ldso
needs to record the start and end addresses properly and use these
when seaching for RTLD_NEXT.

I have been to busy to do something about this and will most likely be
so for
the next few months as well.

 Jocke

> 
> Jm
> 
> On Tue, 11 Apr 2006, Joakim Tjernlund wrote:
> 
> >
> >>
> >> Hi,
> >>
> >> I am using uClibc 0.97 as a test plateform to build a
> >> lightweight graphical environment. I am trying to port on top
> >> of a buildroot environment Enlightenment DR17
> >> (http://www.enlightenment.org) which is under heavy
> >
> > .97(I assume this is really 0.9.27) is very old and lots 
> has happened since then(in ldso as well).
> > I think you should try both 0.9.28 and current SVN.
> > If that doesn't work, show me the the RTLD_XX flags you are 
> using and make sure
> > that the .so libs has all dependencies in their DT_NEEDED list.
> >
> >>
> >> I have included into my 0.97 source tree the lates ldso tree
> >> from the CVS but without major success.
> >
> > Don't see how you can just rip out the ldso sub tree and 
> make that work with current
> > SVN. What did you do?
> >
> >
> 
>