I'm trying to start Civilization: Beyond Earth via Steam but I get an error when the game is loading: /home/peter/.local/share/Steam/SteamApps/common/Sid Meier's Civilization Beyond Earth/./CivBE: error while loading shared libraries: libtbb.so.2: cannot open shared object file: No such file or directory I checked what the library belongs to and it is dev-cpp/tbb: [I] dev-cpp/tbb Available versions: 4.1.20121003-r1 (~)4.2.20131118 (~)4.2.20140122 (~)4.3.20141023 {debug doc examples} Installed versions: 4.3.20141023(00:26:22 2015-04-01)(-debug -doc -examples) Homepage: http://www.threadingbuildingblocks.org/ Description: High level abstract threading library The problem is that it is not multilib aware, so I am unable to build a 32-bit binary from it. Civilization:BE (and most Steam games it seems like) is 32-bit games. Reproducible: Always Steps to Reproduce: 1. Install steam-meta (with -steamruntime) from steam overlay 2. Install Civilization: Beyond Earth 3. Try to start it Actual Results: Game doesn't start.
Is there any way in which I can help to get this fixed? It is a complete show stopper in regards to starting Civilization Beyond Earth at all.
(In reply to Peter Asplund from comment #1) > Is there any way in which I can help to get this fixed? > > It is a complete show stopper in regards to starting Civilization Beyond > Earth at all. Sure, write the ebuild. If you have something working send a PR or attach things here in the bug. If you need help, join IRC and ping me.
Created attachment 404782 [details] new proposed ebuild I worked this ebuild out together with the #gentoo-dev-help and _AxS_ helped me to clean it up. He wrote an improved version, that he might push tomorrow, but I thought I might as well paste my version as well.
Thanks for your work! I will look into it.
(In reply to Peter Asplund from comment #3) > Created attachment 404782 [details] > new proposed ebuild Please use Unix line endings instead of DOS in future. I get this problem Files matching a file type that is not allowed: usr/lib32/libtbb.so.2 usr/lib32/libtbbmalloc.so.2 usr/lib32/libtbbmalloc_proxy.so.2 * ERROR: dev-cpp/tbb-4.3.20141023-r1::gentoo-cvs failed: * multilib-strict check failed! * * Call stack: * misc-functions.sh, line 592: Called install_qa_check * misc-functions.sh, line 217: Called source 'install_symlink_html_docs' * 80multilib-strict, line 47: Called multilib_strict_check * 80multilib-strict, line 43: Called die * The specific snippet of code:
Created attachment 404810 [details] build.log It looks like the 32bit aren't compiled as 32bit.
(In reply to Justin Lecher from comment #6) > Created attachment 404810 [details] > build.log > > It looks like the 32bit aren't compiled as 32bit. I continued to do some work on this ebuild after posting the above version to IRC. I'll be updating attachments in a moment. Here's what I get merged, though: /usr/lib32/libtbb.so.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped /usr/lib32/libtbbmalloc.so.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped /usr/lib32/libtbbmalloc_proxy.so.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped /usr/lib64/libtbb.so.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped /usr/lib64/libtbbmalloc.so.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped /usr/lib64/libtbbmalloc_proxy.so.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
Created attachment 404828 [details] new proposed ebuild, patching build system instead of sed'ing
Created attachment 404830 [details, diff] patch to the build system I found that the sed's, although functional, seemed a little too generic (they have the ability to catch too much). A patch to the build system seems to be a lot safer.
+*tbb-4.3.20141023-r1 (15 Jun 2015) + + 15 Jun 2015; Justin Lecher <jlec@gentoo.org> +files/tbb-4.3-build.patch, + +tbb-4.3.20141023-r1.ebuild: + Add multilib support, bug #545190; thanks Peter Asplund and Ian Stakenvicius + preparing the ebuild +
