dlopen / dlsym issue ?

[Peter S. Mazinger]

On Tue, 11 Apr 2006 jean-marie.verdun at splitted-desktop.org wrote:

> 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.
> 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.

.28 provides an update path to allow you to update libc, rebuild all your 
apps, then rebuild .28 again without compatibility stuff enabled.

set DL_FINI_CRT_COMPAT (you should set MALLOC_GLIBC_COMPAT as well)

after rebuilding all apps you can disable DL_FINI_CRT_COMPAT

from .28 to svn you need ATEXIT_COMPAT/UCLIBC_SUSV3_LEGACY enabled, now 
you need to rebuild anything using atexit(), then you can switch 
ATEXIT_COMPAT off.
UCLIBC_SUSV3_LEGACY can't be switched off (it can be done, but there is no 
"official" update path).

MALLOC_GLIBC_COMPAT has to stay enabled.

> 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
> 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.

works probably only if lazy binding is used (without -Wl,-z,now), and even 
then there are some problems (for sure if RUNPATH/RPATH has $ORIGIN, 
not supported by uClibc's ld.so)

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2