After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 763576 - filesprovider: Do not expect Android libs to have version-info symlinks
filesprovider: Do not expect Android libs to have version-info symlinks
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: cerbero
git master
Other All
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-03-13 19:47 UTC by Marcin Lewandowski
Modified: 2018-11-03 10:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch fixing the issue (1.54 KB, patch)
2016-03-13 19:47 UTC, Marcin Lewandowski
needs-work Details | Review

Description Marcin Lewandowski 2016-03-13 19:47:08 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.
Comment 1 Sebastian Dröge (slomo) 2016-03-14 08:24:39 UTC
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*
Comment 2 Sebastian Dröge (slomo) 2016-03-14 08:24:58 UTC
Fixing those is probably only a matter for running autoreconf btw
Comment 3 Marcin Lewandowski 2016-03-14 09:08:42 UTC
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.
Comment 4 Sebastian Dröge (slomo) 2016-03-14 09:29:14 UTC
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.
Comment 5 Marcin Lewandowski 2016-03-14 09:33:53 UTC
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.
Comment 6 Sebastian Dröge (slomo) 2016-03-14 09:44:56 UTC
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.
Comment 7 Marcin Lewandowski 2016-03-14 10:42:31 UTC
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.
Comment 8 Sebastian Dröge (slomo) 2016-03-14 10:50:25 UTC
(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.
Comment 9 GStreamer system administrator 2018-11-03 10:20:42 UTC
-- 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.