FWGS / hlsdk-portable

Portable Half-Life SDK. GoldSource and Xash3D. Crossplatform.
https://xash.su
Other
271 stars 121 forks source link

vgui.so must be located in build/cl_dll directory to produce a correct build on Linux #267

Open FreeSlave opened 2 years ago

FreeSlave commented 2 years ago

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
a1batross commented 2 years ago

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.

a1batross commented 2 years ago

BUT:

a1batross commented 2 years ago

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.