How to turn off the versioning of the library name .so.54.*

[jonywalker]

I know this is a feature for application compatibility. I cross-compiled ffmpeg for Android, but Android SDK breaks down the symbolic links and copy only the content into *apk Installation file. If those libraries are load into virtual machine, the dependent *.so.xx.xx.xx are no more available, and runtime error occurs. The simplest way is to make ffmpeg build script generate shared libraries without symbolic links and versioning, how to do that?
My old solution is to build static library, but that is not prefered by Android System. I would not mention the reason here because it is out of topic. Thanks!

[koliva]

I had a similar issue with x264 but I solved it by just simply renaming the file after the build.

[rogerdpack]

I know this is a feature for application compatibility. I cross-compiled ffmpeg for Android, but Android SDK breaks down the symbolic links and copy only the content into *apk Installation file. If those libraries are load into virtual machine, the dependent *.so.xx.xx.xx are no more available, and runtime error occurs. The simplest way is to make ffmpeg build script generate shared libraries without symbolic links and versioning, how to do that?
My old solution is to build static library, but that is not prefered by Android System. I would not mention the reason here because it is out of topic. Thanks!

I know in windows builds it created avcodec-54.dll *as well as* avcodec.dll, in the same folder, maybe your are lucky and yours also does something like that, and you can use the unversionsed .so files?

[jonywalker]

it works with single library, but not for e.g
libavformat.so libavcodec.so libavutil.so libwsale.so all together. The real libraries are libavformat.so.54.xxx, libavcodec.so.54.xxx libavutil.so.52.xxx and libwscale.so.3.xxx.
It my be an error of ffmpeg build script that the real libary name of libavcodec.so.54.xxx is referenced by libavformat.so.54.xxx inside, instead it should be the symbolic link of library that should be referenced by libavformat.so.54.xxx. That means, we are then able to make the libavformat.so.54.xxx depend on different version of libavcodec.so.xxx just by switching the soft link of libavcodec.so. I am now modifying the configure file to do that.
There is an option "--disable-symver", means disable symbolic versioning, inside configure file, but it dosn't have any impact on the build results. I tried editing the binary file *.so.xxx via text editor but it didn't work.
There are also errors in tool/build_statefright, we either need to modify enable_libstagefright_h264 to enable libstagefright in order to make the build working. And inside the libstagefright.cpp there is also an error ff_get_buffer not defined, so that we have to add #include internal.h to libstagefright.cpp. So much my input for ffmpeg community.

[rogerdpack]

Makes me wonder how other use it for android (maybe they just use a grande static lib?)
I mean somebody may have run into this before, I'd imagine.
Unfortunately http://ffmpeg.org/trac/ffmpeg/wiki/How% ... %20Android is all I know on the subject

[jonywalker]

yes, the other guys used either static build or did link by themselv, just like I did before, made ffmpeg build script for enable-static, and then call ld to link *.a files to build a single ffmpeg.so in a separate step. Just in the new ffmpeg release, there are multiple external tables, which are the same tables distributed to number of static libraries. It is not error but warning. These create multple copies of instance and may cause android app crash, and this is the reason why android community suggests NDK user to take shared libraries rather static libraries.

[rogerdpack]

yes, the other guys used either static build or did link by themselv, just like I did before, made ffmpeg build script for enable-static, and then call ld to link *.a files to build a single ffmpeg.so in a separate step. Just in the new ffmpeg release, there are multiple external tables, which are the same tables distributed to number of static libraries. It is not error but warning. These create multple copies of instance and may cause android app crash, and this is the reason why android community suggests NDK user to take shared libraries rather static libraries.

I'd re-ask your question on the ffmpeg-user mailing list (at least I'm unaware of a configure option to disable naming...). Ask them what they suggest. And report back of course
-r

[jonywalker]

Hi rogerdpack,
first, thanks a lot of your contribution here. With your help I did understand the cross shared build for winows. I solved the versioning problem by applying minimal modification to the configure, and made sure that this doesn't have impact to any other build by adding following lines to the position line nr. 2272
--disable-symver)
SLIBNAME_WITH_VERSION='$(SLIBNAME).$(LIBVERSION)'
SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
LIB_INSTALL_EXTRA_CMD='$$(RANLIB) "$(LIBDIR)/$(LIBNAME)"'
SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
SLIB_INSTALL_LINKS='$(SLIBNAME)'
for android build just added option ./configure ----disable-symver
and we would have build result with libavcodec-54.so and libavformat-54.so and so on as output, then we make our apps link to libavcodec-54.so and libavformat-54.so as so on instead of linking to the symbolic links.
I am going to open another topic for discussion about build script with libstagefright.
The current build script tools/build_libstagefright is not correct.
The error "libstagefright_h264 not available" is resulted from the error from the script, not because the source and libs are not available. The thing of build stagefright is very complicated, and in current state of ffmpeg is not possible to build it because there are some unnecessary mudules required which are not abailable for the build system. I am writing now own interface library to open openmaxx hardware decoder. The software decoder of ffmpeg is not able to decode HD video in full speed. The source code of ffmpeg libstagefright interface doing two times copy of pixel buffer, which brakes down the speed too. The real hardware decoer should be able to do decoding and rendering in one step.

[rogerdpack]

Hi rogerdpack,
first, thanks a lot of your contribution here. With your help I did understand the cross shared build for winows. I solved the versioning problem by applying minimal modification to the configure, and made sure that this doesn't have impact to any other build by adding following lines to the position line nr. 2272
--disable-symver)
SLIBNAME_WITH_VERSION='$(SLIBNAME).$(LIBVERSION)'
SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
LIB_INSTALL_EXTRA_CMD='$$(RANLIB) "$(LIBDIR)/$(LIBNAME)"'
SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
SLIB_INSTALL_LINKS='$(SLIBNAME)'
for android build just added option ./configure ----disable-symver
and we would have build result with libavcodec-54.so and libavformat-54.so and so on as output, then we make our apps link to libavcodec-54.so and libavformat-54.so as so on instead of linking to the symbolic links.
I am going to open another topic for discussion about build script with libstagefright.
The current build script tools/build_libstagefright is not correct.
The error "libstagefright_h264 not available" is resulted from the error from the script, not because the source and libs are not available. The thing of build stagefright is very complicated, and in current state of ffmpeg is not possible to build it because there are some unnecessary mudules required which are not abailable for the build system. I am writing now own interface library to open openmaxx hardware decoder. The software decoder of ffmpeg is not able to decode HD video in full speed. The source code of ffmpeg libstagefright interface doing two times copy of pixel buffer, which brakes down the speed too. The real hardware decoer should be able to do decoding and rendering in one step.

Nice if the openmax is a plugin to ffmpeg maybe you can contribute it as a module back to ffmpeg core when you're done? That might be useful for either, ex: raspberry pi + ffmpeg