Does anybody know how can I build libav static libraries (.lib) for use them in my projects?
Before compiling LibAV one needs to configure LibAV by 'configure' script. Use '--enable-static' :
./configure --enable-static
The script 'configure' generates make-files according to chosen or default parameters, example of LibAV configuration parameters:
./configure --target-os=mingw32 --arch=x86 --enable-shared --enable-static --enable-dxva2 --disable-encoders --enable-hwaccel=dxva2 --extra-cflags=-O3 --enable-pthreads
Related
I use this to configure ffmpeg:
./configure --enable-shared --enable-yasm --enable-openssl --enable-gpl --enable-libx264 --prefix=/mnt/newdatadrive/apps/ffmpeg/ffmpeg-master
But it returned a error:
OpenSSL <3.0.0 is incompatible with the gpl
But i need both of them, how to resolve this?
It seems to be that openSSL 3.0 is not compatible with GPL 2.0. My guess is that you should try using GPL 3.0 or higher instead. The issue seems to be that the apache license is not compatible with GPL 2.0.
You can try using --enable-gpl with --enable-version3 build params which should help.
You can try using --enable-nonfree as well. Not sure if this is useful though
You should consider looking into ./configure --help for more details on what you're doing.
Try to Use.
./configure --enable-shared --enable-yasm --enable-openssl --enable-gpl --enable-libx264 --enable-nonfree --prefix=/mnt/newdatadrive/apps/ffmpeg/ffmpeg-master
I'am trying to run the LibSourcey to use the Webrtc Streaming Server.
The thing is that i can't seem to make it work.
I struggled to cmake the project on my Ubuntu 16.04(Regexp in cmake files) but now its fixed .
The problem that i actually got is a shared object bug at compiling time :
usr/bin/ld: /home/kimmie/ffmpeg_build/lib/libswresample.a(options.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object;
recompile with -fPIC
/home/kimmie/ffmpeg_build/lib/libswresample.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
av/CMakeFiles/av.dir/build.make:783: recipe for target 'av/libscy_av.so.1.0.2' failed
Any help would be very much appreciated as i don't know what to do now.
I hit this same error on Ubuntu 16.04.
I ended up recompiling FFmpeg with flags to build the shared libraries. Following the code example boxes in the FFmpeg Compilation Guide, I added the following two flags to the ./configure lines where applicable:
--enable-pic
--enable-shared
I removed the --disable-shared flags as well.
I added --enable-pic and --enable-shared to every component and removed the flag if it returned a message that it was unrecognized for that component. At least libx264, libfdk-acc, and libmp3lame needed --enable-shared. And then for the final FFmpeg (copy and pasted from FFmpeg guide linked to above):
PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \
--prefix="$HOME/ffmpeg_build" \
--pkg-config-flags="--static" \
--extra-cflags="-I$HOME/ffmpeg_build/include" \
--extra-ldflags="-L$HOME/ffmpeg_build/lib" \
--bindir="$HOME/bin" \
--enable-gpl \
--enable-libass \
--enable-libfdk-aac \
--enable-libfreetype \
--enable-libmp3lame \
--enable-libopus \
--enable-libtheora \
--enable-libvorbis \
--enable-libvpx \
--enable-libx264 \
--enable-libx265 \
--enable-nonfree \
--enable-pic \
--enable-shared
Note the last two lines in my example are different than the FFmpeg
guide.
After you do all of that, it's probably best to delete the Libsourcey source and build folder and start over with that.
It took me about 4-5 days off and on to finally compile and successfully build Libsourcey with FFmpeg and WebRTC dependencies. I hit some other snags as well, so be sure to tag me if you have other questions. Note: I am noob at Linux building and not solid on all of the concepts; this is just what worked for me and perhaps it will work for you.
You have a linkage error, not a compilation error. You haven't run into a bug,
you have just attempted a linkage that cannot work.
You are trying to build a shared library libscy_av.so. All the object
files that are linked in a shared library must consist of Position Independent
Code. To generate
such an object file with gcc, you compile with the option -fPIC.
The linker discovers that your shared libary requires the object file
options.o, which is a member of the static library libswresample.a. It then
discovers that this options.o is not PIC, and so cannot be linked in
a shared library. The linkage fails and the linker advises you that
options.o must be recompiled with the -fPIC compiler option.
To comply with that advice, you would have to rebuild the static library libswresample.a from source, with -fPIC added to the compiler flags.
You might do that, but it is unusual for object files in a static library to
be PIC, and there is an easier option. Your mistake was in linking against
the static version of libswresample (libswresample.a) rather than the
shared version (libswresample.so), which will be PIC. Just correct that mistake. If you install
libswresample.a from a dev package provided by your package manager, then
it will also provide libswresample.so. If you have built libswresample
from source, then the build system will also build both.
Situation
I have a large multi-library c++ project that has been compiled on Debian Squeeze with its native gcc 4.4 compiler so far.
Now I wanted to benefit from a newer gcc version and its optimizations for a specific architecture, thus being able to use FMA and AVX instructions on my target platform. I have compiled gcc 4.9.1 from source and had to also compile new binutils because the linker did not support the instruction set I guess.
Problem
With the new gcc and ld I now had to modify by cmake based build system to also link libraries like pthread, rt or crypto which I did not have to specify explicitly before. How is that? Did something change in the last versions of gcc or the linker that I should be aware of? Is there a way to get back the "old" behavior of not having to be that specific? Having to specify those linking dependencies makes my CMakeLists.txt less readable by cluttering it with platform specific if-clauses.
Versions
System gcc and ld:
$ /usr/bin/g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
$ /usr/bin/ld -v
GNU ld (GNU Binutils for Debian)
2.20.1-system.20100303
Custom gcc and ld:
$ /usr/local/bin/g++-4.9 -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++-4.9
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.9.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c++ --enable-threads --enable-threads=posix --enable-shared --with-system-zlib --without-included-gettext --enable-clocale=gnu --enable-checking=release --program-suffix=-4.9 --enable-bootstrap
Thread model: posix
gcc version 4.9.1 (GCC)
$ /usr/local/bin/ld -v
GNU ld (GNU Binutils) 2.24.51.20140916
Actually, the proper CMake build of a thread-enable application should include detection of Threads library which indeed performs platform-dependent tests and then fills appropriate variables. See this for more info.
Regarding the other libs in the question, I think that these libraries are platform specific, so you have to add them only on a particular platform. And indeed they are required on those platforms. Why with your previous compiler the program doesn't need these libraries, at least explicitly specified? Maybe because they are implicitly linked in. Try to gcc -dumpspecs for both compiler versions and compare the output.
I get this error when attempting to compile ffmpeg on a 64bit CentOS machine.
Here are my ./configure options:
./configure --enable-shared --enable-gpl --enable-nonfree --enable-postproc --enable-swscale --enable-pthreads --enable-libx264 --enable-libxvid --enable-libvorbis --enable-libfaac --enable-libmp3lame --enable-libvpx
make
I get the following error when compiling the source:
/usr/bin/ld: /usr/local/lib/libvpx.a(vpx_codec.c.o): relocation R_X86_64_32 against .rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libvpx.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libavcodec/libavcodec.so.54] Error 1
How do I get around this error, and get libvpx up and running with the latest ffmpeg on my 64-bit CentOS box?
Since you configured FFMPEG with "--enable-shared", you also need to configure some of it's other libraries with "--enable-shared" also, and they must all use the same setting.
This error message is basically telling you to compile libvpx again with "--enable-shared" added to the configure command, then try compiling FFMPEG again (also configured with "--enable-shared"). Chances are that you will then get the same error but it will say "libx264" or "libmp3lame" instead of "libvpx", so you will also need to recompile those libs with "--enable-shared" in the configure command.
I got a similar error while compiling ffmpeg on an x86_64 machine running Oracle Linux 6.3. Oracle Linux is based on Red Hat and is thus similar to CentOS in the original question.
configure:
./configure --enable-shared --enable-nonfree --enable-libmp3lame --enable-libfaac --enable-libx264 --enable-encoder=x264 --enable-gpl
make:
/usr/bin/ld: /usr/local/lib/libx264.a(common.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libx264.a: could not read symbols: Bad value
In my case, this answer, although partly specific to Ubuntu, shed more light on the underlying issue with respect to x86_64 systems in general:
"I believe if you enable-shared on FFmpeg you have to do the same on
x264 on x86_64 systems, otherwise you'll have a PIC shared FFmpeg and
non-PIC static x264."
The fix was to ensure the x264 sources which I originally compiled using the "--enable-static" flag with configure (which generated "/usr/local/lib/libx264.a") was re-compiled using the "--enable-shared" flag which generates the correct target of "/usr/local/lib/libx264.so":
1st Attempt:
1. cd /tmp
2. wget ftp://ftp.videolan.org/pub/x264/snapshots/last_x264.tar.bz2
3. tar xfv last_x264.tar.bz2;
4. cd x264-snapshot-xxxxxx
5. ./configure --enable-static
6. make && make install
2nd Attempt:
1. cd /tmp/x264-snapshot-xxxxxx
2. make distclean
3. ./configure --enable-shared
4. make && make install
Try
CFLAGS=-fPIC ./configure ...<your config options>...
To add the flag that the error mentions is missing.
(And the question is...?)
Shared libraries must be composed of PIC object code, but ffmpeg failed to do so.
Did you compile your libvpx with --shared and -fPIC so it generated libvpx.so*?
If not, you can try comment #6 and #7 in this issue.
I had this problem in MythTV build with libx264.a
I downloaded and built as Saheed suggested.
The only thing is that /usr/local/lib/libx264.a was not changed when I did "make install". I had to do "make install-lib-static"
I am looking to create a native build of GCC for an ARM system and I am running into some trouble. The build machine is i686-linux. Every tutorial I see tells me how to set up the actual cross compiling suite (which I have already done using crosstools-ng). However, I don't see anything related to compiling native ARM GCC. The configure string I used is below, I have set up the sysroot only with headers. I have also cross-compiled and installed GMP and MPFR.
../../gcc-4.3.5/configure \
--host=arm-unknown-linux-gnueabi \
--build=i686-build_pc-linux-gnu \
--target=arm-unknown-linux-gnueabi \
--prefix=/home/vm/gcc-native/sysroot \
--with-sysroot=/home/vm/gcc-native/sysroot \
--enable-shared --enable-threads --disable-libmudflap --disable-libssp \
--disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld \
--enable-languages=c,c++ --enable-symvers=gnu --enable-__cxa_atexit \
--disable-nls --disable-multilib \
--with-gmp=/home/vm/gcc-native/sysroot/ \
--with-mpfr=/home/vm/gcc-native/sysroot/
GCC will build for a while but then dies with this:
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile.
I am not sure how this would even run on my system as I am building on i686-linux and the target/host are both arm-linux. My thought right now is to find a ltib distro and looking at a spec file for GCC and trying to follow all of the steps. The GCC that ltib shipped with for my board fails to compile on my system due to conflicts with the std namespace.
Any info/links would be appreciated!
Look in the config.log file (maybe not the top-level one) and see what it was trying to do when the test failed. Just grep for the cannot compute suffix message and you should find the right bit (it won't be at the end of the file).
Note that you'll need a working arm-unknown-linux-gnueabi-gcc on your path somewhere if you want to build a cross-native toolchain. I.e. you need a cross compiler to build cross-native compiler.