java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "getdtablesize"

[LeroyChristopherDunn]

Hi there

My client run task with android target fails with the below link error:

E/AndroidRuntime(19668): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "getdtablesize" referenced by "/data/app/hello.hellodesktop-XiRilnh49ahx5XXKtJJqtg==/lib/arm64/libsubstrate.so"...

This specifically occurs when launching our enterprise jar with Assisted Configuration of Native Image Builds. I'm unfortunately unable to replicate the issue in a simple project

Env:
GraalVM CE 20.3.0-dev-20200814_0227 and it's bundled Java 11
Ubuntu 16.04
Maven client plugin version 0.1.31

full-stacktrace.log

Any assistance would be greatly appreciated

[jperedadnr]

Make sure you run with latest release GraalVM 20.2.0 (the log shows /home/leroy/Programs/graalvm-ce-java11-20.2.0-dev) from https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-20.2.0

For some reason, one of your dependencies is adding the getdtablesize symbol, but there is no implementation provided and that causes the runtime failure. Are you including native libraries in your project?

[LeroyChristopherDunn]

We are not directly using any native libraries in our project and suspect it's one of the dependencies. In this issue you mentioned the client plugin scanning all dependencies for static native libraries. Do you have any suggestions on how I might be able to detect them?

Now using latest release GraalVM 20.2.0 and the same error occurs

If it is of any help, I've included jdeps output of our jar
dependencies.txt

[jperedadnr]

You can easily check what native libraries are extracted. See target/client/aarch64-android/gvm/lib folder, where the *.a files will be added before they are linked. If any, these come from Attach (if you use it) and your dependencies.

[LeroyChristopherDunn]

That folder is empty on my side. I've run clean, build, package, install, run

[jperedadnr]

Ok, looks like it could be added via JMX. Your log shows org.apache.log4j.jmx and org.apache.logging.log4j.core.jmx. Is there a way you can easily remove these dependencies and test again?

[LeroyChristopherDunn]

I took the following steps to resolve the issue:

1. I disabled log4j JMX with a system property as per log4j documentation

2. We were using async loggers in our project. I made sure to disable them by removing the async logging system property and the Disruptor dependency as per log4j documentation

3. client:build was now failing with a ClassNotFound error. I explicitly added back the now unused Disruptor dependency as per this issue