Rich:
On 06/23/2016 04:24 AM, Rich Felker
wrote:
On Thu, Jun 23, 2016 at 03:35:02AM +0000, Andrei Pozolotin wrote:
https://github.com/random-alpiner/repository/blob/master/bugs/01/1-app.log
https://github.com/random-alpiner/repository/blob/master/bugs/01/2-ldd.log
https://github.com/random-alpiner/repository/blob/master/bugs/01/3-readelf.log
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.
Thank you for the tip.
1) the trace shows:
https://github.com/random-alpiner/repository/blob/master/bugs/01/4-strace.log
2) that the proper
/usr/lib/libgobject-2.0.so.0
is in fact loaded before
/usr/lib/libswt-atk-gtk-4530.so
3) however, the loading starts from
/home/work/space/none-4.5.0/conf/org.eclipse.osgi/748/0/.cp/libswt-gtk-4530.so,
which is an eclipse default library bundled with the eclipse
application, and which is compiled against foreign libc.6.so:
lddtree /home/work/space/none-4.5.0/conf/org.eclipse.osgi/748/0/.cp/libswt-gtk-4530.so
libswt-gtk-4530.so => /home/work/space/none-4.5.0/conf/org.eclipse.osgi/748/0/.cp/libswt-gtk-4530.so (interpreter => none)
libc.so.6 => not found
4) the library loading logic of eclipse is: first try to load
bundled libraries from private paths,
and if that fails, then try to load these libraries from the public
paths, such as "/usr/lib/*", etc.
5) I do provide replacement libswt-* libraries built against musl on
the public path "/usr/lib/*",
and the assumption was that when private path library loading fails,
then the library will be loaded from the public path, which "sort of
almost works",
so:
* was that a wrong assumption?
* will in fact musl ld.so reject libraries linked to the libc.so.6?
* if not, is there a way to tell musl ld.so to blacklist private
path libraries?