search

fyne-io / fyne

Cross platform GUI toolkit in Go inspired by Material Design
https://fyne.io/
Other
25.26k stars 1.4k forks source link

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

Open xaionaro opened 1 month ago

xaionaro commented 1 month ago

Checklist

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
  2. Put your Android SDK to ~/Android/Sdk.
  3. Run make to build the package.
  4. Run make install to install the package via adb to the connected phone.
  5. Unblock your phone and run make run.
  6. If the window instantly disappears, just run make rununtil 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.

andydotxyz commented 1 month ago

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

xaionaro commented 1 month ago

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: https://github.com/golang/go/issues/69109)

andydotxyz commented 1 month ago

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: https://github.com/golang/go/issues/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.