FWGS
vgui.so must be located in build/cl_dll directory to produce a correct build on Linux
I didn't manage to overcome this issue. And it seems like Valve didn't either as vgui.so is located in both linux and linux/release directories in their repo.
We have a workaround in github workflow by just copying vgui.so into the appropriate directory. But it's not applied automatically on the local build. Maybe some hack should be added to cmake script.
About the problem itself: vgui.so is problematic library as it does not have a commonly used lib prefix in its name nor the defined soname. So linker has a hard time finding it and adding the dependency with proper path. When going with -l:vgui.so approach, it writes the absolute path as a dependency for client.so which is unacceptable obviously.
If you want to experiment with it yourself, use this script to check out the dependencies of the produced client library:
objdump -p client.so | grep NEEDED | tr -s ' ' | cut -d ' ' -f 3
Running this on client.so from Steam Half-Life fetches this:
libstdc++.so.6
libdl.so.2
libpthread.so.0
vgui.so
libSDL2-2.0.so.0
libc.so.6
In case of our sdk it must result in
libdl.so.2
vgui.so
libstdc++.so.6
libm.so.6
libc.so.6
It seems more like a bug of linker. If I'm using system toolchain, this doesn't happen anymore. If it uses steamrt toolchain, absolute path is written to the shared object.
It happens in both our HLSDK and vgui_support, compile set up using CMake and Waf.
Back in days when engine used cmake, I had a CMake macro that copied vgui.so before build starts, so it links normally.
- Switching from ld.bfd to ld.gold doesn't help.
- Setting rpath doesn't help.
BUT:
- Switching from old ld 2.22 to ld-2.30 binary that present in SteamRT helps
Solution from old engine https://github.com/FWGS/xash3d/blob/master/cmake/FWGSLib.cmake#L149-L173
Again, it seems irrelevant if we have binutils >2.30, as the post above shows. Probably some earlier versions could work too, if we want to target legacy.