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"
Related
I am trying to set up a script that automatically builds a small library I'm trying to write for whichever archs/OSs I want to include in the package all in one go. At the moment, just x86_64 Linux and Windows. I have no problem compiling the code for x86_64 Linux with g++ (not surprising). It's partly a practice exercise for myself.
However, I am having difficulty with the mingw-w64 linker. I decided to try building a "hello world" to see if it was an issue with my dependencies. I had the same problem.
The last command:
CXXFLAGS_WIN64="-Wall -O3 -m64 -std=c++11 -pedantic"
LINKFLAGS_MINGW64_EXE="-Wall -m64 -pedantic -L ${MINGW64_DIR}/lib"
INCLUDEDIR_MINGW64=/usr/x86_64-w64-mingw32/sys-root/mingw/include
#Build
x86_64-w64-mingw32-g++ ${CXXFLAGS_WIN64} -I ${includedir} -I ${INCLUDEDIR_MINGW64} -c ${srcdir}/helloworld0.cpp -o ${OBJ_TARG_DIR}/helloworld0.o
#Link
x86_64-w64-mingw32-g++ ${LINKFLAGS_MINGW64_EXE} -v -o helloworld0.exe ${OBJ_TARG_DIR}/helloworld0.o
outputs:
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --enable-threads=win32 --program-suffix=-win32 --program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as --with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic --enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking
Thread model: win32
gcc version 9.3-win32 20200320 (GCC)
COMPILER_PATH=/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/:/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/../../../../x86_64-w64-mingw32/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/:/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/../../../../x86_64-w64-mingw32/lib/
COLLECT_GCC_OPTIONS='-Wall' '-m64' '-Wpedantic' '-L/usr/x86_64-w64-mingw32/sys-root/mingw/lib' '-v' '-o' 'helloworld0.exe' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/collect2 -plugin /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/lto-wrapper -plugin-opt=-fresolution=/tmp/ccFdueja.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -m i386pep -Bdynamic -o helloworld0.exe /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/../../../../x86_64-w64-mingw32/lib/crt2.o /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/crtbegin.o -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -L/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32 -L/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/../../../../x86_64-w64-mingw32/lib ./obj/win64/helloworld0.o -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/crtend.o
/usr/bin/x86_64-w64-mingw32-ld: /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/../../../../x86_64-w64-mingw32/lib/crt2.o: in function `__tmainCRTStartup':
./build/x86_64-w64-mingw32-x86_64-w64-mingw32-crt/./mingw-w64-crt/crt/crtexe.c:288: undefined reference to `__mingw_init_ehandler'
/usr/bin/x86_64-w64-mingw32-ld: /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/../../../../x86_64-w64-mingw32/lib/crt2.o: in function `WinMainCRTStartup':
./build/x86_64-w64-mingw32-x86_64-w64-mingw32-crt/./mingw-w64-crt/crt/crtexe.c:194: undefined reference to `__security_init_cookie'
/usr/bin/x86_64-w64-mingw32-ld: /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/../../../../x86_64-w64-mingw32/lib/crt2.o: in function `mainCRTStartup':
./build/x86_64-w64-mingw32-x86_64-w64-mingw32-crt/./mingw-w64-crt/crt/crtexe.c:222: undefined reference to `__security_init_cookie'
collect2: error: ld returned 1 exit status
Most of this is the result of the -v flag for informational purposes, but the linker issue appears to be that it cannot resolve references to two functions: __security_init_cookie and __mingw_init_ehandler.
This was already odd as it was mingw's own modules that were calling these functions, but I thought I'd check for a missing library.
Nope. Upon snooping through the libraries in /usr/x86_64-w64-mingw32/lib, I found exports of these functions in libmingw32.a. Which as you can see in the verbose output appears to be explicitly included as -lmingw32 in the expanded mingw command!
So what gives? Is -lmingw32 incompatible with a 64-bit build? If so, why put it in the x86_64 directory and why isn't a 64-bit version included? Is mingw putting the libraries in the wrong order? Is there a circular dependency?
Anyway, I'm hoping there is just an issue with my configuration and this isn't something I am going to have to wait on mingw to fix. If anyone sees what's wrong, let me know! I didn't find much in terms of search results for my particular scenario so that makes me think I just messed up something obvious. It does seem odd though that mingw is having trouble resolving its own dependencies, so I worry I messed up something in the installation somehow? (I used apt-get...)
Using mingw-w64 version 9.3.0 on 64-bit Ubuntu 20.04.1 (arch amd64).
I'm going to continue poking around to see if I can figure out the dependency chain of this whole CRT thing. And of course if there is already a good post on this that I missed, feel free to link.
If you had the chance to read this through, thanks!
-B
I have the same issue. -lmingw32 does not work, but adding -Wl,--no-whole-archive /usr/x86_64-w64-mingw32/lib/libmingw32.a to the command line resolves the issue and my project is linked successfully.
I cann't realise the difference between -lmingw32 and specifying the full path. They should be identical, but the second one works and the first one does not
Im trying to compile gcc 4.8.5 under Red Hat 6. This is my procedure:
tar -xvzf archive.tar.gz
cd gcc-4.8.5
./configure --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release \
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object \
--enable-languages=fortran,c --prefix=/opt/gcc4.8.5
make
Then I get the following error:
make all-am
make[4]: Entering directory `/app/gfortran_build/gcc-4.8.5/host-x86_64-unknown-linux-gnu/lto-plugin'
/bin/sh ./libtool --tag=CC --tag=disable-static --mode=link gcc -Wall -g -module -bindir /opt/gcc4.8.5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.5 -o
liblto_plugin.la -rpath /opt/gcc4.8.5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.5 lto-plugin.lo -Wc,../libiberty/pic/libiberty.a
libtool: link: gcc -shared .libs/lto-plugin.o ../libiberty/pic/libiberty.a -Wl,-soname -Wl,liblto_plugin.so.0 -o .libs/liblto_plugin.so.0.0.0
/usr/bin/ld: ../libiberty/pic/libiberty.a(simple-object-coff.o): relocation R_X86_64_PC32 against undefined symbol `simple_object_set_big_16' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
I already read about CFLAGS, but I wont get it to work.
kind regards
GCC is documented to need to be built outside of its source tree; see the configuring chapter of its installation documentation:
First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn’t get extensive testing; building where objdir is a subdirectory of srcdir is unsupported.
So you need to build it according to that rule. Hence your GCC build:
cd gcc-4.8.5
#wrong code from the original question! Don't use that
./configure --enable-bootstrap --enable-shared \
--enable-threads=posix --enable-checking=release \
--with-system-zlib --enable-__cxa_atexit \
--disable-libunwind-exceptions --enable-gnu-unique-object \
--enable-languages=fortran,c --prefix=/opt/gcc4.8.5
is wrong; I would recommend at least:
cd gcc-4.8.5
mkdir ../_BuildGCC
cd ../_BuildGCC
../gcc-4.8.5/configure --enable-bootstrap --enable-shared \
--enable-threads=posix --enable-checking=release \
--with-system-zlib --enable-__cxa_atexit \
--disable-libunwind-exceptions --enable-gnu-unique-object \
--enable-languages=fortran,c --prefix=/opt/gnu \
--program-suffix=-mine
then, after the entire build, probably with
make -j4
followed by some mkdir /opt/gnu with appropriate user and permission, then (in the same _BuildGCC)
make install DESTDIR=/tmp/gccinst
and finally cp -vr /tmp/gccinst/opt/gnu /opt/gnu to be run appropriately (perhaps as root...., and perhaps cp -va)
Then you would add /opt/gnu/bin/ to your PATH variable, and you would use gcc-mine to compile your code.
BTW, GCC is compatible for C programs since the ABI don't change. And GCC 4.8 is obsolete and unsupported. You'll better compile from source the supported versions (listed on gcc.gnu.org; in January 2018, GCC 7.2 & GCC 6.4)
Perhaps your particular Redhat system requires additional/specific CFLAGS to be appended into your configure command. You could ask your Redhat support, or try to append CFLAGS=-fPIE or CFLAGS=-fPIC at the end of your ../gcc-4.8.5/configure command.
At last, you might perhaps get such help on gcc-help#gcc.gnu.org, but you'll better try with a recent GCC. Few GCC folks remember 4.8 ....
If you really need precisely GCC 4.8 (but I doubt that), you could buy costly support (e.g. from RedHat or AdaCore folks) if needed.
With Google I found Installing gcc 4.8 and Linuxbrew on CentOS 6
it worked with the following:
../gcc-4.8.5/configure CC="/opt/gcc4.5/bin/gcc" --prefix=/opt/gcc4.8.5 --enable-languages=c,c++,fortran --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
The interesting part is CC=...
The installed gcc-version is 4.4. With this version, the compiling fails.
kind regards
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.
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).
This should be a pretty straightforward issue -- I'm trying to compile Lua (or rather lua-vec, which is a minor variant) on a CentOS Linux install, and I get the following error:
[jt#flyboy src]#make linux
make all MYCFLAGS=-DLUA_USE_LINUX MYLIBS="-Wl,-E -ldl -lreadline -lhistory -lncurses"
make[1]: Entering directory `/jt/flyboy/fly/lua/lua-vec/src'
gcc -o lua lua.o liblua.a -lm -Wl,-E -ldl -lreadline -lhistory -lncurses
/usr/bin/ld: cannot find -lreadline
collect2: ld returned 1 exit status
make[1]: *** [lua] Error 1
That would suggest the readline lib is not installed. But...
[jt#flyboy src]#ls /usr/lib/libreadline*
/usr/lib/libreadline.so.5 /usr/lib/libreadline.so.5.1
Interestingly, if I rearrange the order of readline/history/ncurses, whichever is first triggers the same error, so I suspect that this is some sort of a folder-specification problem, not a missing library problem.
Any ideas?
yum install readline-devel.x86_64 readline-devel.i386 ncurses-devel.i386 ncurses-devel.x86_64
seems to have done the trick! The odd thing is I have compiled this before without these libs... but enough time pondering life's mysteries...
libreadline is not enough, it will give you libraries related to readline. You need libreadline-dev for compiling package which depends upon readline like in above case.
In Red Hat like distros, name of package is readline-devel
Following command will do the trick in such environment:
$ yum install -y readline-devel
If somebody has this issue in ubuntu/debian:
sudo apt-get install libreadline-dev