s0600204 Posted December 16, 2018 Report Share Posted December 16, 2018 (edited) 1 hour ago, skaiware said: Should nt update-workspaces.sh add -L/usr/local/lib to the linking commands ? Why should it? That path is already included for search by default. The problem is that it is searched after /usr/lib64, /usr/local/lib64 in that order (plus a couple of distro-specific paths). That's fine for the vast majority of users and systems, it's just problematic in this case. What's really annoying is that the gcc search path (for include headers) goes (by default*) /usr/local/include, /usr/include (eg. locally-generated then repo-provided); whilst the compile-time linker searches for libraries in the other direction (repo-provided then locally-generated). (Then you have the run-time linker which doesn't search /usr/local/lib{64} at all. Which does make a sort-of sense, I guess.) You could modify ./premake/external_libraries5.lua to append that to the start of the search path (so the linker searches there first - unlike gcc, ld claims not to mind paths appearing more than once); but unless you've told b2 to name the 1.68 libs with the -mt suffix, you'll also have to tell ./premake/external_libraries5.lua to stop preferring files with the suffix -mt over files without. * - 0 A.D. messes this up, hence revision. Edited December 16, 2018 by s0600204 Show the comment I'm responding to (as we've just started a new page, it's not immediately obvious). Quote Link to comment Share on other sites More sharing options...
skaiware Posted December 17, 2018 Report Share Posted December 17, 2018 Ok tks. So 1st if 0ad expects/needs mt boost, then lets build the mt libs : sudo ./b2 threading=multi --layout=tagged --with-thread install $ ll /usr/local/lib/libboost_* -rw-r--r--. 1 root root 245756 Dec 12 20:54 /usr/local/lib/libboost_filesystem.a lrwxrwxrwx. 1 root root 29 Dec 12 20:53 /usr/local/lib/libboost_filesystem.so -> libboost_filesystem.so.1.68.0 -rwxr-xr-x. 1 root root 127208 Dec 12 20:53 /usr/local/lib/libboost_filesystem.so.1.68.0 -rw-r--r--. 1 root root 65844 Dec 12 20:54 /usr/local/lib/libboost_system.a -rw-r--r--. 1 root root 65844 Dec 16 16:36 /usr/local/lib/libboost_system-mt.a lrwxrwxrwx. 1 root root 28 Dec 16 16:36 /usr/local/lib/libboost_system-mt.so -> libboost_system-mt.so.1.68.0 -rwxr-xr-x. 1 root root 24800 Dec 16 16:36 /usr/local/lib/libboost_system-mt.so.1.68.0 lrwxrwxrwx. 1 root root 25 Dec 12 20:53 /usr/local/lib/libboost_system.so -> libboost_system.so.1.68.0 -rwxr-xr-x. 1 root root 24800 Dec 12 20:53 /usr/local/lib/libboost_system.so.1.68.0 -rw-r--r--. 1 root root 292928 Dec 16 16:37 /usr/local/lib/libboost_thread-mt.a lrwxrwxrwx. 1 root root 28 Dec 16 16:36 /usr/local/lib/libboost_thread-mt.so -> libboost_thread-mt.so.1.68.0 -rwxr-xr-x. 1 root root 187512 Dec 16 16:36 /usr/local/lib/libboost_thread-mt.so.1.68.0 Now just retrying to build 0ad without touching premake script yet but in theory it still should nt link correctly... Quote Link to comment Share on other sites More sharing options...
skaiware Posted December 17, 2018 Report Share Posted December 17, 2018 Ok still failing to link because make/ld still trying to use the OS boost libs instead of usr local libs. I dont see any external_libraries5.lua : $ find . -iname "extern*" ./libraries/source/spidermonkey/mozjs-38.0.0/media/webrtc/trunk/tools/gyp/test/rules/src/external ./libraries/source/spidermonkey/mozjs-38.0.0/media/webrtc/trunk/tools/gyp/test/rules/src/external/external.gyp ./libraries/source/spidermonkey/mozjs-38.0.0/media/webrtc/trunk/tools/gyp/test/external-cross-compile ./libraries/source/spidermonkey/mozjs-38.0.0/js/src/build-debug/config/external ./libraries/source/spidermonkey/mozjs-38.0.0/js/src/build-release/config/external ./libraries/source/spidermonkey/mozjs-38.0.0/config/external ./build/premake/extern_libs5.lua ./build/premake/extern_libs4.lua ./source/lib/external_libraries More globally, people anyway probably also have to build/install libcurl and probably libssh, and even some other third parties. The same kind of issue should then happen. Any needed third parties should be installed in /usr/local/lib, not in the OS system. Looks like the 0ad build system is missing an option to prefer the libs in /usr/local/lib, not the OS ones. Would nt such an option (for instance "--prefer-usr-local-libs", adding -L/usr/local/lib to linking commands) resolves this and upcoming linking issues ? Quote Link to comment Share on other sites More sharing options...
s0600204 Posted December 17, 2018 Report Share Posted December 17, 2018 Ach, my apologies, I mean ./build/premake/extern_libs5.lua. (Was getting late and tired.) The simplest change that should work is: --- a/build/premake/extern_libs5.lua +++ b/build/premake/extern_libs5.lua @@ -197,6 +197,8 @@ extern_lib_defs = { link_settings = function() if os.istarget("windows") or os.istarget("macosx") then add_default_lib_paths("boost") + else + syslibdirs { "/usr/local/lib" } end add_default_links({ -- The following are not strictly link dependencies on all systems, but 8 hours ago, skaiware said: Any needed third parties should be installed in /usr/local/lib, not in the OS system. Looks like the 0ad build system is missing an option to prefer the libs in /usr/local/lib, not the OS ones. Would nt such an option (for instance "--prefer-usr-local-libs", adding -L/usr/local/lib to linking commands) resolves this and upcoming linking issues ? You might have a point. I'm not familiar enough with other software projects to know how they handle this in their respective build systems. If you wish to look into it and create a patch for review (more general than the diff above), better minds than I can - and no doubt will - pass comment on it. (See here for how we accept patches.) I'm afraid real life commitments (eg. work) are going to take my focus for the next couple of days, so good luck. Quote Link to comment Share on other sites More sharing options...
skaiware Posted December 21, 2018 Report Share Posted December 21, 2018 On 12/17/2018 at 1:57 AM, s0600204 said: If you wish to look into it and create a patch for review (more general than the diff above), better minds than I can - and no doubt will - pass comment on it. (See here for how we accept patches.) I'm afraid real life commitments (eg. work) are going to take my focus for the next couple of days, so good luck. > You might have a point. I'm not familiar enough with other software projects to know how they handle this in their respective build systems. Well I guess the majority of projects today uses cmake and ExternalProject_Add() : https://cmake.org/cmake/help/latest/module/ExternalProject.html I ve seen CMake capable to download/clone/pull the dep, unarchive, build, install and automatically setup linking for the main project to link with the sub external projects. > I m afraid real life commitments (eg. work) are going to take my focus for the next couple of days, so good luck. It looks like 0ad build system has accumulated too much technical debt. I prefer to wait for you to be back. Perhaps to be continued. 1 Quote Link to comment Share on other sites More sharing options...
s0600204 Posted January 14, 2019 Report Share Posted January 14, 2019 On 12/21/2018 at 4:49 AM, skaiware said: On 12/17/2018 at 9:57 AM, s0600204 said: You might have a point. I'm not familiar enough with other software projects to know how they handle this in their respective build systems. Well I guess the majority of projects today uses cmake and ExternalProject_Add() After a bit of research (and playing around a little with both build systems), it appears that projects that use CMake don't have to handle this because CMake handles it for them. Comparing how premake and CMake specify which libraries should be included: premake tells the linker to include a certain library but leaves it up to the linker to locate it. CMake, on the other hand, locates the library itself and, should the library not be in /usr/lib, adds the non-standard path via -rpath (an approach that might get them in trouble with certain OSes) so that both the compile-time linker (ld) and the run-time linker (ld.so) can find it. Anyhow. Taking your suggestion of adding an option to our build system: https://code.wildfiregames.com/D1747 Quote Link to comment Share on other sites More sharing options...
s0600204 Posted May 27, 2019 Report Share Posted May 27, 2019 The change is now live in our code repository. To use, simply add the appropriate argument: ./update-workspaces.sh --prefer-local-libs Then run make as usual. You will also need a file in /etc/ld.so.d.conf with the contents /usr/local/lib so that the runtime linker can locate the local libraries. (If you're compiling and using local libs on a regular basis, there may already be such a file present.) The build instructions on the wiki have also been updated. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.