Assertion when loading shared object with unmet version dependencies

[Marc Streckfuß]

Hey, sorry for the nagging but did you make any progress on that?
Or can you guide me so I can make any progress on this?

Cheers,
Marc

Am Sa., 15. Feb. 2020 um 14:25 Uhr schrieb Marc Streckfuß <
marc.streckfuss@gmail.com>:

> Sure:
>
> This is the Ubuntu Build:
>
> http://security.ubuntu.com/ubuntu/pool/main/o/openjdk-lts/openjdk-11-jre-headless_11.0.6+10-1ubuntu1~18.04.1_amd64.deb
>
> This is the Debian Build:
>
> http://ftp.de.debian.org/debian/pool/main/o/openjdk-11/openjdk-11-jre-headless_11.0.6+10-1~deb10u1_amd64.deb
>
> You can extract both using "dpkg-deb -R file.deb tmp/". If you are
> unable to use that tool, I can upload/attach to this e-mail(?) the files.
> You are looking for libs/libjawt.so, which is merely a gate for the real
> libawt.so (FWIW).
>
> Now the difference is that Ubuntu has "optimized" the .so and removed
> the versioned dependency on _cxa_finalize and thus discarded all sections.
>
>
> https://repo1.maven.org/maven2/org/lwjgl/lwjgl/lwjgl-platform/2.9.3/lwjgl-platform-2.9.3-natives-linux.jar
> This is the file triggering the condition, when the JDK tries to load
> the contained .so (you can unzip it), this so tries to load libjawt.
> Oh and I've only tested this for x64.
>
> Also note that with Debian there is no failure. Either the library has a
> fallback or loading works without that versioning.
>
> Am 15.02.20 um 13:57 schrieb Florian Weimer:
> > * Marc Streckfuß:
> >
> >> I am currently debugging a strange problem where loading a native
> library
> >> stops working depending on the build environment used to build openJDK.
> >>
> >> Basically when loading the lwjgl2.so, it fails at the following
> assertion:
> >> https://github.com/lattera/glibc/blob/master/elf/dl-lookup.c#L111
> > I missed the part where this isn't a load failure, but an assertion
> > failure.  Would you please put the object files which trigger this
> > somewhere, so that we can figure out the exact triggering conditions?
> >
> > This should really result in a dlopen failure, not a failing assert.
>
>