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.
Related
I have a C99 shared library that I want to link in a few statically static libraries (via --whole-archive). Note: All the static libs are built with -fPIC
I also would like to build a universal linux binary and thus have decided to use musl. When I try to link in the static libc.a from musl I get the following error:
# Building shared library tgt/Linux-x86_64/mylib/lib/mylib.so
/root/mylib/./tgt/Linux-x86_64/libmusl/bin/musl-gcc -Wl,-whole-archive -L./tgt/Linux-x86_64/libmusl/lib -L./tgt/Linux-x86_64/libz/lib -L./tgt/Linux-x86_64/libssl/lib -L./tgt/Linux-x86_64/libsasl/lib -L./tgt/Linux-x86_64/librdkafka/lib -L./tgt/Linux-x86_64/libcurl/lib -L./tgt/Linux-x86_64/libgjalloc/lib -L./tgt/Linux-x86_64/libavro/lib -L./tgt/Linux-x86_64/libunwind/lib -l:libc.a -l:libpthread.a -l:libz.a -l:libssl.a -l:libcrypto.a -l:libsasl2.a -l:libm.a -l:librt.a -l:libcrypt.a -l:libunwind-x86_64.a -l:librdkafka.a -l:libcurl.a -l:libgjalloc.a -l:libavro.a -Wl,-no-whole-archive -shared -fPIC -o tgt/Linux-x86_64/mylib/lib/mylib.so ./tgt/Linux-x86_64/mylib/obj/myfile.o ./tgt/Linux-x86_64/mylib/obj/myotherfile.o ./tgt/Linux-x86_64/mylib/obj/cJSON.o
/usr/bin/ld: ./tgt/Linux-x86_64/libmusl/lib/libc.a(exit.lo): relocation R_X86_64_PC32 against undefined hidden symbol `__fini_array_start' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make: *** [tgt/Linux-x86_64/mylib/lib/mylib.so] Error 1
My musl build looks like:
cd mystatic_libs_build_dir/musl; \
./configure CFLAGS='-fPIC' \
--enable-shared \
--enable-static \
--prefix=/root/mylib/tgt/Linux-x86_64/libmusl; \
make; make install;
# libmusl is available
exit.lo will be written in assembler which is why your CFLAGS='-fPIC' is not having the effect you intend. This is either 1. a bug in 'musl' or 2. intentional and they do not support statically linking into .so's.
I would assume that it is unintentional and file a bug against 'musl'
You could also edit the asm yourself if you need a fix quickly.
Finally you might be able to configure musl to build with no asm?
Slightly off topic, but other options for a universal binary are:
Simply linking against glibc on the oldest version of Linux that you support.
Rather than struggling with a dependency on 'musl', simply use the Linux kernel api's directly.
Recompile musl as long as your own code with CFLAGS="-fPIC -Wa,-mrelax-relocations=no" (your binutils version must be >=2.27).
I'm trying to cross-compile Qt5 for the Freescale i.MX6 processor. I've already built an image using the latest Yocto package.
Before compilation of qtbase, a test for OpenGL functionality is first ran by compiling an some OpenGL code. However, during this test the compiler complains that an incompatible libc.so.6 is found.
I've discovered in another post (which I can't find at the moment), that such an error occurs because /lib/libc.so.6 is actually a symbolic link which points to the actual shared object file. However, the compiler does not use the shared object file pointed to by libc.so.6, instead trying to link to the symbolic link itself, thus the compatibility issue.
Here is the output when the configure script is ran:
OpenGL ES 2.x auto-detection... ()
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -c -pipe -mfloat-abi=softfp -O2 -O2 -march=armv7-a -mfpu=neon -DLINUX=1 -DEGL_API_FB=1 -Wall -W -fPIE -I../../../mkspecs/devices/linux-imx6-g++ -I. -I/home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/include -o opengles2.o opengles2.cpp
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -Wl,-rpath-link,/home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/lib -Wl,-O1 -o opengles2 opengles2.o -L/home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/lib -lGLESv2 -lEGL -lGAL
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find /lib/libc.so.6
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: skipping incompatible /usr/lib/libc_nonshared.a when searching for /usr/lib/libc_nonshared.a
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find /usr/lib/libc_nonshared.a
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find /lib/ld-linux.so.3
collect2: error: ld returned 1 exit status
gmake: *** [opengles2] Error 1
OpenGL ES 2.x disabled.
The OpenGL ES 2.0 functionality test failed!
Here is the script I used to supply the proper options to the configure script:
#!/bin/sh
./configure -v -opensource -confirm-license -no-pch -opengl es2 \
-make libs -device imx6 \
-make examples -make demos \
-device-option CROSS_COMPILE=/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi- \
-sysroot /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint -no-gcc-sysroot \
-prefix /opt/qt5
At the moment, I'm considering just renaming the actual shared object file to libc.so.6, but that doesn't seem like a good way to fix things.
It seems that you are compiling against the wrong libc. The location of the correct libc should be: /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/lib/ Can you check that? Run in that folder:
file libc.so.6
Have a look if the architecture is fine. I do not have the sources in front of me, so please give feedback if things are going wrong.
Your application is compiled in a chroot environment (see man chroot). The folder /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint acts as the new rootfolder for your application. This is configured in the -sysroot option of your configure script. This is not valid for gcc, because the -no-gcc-sysroot is on. So the linker is looking to your native /lib/ folder to find the libraries. They are not there of course.
So, can you try the following things:
1) remove the -no-gcc-sysroot option in the configure script. Configure again and try to make.
2) This can possibly fail because the compiler does not find back it's own components. Please mount the directory of the compiler into your chroot enviroment. Run the next commands:
mkdir /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/bin -p
mount --bind /home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/ /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/bin
Configure again and try again to make.
3) If it still is not working, the cross-compiler is not set properly. Change into the configure script argument list the CROSS_COMPILE argument:
CROSS_COMPILE=/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-
I wish you good luck. Let me know if it is working or not.
I am able to make a shared library without problems. I create libcbitcoin.so (without any errors) and attempt to link against it with an executable as well as OpenSSL libraries. I use this command:
gcc -L/media/sf_BitEagle_Projects/cbitcoin/build/bin -lcbitcoin \
-Wl-rpath,/media/sf_BitEagle_Projects/cbitcoin/build/bin -lssl -lcrypto \
-L/usr/local/ssl/lib/ -o /media/sf_BitEagle_Projects/cbitcoin/build/bin/testCBAddress \
/media/sf_BitEagle_Projects/cbitcoin/build/obj/testCBAddress.o \
/media/sf_BitEagle_Projects/cbitcoin/build/obj/CBOpenSSLCrypto.o
The bin directory is the location of the library. The obj directory has the object files I wish to link into an executable. In the command I use the -L, -l and -rpath* options which I thought was all that is needed for linking in Linux. It seems I am wrong since I get errors like:
/media/sf_BitEagle_Projects/cbitcoin/test/testCBAddress.c:40:
undefined reference to `CBNewByteArrayFromString'
CBNewByteArrayFromString is found in the library. For some reason it is not being linked. OpenSSL too:
/media/sf_BitEagle_Projects/cbitcoin/dependencies/crypto/CBOpenSSLCrypto.c:37:
undefined reference to `SHA1'
How do I get the linking to work?
GCC version: gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
It is on Linux Mint 13 (Maya).
Put the libraries after the object files on the link command line:
gcc /media/sf_BitEagle_Projects/cbitcoin/build/obj/testCBAddress.o \
/media/sf_BitEagle_Projects/cbitcoin/build/obj/CBOpenSSLCrypto.o \
-L/media/sf_BitEagle_Projects/cbitcoin/build/bin \
-lcbitcoin -Wl-rpath,/media/sf_BitEagle_Projects/cbitcoin/build/bin \
-L/usr/local/ssl/lib/ -lssl -lcrypto \
-o /media/sf_BitEagle_Projects/cbitcoin/build/bin/testCBAddress
If you don't do that, the linker may decide that it needs nothing from a particular library at the stage of the link where it scans the library, and then it won't rescan the library later after it finds some undefined symbols in the object files. If you put the object files first, you don't run into this problem.
I think it is caused by can not find symbol. GCC will first go through from the left and will try to put the library file at the end.
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.