Re: musl ldd: swt build: Error relocating / symbol not found

[Rich Felker <dalias@libc.org>]

On Thu, Jun 23, 2016 at 03:35:02AM +0000, Andrei Pozolotin wrote:
>     Hello.
> 
>     I have a curious problem:
> 
>     1) the following build system:
>     https://github.com/random-alpiner/repository/blob/master/bugs/01/APKBUILD
>     https://github.com/random-alpiner/repository/blob/master/bugs/01/build.sh
>     https://github.com/random-alpiner/repository/blob/master/bugs/01/make_linux.mak
> 
>     2) produces a library:
>     https://github.com/random-alpiner/repository/blob/master/alpine/x86_64/swt-4.5.2-r1.apk
> 
>     3) which, when loaded by target application (java/eclipse), produces
>     an error:
>     https://github.com/random-alpiner/repository/blob/master/bugs/01/1-app.log
> 
>     4) and yet, that error should not happen, according to musl ldd:
>     https://github.com/random-alpiner/repository/blob/master/bugs/01/2-ldd.log
> 
>     5) and also confirmed by readelf:
>     https://github.com/random-alpiner/repository/blob/master/bugs/01/3-readelf.log
> 
>     Any pointers on how to resolve this seeming contradiction are much
>     appreciated.

My first guess would be that something else in the application
(eclipse) has already caused an older/stale version of libgobject to
be loaded, so that the version containing the symbol definition does
not get loaded. You could confirm this by running strace on the
program and checking what library files it loads/maps.

>     Finally, someone on irc#musl suggested that musl ldd provides "-d"
>     and "-r" options
>     by default out of the box:
>     http://man7.org/linux/man-pages/man1/ldd.1.html. Is that so?

This is roughly correct. Symbol resolution is always attempted and
errors reported.

Rich