Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[android] dlopen failed: library "*" not found #5189

Open
2 tasks done
xaionaro opened this issue Oct 11, 2024 · 3 comments
Open
2 tasks done

[android] dlopen failed: library "*" not found #5189

xaionaro opened this issue Oct 11, 2024 · 3 comments
Labels
unverified A bug that has been reported but not verified

Comments

@xaionaro
Copy link

xaionaro commented Oct 11, 2024

Checklist

  • I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
  • This issue only relates to a single bug. I will open new issues for any other problems.

Describe the bug

When I use fyne to build into APK an app that uses a so-file, it fails to launch.

The crash report on Android:

type: crash
osVersion: google/lynx/lynx:14/AP2A.240905.003/2024091400:userdebug/release-keys
package: center.dx.fyneNoLibBugRepro:9
process: center.dx.fyneNoLibBugRepro
processUptime: 33 + 56 ms

java.lang.UnsatisfiedLinkError: dlopen failed: library "libdummy.so" not found: needed by /data/app/~~6mq_K-G-2TCpfXekwRY-ZQ==/center.dx.fyneNoLibBugRepro-1GnlebyfPI5lQFH704pTYw==/lib/arm64/libfyneNoLibBugRepro.so in namespace clns-4
	at java.lang.Runtime.loadLibrary0(Runtime.java:1081)
	at java.lang.Runtime.loadLibrary0(Runtime.java:1003)
	at java.lang.System.loadLibrary(System.java:1765)
	at org.golang.app.GoNativeActivity.load(GoNativeActivity.java:221)
	at org.golang.app.GoNativeActivity.onCreate(GoNativeActivity.java:229)
	at android.app.Activity.performCreate(Activity.java:9013)
	at android.app.Activity.performCreate(Activity.java:8991)
	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1531)
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3986)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:4184)
	at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:114)
	at android.app.servertransaction.TransactionExecutor.executeNonLifecycleItem(TransactionExecutor.java:231)
	at android.app.servertransaction.TransactionExecutor.executeTransactionItems(TransactionExecutor.java:152)
	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:93)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2602)
	at android.os.Handler.dispatchMessage(Handler.java:107)
	at android.os.Looper.loopOnce(Looper.java:232)
	at android.os.Looper.loop(Looper.java:317)
	at android.app.ActivityThread.main(ActivityThread.java:8623)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:580)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:894)

How to reproduce

  1. Download the repro code:
git clone https://github.com/xaionaro-go/fyne-library-not-found-bug-repro
cd fyne-library-not-found-bug-repro
  1. Put your Android SDK to ~/Android/Sdk.
  2. Run make to build the package.
  3. Run make install to install the package via adb to the connected phone.
  4. Unblock your phone and run make run.
  5. If the window instantly disappears, just run make run until Android would allow to take a look at the crash report.

Screenshots

No response

Example code

Essentially this code causes the error:

package main

// #cgo LDFLAGS: -L./ -ldummy
//#include "libdummy.h"
import "C"

func helloWorld() {
	C.helloWorld()
}

Fyne version

2.5.1, 2.4.5

Go compiler version

1.23.0

Operating system and version

Ubuntu 24.04

Additional Information

Current understanding of the problem:
My humble lame understanding is that fyne just needs to include the so-file into the APK.

The initial motivation:
The repro and description I provided above are the minimized/localized version of the bug I'm having in my project https://github.com/xaionaro-go/streamctl . There I'm trying to use libav (libavcodec, libavfilter, etc) compiled by termux inside the app.

@xaionaro xaionaro added the unverified A bug that has been reported but not verified label Oct 11, 2024
@andydotxyz
Copy link
Member

The fyne package tool does not have support for dynamic linked libraries, if you link them statically it will work.

@xaionaro
Copy link
Author

xaionaro commented Oct 12, 2024

The fyne package tool does not have support for dynamic linked libraries,

Would it be more appropriate to convert this bugreport to a feature request?

if you link them statically it will work.

It seems like linking statically any complex library (let's say libav with MediaCodec support) is out of reach for the vast majority of potential users (if not all of them).

For example, I've already spent about 16 hours trying to do that, and still have tons of unsolved problems *. If I won't be able to complete it today, then I'll just drop it...


* Just to give a feel of the complexity (and not to bugreport): for example, this is the problem I'm fighting right now (and there were dozens of other problems before that are already solved):

type: crash
osVersion: google/lynx/lynx:14/AP2A.240905.003/2024091400:userdebug/release-keys
package: center.dx.streampanel:176
process: center.dx.streampanel
processUptime: 38 + 49 ms

java.lang.UnsatisfiedLinkError: dlopen failed: TLS symbol "(null)" in dlopened "/data/app/~~NfpA1FedI-QGE2MluFoGRw==/center.dx.streampanel-TIi2qBVU_kvBPk_o2TQuqw==/lib/arm64/libstreampanel.so" referenced from "/data/app/~~NfpA1FedI-QGE2MluFoGRw==/center.dx.streampanel-TIi2qBVU_kvBPk_o2TQuqw==/lib/arm64/libstreampanel.so" using IE access model
	at java.lang.Runtime.loadLibrary0(Runtime.java:1081)
	at java.lang.Runtime.loadLibrary0(Runtime.java:1003)
	at java.lang.System.loadLibrary(System.java:1765)
	at org.golang.app.GoNativeActivity.load(GoNativeActivity.java:221)
	at org.golang.app.GoNativeActivity.onCreate(GoNativeActivity.java:229)
	at android.app.Activity.performCreate(Activity.java:9013)
	at android.app.Activity.performCreate(Activity.java:8991)
	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1531)
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3986)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:4184)
	at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:114)
	at android.app.servertransaction.TransactionExecutor.executeNonLifecycleItem(TransactionExecutor.java:231)
	at android.app.servertransaction.TransactionExecutor.executeTransactionItems(TransactionExecutor.java:152)
	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:93)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2602)
	at android.os.Handler.dispatchMessage(Handler.java:107)
	at android.os.Looper.loopOnce(Looper.java:232)
	at android.os.Looper.loop(Looper.java:317)
	at android.app.ActivityThread.main(ActivityThread.java:8623)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:580)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:894)

(which seems to be an unsolved problem in the Internet: golang/go#69109)

@andydotxyz
Copy link
Member

andydotxyz commented Oct 13, 2024

Would it be more appropriate to convert this bugreport to a feature request?

Could be. The idea of platform-independently requesting additional libraries is an interesting one but a hugely complex problem to solve well.

  • Just to give a feel of the complexity (and not to bugreport): for example, this is the problem I'm fighting right now (and there were dozens of other problems before that are already solved):

That indicates the code is still looking for a .so file and is not looking for locally compiled symbols.

(which seems to be an unsolved problem in the Internet: golang/go#69109)

They should not be related - go-mobile bind is a whole different approach to assembling applications compared to Fyne. A fyne app should host all the code and symbols (apart from the OS and graphics driver!) internally. The binding in go-mobile is for native apps with a Go lib packaged into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unverified A bug that has been reported but not verified
Projects
None yet
Development

No branches or pull requests

2 participants