termux-packages commit 46c5cd3 breaks my app and I am not sure the best solution
Hi, I develop an app called sm64ex-coop and I rely on Termux and its rolling packages for part of my app's build process. unfortunately my users and I are getting this error if we upgrade our Termux
libglvnd packages beyond this commit https://github.com/termux/termux-packages/commit/46c5cd3d7458adb980919a7ab4e75f6cec05af2f. I understand that commit fixes an issue, meaning that the way my app and that other app use libglvnd is in conflict, and most likely the way I use it is the less correct method and the termux-packages repo change needs to stay in place for correctness and solving that other app's issue because I compile C code using Termux's clang, but then use apksigner and zipalign to inject it into a Android SDK package containing java code and a custom fork I made of libSDL2.so compiled within Android Studio for the Android SDK so that my app works in the SurfaceFlinger windowing system of Android's default GUI with 3D acceleration. commit 924694a and all prior this year are good. Full source code of my app: https://github.com/robertkirkman/sm64ex-coop-android-base. the build system broken by this commit (I maintain two parallel build systems simultaneously and only one of them uses Termux as a dependency) is described in the sub readme at the link "minimal from Android" in my README.md.
1 Reply
Doing this and then rerunning my build process makes the issue disappear, and updating the packages to newest again, then recompiling, causes the issue to reappear:
I'd like to be able to make the latest Termux package work as the dependency for my app but I am not sure what the best way is to write my app correctly to prevent this issue in the future.
The reason this package and header package are a dependency for my app is because my build process prints this if they're not installed:
so at the very least I need that file and any of its own companions or dependencies to work how I need them to as a dependency of my build process.
on inspection, the only files from
libglvnd that my build needs for both compile-time and run-time are:
gl2.h
gl2ext.h
gl2platform.h
khrplatform.h
my app is normally capable of using the Android base system's /system/lib/libGLESv2.so at run-time, but it seems like something about this change to libglvnd is interfering with that when the updatedlibglvnd package itself specifically is installed at compile-time, the libglvnd-dev package might still be fine, so maybe I can label libglvnd specifically as a "compile-time inverse dependency" of my app, stating that having it installed is a conflict that breaks my build.
it looks like that is the best solution for me to go with. Previously (several months ago), these files (gl2platform.h and khrplatform.h) were packaged very differently. They were split between the mesa and mesa-dev packages, requiring both of those to be installed in order to obtain them all, so i included them in my documented dependencies. Later, it looks like the mesa packages began pulling in libglvnd and libglvnd-dev instead, placing the newer versions of all of them onto my devices, and all of the files I actually need were moved into libglvnd-dev. So it looks like I can update my documented build dependencies to include libglvnd-dev only and explicitly exclude libglvnd as a conflict, since although it never caused a conflict for months, its recent change has caused it to.
i will just leave this open because while i have made appropriate changes to my documentation, if there is ever some way discovered that I don't know about to make a change to libglvnd that still preserves the appropriate fix for https://github.com/termux/termux-packages/issues/16548 but also doesn't conflict with my use-case of -lGLESv2 at link-time, then that would minimize confusion with my users who don't read documentation.