Consider adding rpath=. to example binaries

[jonesmz]

I was checking out the new example apps (Which, btw, sadly still don't work on my linux machine, though they don't crash or throw exceptions anymore :-)) and, since it'd been a good while since I toyed with them last, I ended up spending about half an hour trying to figure out what wasn't working that they would claim they couldn't find libraries in their own directory.

Turned out, ld wasn't looking for the libraries in the bin folder, just the default system ld library path.

If you add either an rpath=. (for cwd) or an rpath=${build artifact output directory}, that issue would be alleviated.

Looking here: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling

CMake has support for Rpath when building, and rpath when installing, so when someone runs "make install", the rpath fo rthe installed binaries and libraries is set appropriately for the system.

That, or add some more documentation to the Readme.md about launching the newly built examples.

[BearishSun]

Mesa issues are still high on the priority list but they are unlikely to make it out in v1.0.0 beta (yes for final release of course).

I do set RPATH to $ORIGIN, which should look for the libraries in the current folder. To be clear did you run make install (since CMake messes with the path during the install step)? Although I don't think examples have an install step configured so perhaps this wasn't even an option?

I'll take a proper look at this later today or tomorrow.

[jonesmz]

Thanks for looking into it.

No I didn't run make install. I was trying to run from bin. Sorry for the short response. Am on mobile and away from home.

[BearishSun]

I cannot reproduce this. I'm on Ubuntu 17.04, compiling with GCC 7.0.1.

Are you using Clang? Or perhaps it an issue with the bash and how it parses $ORIGIN (might need to be escaped on different distros)?

You could try doing readelf -d GUI | grep R.*PATH (replace GUI with any example) and see if the RUNPATH/RPATH looks solid. On my end I have a RUNPATH entry, with two elements, $ORIGIN and an absolute path to the bin/x64/Release folder. If I run the same command on libbsf.so it only reports a RUNPATH with a single entry, $ORIGIN.

[jonesmz]

jonesmz@ymir ~ $ which c++
/usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0/c++

jonesmz@ymir ~ $ bash --version
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)

jonesmz@ymir ~ $ uname -a
Linux ymir 4.14.8-gentoo-r1 #1 SMP Thu Dec 21 19:05:19 CST 2017 x86_64 Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz GenuineIntel GNU/Linux

jonesmz@ymir ~ $ rm -rf bsfExamples ; git clone https://github.com/GameFoundry/bsfExamples.git ; mkdir bsfExamples/Build ; cd bsfExamples/Build ; cmake -G Ninja .. ; ninja ; cd ../bin/x64/Release ; ./Audio

Cloning into 'bsfExamples'...
remote: Counting objects: 161, done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 161 (delta 84), reused 134 (delta 57), pack-reused 0
Receiving objects: 100% (161/161), 56.96 KiB | 1.19 MiB/s, done.
Resolving deltas: 100% (84/84), done.
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
Defaulting to release build.
-- Looking for snappy installation...
-- ...snappy OK.
-- Looking for nvtt installation...
-- ...nvtt OK.
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/libX11.so
-- Looking for LibUUID...
-- ...LibUUID OK.
-- Found the following ICU libraries:
-- data (required)
-- uc (required)
-- Found ICU: /usr/include (found version "60.2")
-- Found OpenGL: /usr/lib/libGL.so
-- Looking for OpenAL installation...
-- ...OpenAL OK.
-- Looking for ogg installation...
-- ...ogg OK.
-- Looking for vorbis installation...
-- ...vorbis OK.
-- Looking for FLAC installation...
-- ...FLAC OK.
-- Looking for PhysX installation...
-- ...PhysX OK.
-- Looking for FBXSDK installation...
-- ...FBXSDK OK.
-- Looking for freetype installation...
-- ...freetype OK.
-- Looking for freeimg installation...
-- ...freeimg OK.
-- Looking for XShaderCompiler installation...
-- ...XShaderCompiler OK.
-- Builtin assets for 'bsfExamples' are missing. Downloading package...
-- [download 0% complete]
-- [download 1% complete]
-- [download 2% complete]
...
...
...
-- [download 98% complete]
-- [download 99% complete]
-- [download 100% complete]
-- Extracting files. Please wait...
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jonesmz/bsfExamples/Build
[258/470] Building CXX object bsf/Foundation/CMakeFiles/bsf.dir/bsfCore/Mesh/BsMeshUtility.cpp.o
/home/jonesmz/bsf/Source/Foundation/bsfCore/Mesh/BsMeshUtility.cpp: In member function ‘void bs::TriangleClipperBase::processFaces()’:
/home/jonesmz/bsf/Source/Foundation/bsfCore/Mesh/BsMeshUtility.cpp:98:10: warning: ‘.bs::TriangleClipperBase::ClipEdge::verts’ may be used uninitialized in this function [-Wmaybe-uninitialized]
struct ClipEdge
^~~~~~~~
[461/470] Linking CXX shared library ../bin/x64/Release/libbsfFBXImporter.so
/home/jonesmz/bsf/Dependencies/FBXSDK/lib/libfbxsdk.a(fbxutils.o): In function fbxsdk::FbxPathUtils::GenerateFileName(char const*, char const*)': (.text+0x4b8): warning: the use of tempnam' is dangerous, better use `mkstemp'
[470/470] Linking CXX executable ../bin/x64/Release/CustomMaterials
A fatal error occurred and the program has to terminate!

• Error: InternalErrorException
• Description: Could not load dynamic library libbsfGLRenderAPI.so. System Error: libbsfGLRenderAPI.so: cannot open shared object file: No such file or directory
• In function: void bs::DynLib::load()
• In file: /home/jonesmz/bsf/Source/Foundation/bsfUtility/Utility/BsDynLib.cpp:37

Stack trace:
0) libbsf.so: bs::CrashHandler::getStackTraceabi:cxx11+0x1e4 [0x7f1c3b8df984]

1. libbsf.so: bs::CrashHandler::logErrorAndStackTrace(std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> > const&, std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> > const&, std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> > const&, std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> > const&, unsigned int) const+0x36d [0x7f1c3b8c0b1d]
2. libbsf.so: bs::CrashHandler::reportCrash(std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> > const&, std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> > const&, std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> > const&, std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> > const&, unsigned int) const+0x2c [0x7f1c3b8df4ec]
3. libbsf.so: bs::DynLib::load()+0x153 [0x7f1c3b849783]
4. libbsf.so: bs::DynLibManager::load(std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> >)+0x2d9 [0x7f1c3b84a869]
5. libbsf.so: bs::RenderAPIManager::initialize(std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> > const&, bs::RENDER_WINDOW_DESC&)+0xc6 [0x7f1c3bdb8f06]
6. libbsf.so: bs::CoreApplication::onStartUp()+0x914 [0x7f1c3bc93f44]
7. libbsf.so: bs::Application::onStartUp()+0x38 [0x7f1c3bf4e5a8]
8. ./Audio() [0x404df1]
9. /lib64/libc.so.6: __libc_start_main+0xfd [0x7f1c397155ad]
10. ./Audio() [0x40525a]

Then, if I do

jonesmz@ymir ~ $ export LD_LIBRARY_PATH=.
jonesmz@ymir ~ $ ./Audio
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed

But it otherwise launches and displays a white screen (Mesa problems as previously mentioned).

RPath settings:

jonesmz@ymir ~/bsfExamples/bin/x64/Release $ readelf -d GUI | grep R.*PATH
0x000000000000001d (RUNPATH) Library runpath: [:/home/jonesmz/bsfExamples/bin/x64/Release]
jonesmz@ymir ~/bsfExamples/bin/x64/Release $ readelf -d libbsf.so | grep R.*PATH
0x000000000000001d (RUNPATH) Library runpath: []

Though, it seems other .so's have their origin set as expected

jonesmz@ymir ~/bsfExamples/bin/x64/Release $ readelf -d libbsfGLRenderAPI.so | grep R.*PATH
0x000000000000001d (RUNPATH) Library runpath: [:/home/jonesmz/bsfExamples/bin/x64/Release:]

Here's all of them. Apparently only libbsf.so doens't have it. So maybe the rpath isn't the problem?:

jonesmz@ymir ~/bsfExamples/bin/x64/Release $ readelf -d libbsf*.so | grep R.*PATH
0x000000000000001d (RUNPATH) Library runpath: [:/home/jonesmz/bsfExamples/bin/x64/Release:]
0x000000000000001d (RUNPATH) Library runpath: [:/home/jonesmz/bsfExamples/bin/x64/Release:]
0x000000000000001d (RUNPATH) Library runpath: [:/home/jonesmz/bsfExamples/bin/x64/Release:]
0x000000000000001d (RUNPATH) Library runpath: [:/home/jonesmz/bsfExamples/bin/x64/Release:]
0x000000000000001d (RUNPATH) Library runpath: [:/home/jonesmz/bsf/Dependencies/libFLAC/lib:/home/jonesmz/bsf/Dependencies/libvorbis/lib:/home/jonesmz/bsf/Dependencies/OpenAL/lib:/home/jonesmz/bsfExamples/bin/x64/Release:]
0x000000000000001d (RUNPATH) Library runpath: [:/home/jonesmz/bsf/Dependencies/PhysX/lib:/home/jonesmz/bsfExamples/bin/x64/Release:]
0x000000000000001d (RUNPATH) Library runpath: [:/home/jonesmz/bsfExamples/bin/x64/Release:]
0x000000000000001d (RUNPATH) Library runpath: [:/home/jonesmz/bsfExamples/bin/x64/Release:]
0x000000000000001d (RUNPATH) Library runpath: []

[BearishSun]

Thanks for the detailed info.

None of your libraries have $ORIGIN set in RPATH, even though I explicitly set -Wl,-rpath=$ORIGIN flag in CMake. They all have it on my end.

Not sure why libbsf has no absolute path either, but solving the $ORIGIN issue should make that irrelevant.

I'm not using Ninja, but Makefiles. It's potentially that, or bash differences. I'll try tomorrow with the Ninja generator and see if the same thing happens on my end. If you get a chance try changing -Wl,-rpath=$ORIGIN flag in bsf/Source/CMake/Properties.cmake, at lines 80 and 100, to -Wl,-rpath=$$ORIGIN.

[jonesmz]

Building with make apparently avoids the same issue, it runs without complaining about the missing library.

Get this error instead :-P

jonesmz@ymir ~/bsfExamples/bin/x64/Release $ ./Audio
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
Cannot find texture parameter with the name 'gInputTex'
in void bs::TGpuParams::getTextureParam(bs::GpuProgramType, const String&, bs::TGpuParamTexture&) const [with bool Core = true; bs::String = std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> >] [/home/jonesmz/bsf/Source/Foundation/bsfCore/RenderAPI/BsGpuParams.cpp:333]

Cannot find buffer parameter with the name 'gOutput'
in void bs::TGpuParams::getBufferParam(bs::GpuProgramType, const String&, bs::TGpuParamBuffer&) const [with bool Core = true; bs::String = std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> >] [/home/jonesmz/bsf/Source/Foundation/bsfCore/RenderAPI/BsGpuParams.cpp:375]

Cannot find buffer parameter with the name 'gInput'
in void bs::TGpuParams::getBufferParam(bs::GpuProgramType, const String&, bs::TGpuParamBuffer&) const [with bool Core = true; bs::String = std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> >] [/home/jonesmz/bsf/Source/Foundation/bsfCore/RenderAPI/BsGpuParams.cpp:375]

Cannot find texture parameter with the name 'gOutput'
in void bs::TGpuParams::getLoadStoreTextureParam(bs::GpuProgramType, const String&, bs::TGpuParamLoadStoreTexture&) const [with bool Core = true; bs::String = std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> >] [/home/jonesmz/bsf/Source/Foundation/bsfCore/RenderAPI/BsGpuParams.cpp:354]

Cannot find texture parameter with the name 'gSHCoeffs'
in void bs::TGpuParams::getTextureParam(bs::GpuProgramType, const String&, bs::TGpuParamTexture&) const [with bool Core = true; bs::String = std::__cxx11::basic_string<char, std::char_traits, bs::StdAlloc<char, bs::GenAlloc> >] [/home/jonesmz/bsf/Source/Foundation/bsfCore/RenderAPI/BsGpuParams.cpp:333]

Segmentation fault

[jonesmz]

Sadly, the double $ in bsf/Source/CMake/Properties.cmake doesn't seem to do the trick.

[BearishSun]

So just using make instead of ninja triggers a segmentation fault when the example is ran? Plus the parameter warnings, which imply something also went wrong with the shader.

It feels very strange. I'm guessing it's some kind of memory corruption, but it manifests more easily when using make for whatever reason. I cannot reproduce this. If you get a chance to step through the program and see if you can narrow down where exactly the crash happens it would be very useful.

[BearishSun]

Using Ninja will indeed omit $ORIGIN on my end as well. I end up with the same issue as you trying to run the examples. I've updated the CMake files so they handle RPATH directly through CMake instead of manually providing linker flags: GameFoundry/bsf@4e824ef. This appears to resolve the issue on my end.

That said, libbsf.so still has no RPATH, either absolute or $ORIGIN, but the examples don't complain about missing libraries. So I'm not entirely sure how it works, nor will it work for you as well.