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