undefined symbols in libjvm.so

[David Holmes]

On 8/05/2024 6:55 am, Vladimir Petko wrote:
> Hi,
> 
>   This is probably an edge-case with assembly-defined symbols.
> -Wl,z,defs prevents linking a shared library with undefined imports,
> but does nothing about symbols exported by the library itself that are
> undefined.
> -Wl,--allow-shlib-undefined allows linking executable against such
> library as long as it does not use any of the undefined symbols. I
> have made a small sample[1] to illustrate the point.

So we can only detect the undefined symbol problem indirectly via an 
executable linking to the bad library rather than the building of the 
library itself?

David

> 
> Best Regards,
>   Vladimir.
> 
> [1] https://github.com/vpa1977/linksample
> 
> On Tue, May 7, 2024 at 10:36 PM Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>>
>> Undefined symbols in libjvm.so is no good, and it should not be allowed.
>> However, I am unsure about your analysis. This flag only affect linking
>> of executables, not shared libraries. We do set "-Wl,-z,defs" when
>> linking shared libraries, and this should complain about undefined symbols.
>>
>> /Magnus
>>
>> On 2024-05-06 21:57, Vladimir Petko wrote:
>>> Hi,
>>>
>>> I have recently encountered bugs caused by undefined symbols in
>>> libjvm.so[1][2]. The root cause of those issues is the expression in
>>> make/autoconf/flags-ldflags.m4:
>>>
>>> ---
>>> if test "x$TOOLCHAIN_TYPE" = xgcc; then
>>> EXECUTABLE_LDFLAGS="$EXECUTABLE_LDFLAGS -Wl,--allow-shlib-undefined"
>>> ...
>>> --
>>>
>>> OpenJDK master builds fine after fixing[1] on the following
>>> architectures:  amd64, i386, armhf, arm64, s390, ppc64el and riscv64.
>>>
>>> Would it be possible to consider removing -Wl,--allow-shlib-undefined
>>> from the build flags?
>>>
>>> Best Regards,
>>>    Vladimir.
>>>
>>> [1] https://bugs.openjdk.org/browse/JDK-8331541
>>> [2] https://bugs.openjdk.org/browse/JDK-8329983