GNOME Bugzilla – Bug 763576
filesprovider: Do not expect Android libs to have version-info symlinks
Last modified: 2018-11-03 10:20:42 UTC
Created attachment 323809 [details] [review] Patch fixing the issue Android, despite being based on Linux, does not support libtool versions. As a result, libtool creates only .so files for Android libraries, .so.* symlinks are not present. That caused problem while building package that had dependencies that hadn't explicitely listed library file names (like it happens in GStreamer) - files_libs from dependencies were not found while packaging for Android. The attached patch fixes the issue.
Review of attachment 323809 [details] [review]: This is not libtool versioning, but ELF shared object versioning. Has nothing to do with libtool really :) But yes, newest libtool apparently does not create the versioned .so anymore for Android, however in cerbero we don't really use the shared libraries for anything. Why/what are you planning to do with the shared libraries? ::: cerbero/build/filesprovider.py @@ +43,3 @@ Platform.LINUX: {'bext': '', 'sext': '.so.*', 'sdir': 'lib', 'mext': '.so', 'smext': '.a', 'pext': '.so', 'srext': '.so'}, + Platform.ANDROID: {'bext': '', 'sext': '.so', 'sdir': 'lib', Should be either .so*, or these have to be fixed first: > libbz2.so.1.0@ libcroco-0.6.so.3.0.1* libhogweed.so.4@ libnettle.so.6.2 libopenh264.so.0* libtag_c.so.0@ libz.so.1@ > libbz2.so.1.0.6* libexpat.so.1@ libhogweed.so.4.2 libopencore-amrnb.so.0@ libopus.so.0@ libtag_c.so.0.0.0 libz.so.1.2.8* > libcharset.so.1@ libexpat.so.1.6.0* libiconv.so.2@ libopencore-amrnb.so.0.0.3* libopus.so.0.5.0* libtag.so.1@ > libcharset.so.1.0.0 libharfbuzz.so.0@ libiconv.so.2.5.1 libopencore-amrwb.so.0@ librtmp.so.1* libtag.so.1.7.2 > libcroco-0.6.so.3@ libharfbuzz.so.0.10000.1* libnettle.so.6@ libopencore-amrwb.so.0.0.3* libsrtp.so.1* libx264.so.148*
Fixing those is probably only a matter for running autoreconf btw
You're right, it's about ELF, I wasn't precise. I think better solution is to ensure that these libraries just build .so on Android, so I would rather go with adding autoreconf = True to their recipes. I will prepare another patch. I am investigating this because I want to use prebuilt binary in my project. According to this: https://developer.android.com/ndk/guides/prebuilts.html I can use either prebuilt shared or static library. I started with shared as in my case there's no reason to use static (or I just don't know that reason). I run into issues when I created new package and added deps and started to figure out why .so files that are listed in recipes' fies_libs are missing in the tarball.
The ndk-build integration of cerbero is working differently though. It's creating, based on configuration in the Android.mk, a single libgstreamer_android.so from all the required static libraries. This one then contains e.g. glib, gstreamer core, the plugins, their dependencies, everything. It's to a) not clutter the app with 100s of shared libraries and b) work around a Android limitation that existed until 4.0 (?)... it could only load up to 64 shared libraries in a single process.
I do not want to modify how GStreamer is built. I want to use cerbero to build another project that depends on gstreamer, but additionally depends on several other open libraries (such as json-glib or libvspec), not present in the cerbero. Basically it should end up with extra 4-5 shared libraries so even if the limit is still present, it's fine. GStreamer can and should remain as it is, but for the new software I add to cerbero this is an issue.
If you build that software with cerbero, you can just add their pkg-config files to GSTREAMER_EXTRA_DEPS, and they would become part of the big libgstreamer_android.so. But doing it like you want to do should work nonetheless, so let's get this fixed :) Thanks for looking into this.
Hm it seems to be not that trivial, not all of the libraries are based on autotools, so autoreconf is not enough. I would have needed patching all of their individual build systems which will add some effort in maintaining that. Maybe better solution would have been to add Android-specific behaviour to cerbero that if it finds .so.* file it will take it and store as .so in the tarball? It should still work and it's more universal. Thanks for the hint about linking, unfortunately one of these libraries is proprietary and AFAIK I am not allowed to statically link LGPL and proprietary software and I want to respect that.
(In reply to Marcin Lewandowski from comment #7) > Hm it seems to be not that trivial, not all of the libraries are based on > autotools, so autoreconf is not enough. I would have needed patching all of > their individual build systems which will add some effort in maintaining > that. > > Maybe better solution would have been to add Android-specific behaviour to > cerbero that if it finds .so.* file it will take it and store as .so in the > tarball? It should still work and it's more universal. The soname stored inside the library would be wrong then, and would have to be fixed up first otherwise. > Thanks for the hint about linking, unfortunately one of these libraries is > proprietary and AFAIK I am not allowed to statically link LGPL and > proprietary software and I want to respect that. AFAIU you are as long as you provide a way to relink everything with modified versions of the LGPL code. I.e. you need to provide object files or static libraries for your proprietary code at least.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/cerbero/issues/29.