Jump to content

Installation on CentOS 7


gw1500se
 Share

Recommended Posts

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 by s0600204
Show the comment I'm responding to (as we've just started a new page, it's not immediately obvious).
Link to comment
Share on other sites

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... 

 

Link to comment
Share on other sites

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 ? 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...
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

Link to comment
Share on other sites

  • 4 months later...

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.

  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...