search

CasparCG / server

CasparCG Server is a Windows and Linux software used to play out professional graphics, audio and video to multiple outputs. It has been in 24/7 broadcast production since 2006. Ready-to-use downloads are available under the Releases tab https://casparcg.com.
GNU General Public License v3.0
911 stars 268 forks source link

Linux link fails with relocation error #597

Closed sesse closed 6 years ago

sesse commented 7 years ago

Hi,

On an updated Debian unstable, building using ./set-variables-and-build-linux.sh:

[100%] Linking CXX executable generate_docs
/usr/bin/ld: warning: libgnutls.so.30, needed by //usr/lib/x86_64-linux-gnu/libcups.so.2, may conflict with libgnutls.so.28
/usr/bin/ld: warning: libnettle.so.6, needed by //usr/lib/x86_64-linux-gnu/libgnutls.so.30, may conflict with libnettle.so.4
/usr/bin/ld: warning: libhogweed.so.4, needed by //usr/lib/x86_64-linux-gnu/libgnutls.so.30, may conflict with libhogweed.so.2
/usr/bin/ld: /home/sesse/nmu/Server/dependencies64/boost/stage/lib/linux/libboost_system.a(error_code.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/sesse/nmu/Server/dependencies64/boost/stage/lib/linux/libboost_thread.a(thread.o): relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/sesse/nmu/Server/dependencies64/boost/stage/lib/linux/libboost_thread.a(once.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/sesse/nmu/Server/dependencies64/boost/stage/lib/linux/libboost_chrono.a(chrono.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/sesse/nmu/Server/dependencies64/boost/stage/lib/linux/libboost_filesystem.a(operations.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/sesse/nmu/Server/dependencies64/boost/stage/lib/linux/libboost_filesystem.a(path.o): relocation R_X86_64_32S against symbol `_ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/sesse/nmu/Server/dependencies64/boost/stage/lib/linux/libboost_filesystem.a(path_traits.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /home/sesse/nmu/Server/dependencies64/boost/stage/lib/linux/libboost_filesystem.a(codecvt_error_category.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

and then many other of the same errors. It seemingly affects both Boost and SFML.

sesse commented 7 years ago

The simplest workaround seems to be to un-vendor everything; here's a very hackish solution:

sudo apt install libass-dev libbluray-dev libfribidi-dev libgsm1-dev libmodplug-dev libmp3lame-dev libssl-dev libvpx-dev libxvidcore-dev libopus-dev librtmp-dev libtheora-dev libopencore-amrwb-dev libopencore-amrnb-dev

sudo apt install libsfml-dev
rm -r dependencies64/sfml/include
rm -r dependencies64/sfml/lib/linux
ln -s /usr/include dependencies64/sfml/include
ln -s /usr/lib/x86_64-linux-gnu ./dependencies64/sfml/lib/linux
perl -pi -e 's/sfml-(.*)-s/sfml-$1/g' common/CMakeLists.txt

sudo apt install libboost1.63-dev libboost-thread1.63-dev libboost-filesystem1.63-dev libboost-log1.63-dev libboost-locale1.63-dev libboost-regex1.63-dev
rm -r dependencies64/boost/boost
rm -r dependencies64/boost/stage/lib/linux
ln -s /usr/include/boost dependencies64/boost/boost
ln -s /usr/lib/x86_64-linux-gnu dependencies64/boost/stage/lib/linux

sudo apt install googletest
rm -r dependencies64/gtest/lib/linux/
rm -r dependencies64/gtest/include/gtest
ln -s /usr/include/gtest dependencies64/gtest/include/gtest
ln -s /usr/lib/x86_64-linux-gnu dependencies64/gtest/lib/linux

sudo apt install libavcodec-dev libavformat-dev libswscale-dev libavutil-dev libavfilter-dev libavdevice-dev
rm -r dependencies64/ffmpeg/lib/linux
rm -r dependencies64/ffmpeg/include
ln -s /usr/include dependencies64/ffmpeg/include
ln -s /usr/lib/x86_64-linux-gnu dependencies64/ffmpeg/lib/linux
sed -i '/ilbc/d' modules/ffmpeg/CMakeLists.txt
sed -i '/xavs/d' modules/ffmpeg/CMakeLists.txt

sed -i 's/-D_GLIBCXX_USE_CXX11_ABI=0/-DBOOST_LOG_DYN_LINK/' CMakeLists.txt

I still haven't figured out how to deal with Google Test (it needs some stuff around ExternalProject), so I've simply just ignored linking the unit test binary. Also, there are some changes in Boost around sinks that makes the compilation fail, which made me simply comment out that part as a hack.

It would be nice to at least have an option for doing this upstream, which is how a Linux distribution would want to build it.

dimitry-ishenko commented 7 years ago

@sesse in case you are interested, take a look at my PR #394 which allows you to build against system installed libraries. It's probably a bit outdated, as I haven't updated my server in a while

sesse commented 7 years ago

Hm, without response for a year :-/

dimitry-ishenko commented 7 years ago

If you are interested, I can try to bring it up to date with the current master. (It's probably a good time for me to update the server anyways.)

mauricev78 commented 7 years ago

Well i would be interested since i want to build against my systems FFMPEG no clue how to do that ;)

sesse commented 7 years ago

I would certainly be interested in this going upstream (it would fix this bug, for one), but that doesn't mean upstream is willing to take it in, of course.

HellGore commented 7 years ago

I agree that it would be nice to be able to build CasparCG on other distributions than Ubuntu 14.04 LTS but on the other hand it is nice to know that all the library versions are the same on Linux and Windows at all times. That is the reason why we have tried to bundle all the libraries and only make CasparCG interface with "system libraries" like for example X, OpenGL, GlibC and libstdc++.

Also it is hard to make a statement such as CasparCG 2.1.0 has been tested on Linux when everybody is using different versions of for example FFmpeg.

sesse commented 7 years ago

Yes, the Linux ecosystem is more heterogenous than, say, Windows. This causes some issues as you say, but it's generally something most people choose just to live with. You can say something like “we support distributions X and Y and Z, everything else is a best effort”—typically, distributions will be the ones doing most of the work of porting, although carrying large de-vendoring patchsets around can be a pain. And I don't know if CasparCG is carried by a lot of Linux distributions yet.

mauricev78 commented 7 years ago

If i understand it right the way you made PR #394 is that if you do it without options it will compile like intended / normal against known versions of lib's and stuff. I guess when you are trying the options you know that you are experimenting / doing stuff that could result in unstable behaviour.

dimitry-ishenko commented 7 years ago

@mauricev78 you are correct. You can selectively specify which system libraries to build against using the USE_SYSTEM_xxx variables. If you don't set any, then the server will build with all the bundled libraries.

dimitry-ishenko commented 7 years ago

I've rebased the PR but haven't had the time to test it yet. If anyone feels courageous, go ahead and try it :smile:

sesse commented 7 years ago

Can I ask you to add a USE_SYSTEM_ALL variant? :-)

mauricev78 commented 7 years ago

will try when i got a machine back from production. THANKS !!!

dimitry-ishenko commented 7 years ago

@sesse of course you can ask :smile:

In the build-scripts directory there is a file called system-build-linux.sh which builds the server with all vars enabled.

gizahNL commented 6 years ago

can confirm this issue while building 2.1

ronag commented 6 years ago

@gizahNL 2.2?

gizahNL commented 6 years ago

@ronag,no solely when compiling 2.1 on for example Debian Stretch

gizahNL commented 6 years ago

/usr/bin/ld: /root/casparcg_source_git/2.1.0/dependencies64/sfml/lib/linux/libsfml-system-s.a(ThreadLocal.cpp.o): relocation R_X86_64_32 against symbol __gxx_personality_v0@@CXXABI_1.3 can not be used when making a shared object; recompile with -fPIC

2.2 build does also fail, but for whole other reasons ;)

ronag commented 6 years ago

@gizahNL we won't put any more time into 2.1 unfortunately. If you want help with building 2.2 please open a new issue.

gizahNL commented 6 years ago

No problem. Is there a git revision of 2.2 that is considered buildable? I've been occasionally pulling and trying makes and seeing builds fail at different places. February 15, 2018 3:15 PM, "Robert Nagy" <notifications@github.com (mailto:%22Robert%20Nagy%22%20notifications@github.com)> wrote: @gizahNL (https://github.com/gizahnl) we won't put any more time into 2.1 unfortunately. If you want help with building 2.2 please open a new issue. 

—

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (https://github.com/CasparCG/server/issues/597#issuecomment-365939250), or mute the thread (https://github.com/notifications/unsubscribe-auth/AHomQoaDPclmMCAR3F-RNIu772HBICuIks5tVDwKgaJpZM4M-nt_).

ronag commented 6 years ago

I've been occasionally pulling and trying makes and seeing builds fail at different places.

Yea, sorry about that. It's been a bit hectic to meet the deadline for 2.2. There should not be any significant code changes for a while now. So if you try and build it now and we fix any issues you find the chances of breaking anything should be low.

ronag commented 6 years ago

No problem. Is there a git revision of 2.2 that is considered buildable?

Master SHOULD be buildable. But I don't know the status there since I don't build it myself and I tend to break it. It seems Visual Studio is much more forgiving. Once auto builds are up and running again this situation should be improved.

gizahNL commented 6 years ago

Yes I noticed the amount of code changes, and I didn't want to start writing PR's for hot code failing to build, as I imagine it would be creating a lot of useless interuption. I'll send a PR in from a failed 2.2 build and I'll try to see how a Dockerbuild goes.

February 15, 2018 3:33 PM, "Robert Nagy" <notifications@github.com (mailto:%22Robert%20Nagy%22%20notifications@github.com)> wrote: I've been occasionally pulling and trying makes and seeing builds fail at different places. 

Yea, sorry about that. It's been a bit hectic to meet the deadline for 2.2. There should not be any significant code changes. So if you try and build it now and we fix any issues you find the chances of breaking anything should be low. 

—

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (https://github.com/CasparCG/server/issues/597#issuecomment-365944518), or mute the thread (https://github.com/notifications/unsubscribe-auth/AHomQqbQFLQz0bgGXDjQPe8frl5bAlNpks5tVEA-gaJpZM4M-nt_).