Topic: missing libboost-signals-mt.so in debian jessy (testing)?

1 — 10 of 11 Posts 1 2 next ››

chaos91 Topic Opener Joined: 2009-03-15, 21:14 Posts: 31 Pry about Widelands Location: germany	Posted at: 2013-09-09, 18:27 Hi, i'm trying to upgrade widelands via the updatescript I'm getting this error: [100%] Built target widelands_all make[2]: * Keine Regel vorhanden, um das Target »/usr/lib/libboost_signals-mt.so«, benötigt von »src/widelands«, zu erstellen. Schluss. make[1]: * [src/CMakeFiles/widelands.dir/all] Fehler 2 make: *** [all] Fehler 2 in my /usr/lib/ there are no libboost files with "-mt" at the end atm i'm running libboost1.54 (standart one in jessie i think) (metapackage libboost-all-dev is also installed) i've looked around in the net for a while, but didn't find sth. useful What do I have to do? Edited: 2013-09-09, 18:28 Top Quote

QCS Joined: 2009-12-29, 21:47 Posts: 256 Tribe Member	Posted at: 2013-09-10, 07:23 Debian always named their libboost files always with a -mt at the end, for whatever reason. With jessie they seem to have changed that (see http://packages.debian.org/jessie/amd64/libboost-signals1.54-dev/filelist ) Some questions: Did you update to jessie lately? Does your FindBoost.cmake (which Debian had surely changed) already try to search for non-mt files? The error is somewhere within this scope. Maybe try a new clean checkout to make sure everything is "connected" newly after a package upgrade? CMake is evil. Top Quote

chaos91 Topic Opener Joined: 2009-03-15, 21:14 Posts: 31 Pry about Widelands Location: germany	Posted at: 2013-09-10, 15:21 i think i've installed this debian testing in Jan/2013 and haven't done a fresh install since (wheezy was released on 4. Mai 2013) (well i'm not exactly sure about this, perhaps i did a reinstall after the new kernel arrived, but there is still a libboost_signals.so.1.49.0 in /usr/lib) i believe findboost.cmake is still searching for this suffix, but well i'm a noob. At the beginning of the file, located between some explanations, i found this: # Boost libraries come in many variants encoded in their file name. Users or # projects may tell this module which variant to find by setting variables: # Boost_USE_MULTITHREADED - Set to OFF to use the non-multithreaded libraries ('mt' tag). Default is ON. later in the text, for example: if(NOT DEFINED Boost_USE_MULTITHREADED) set(Boost_USE_MULTITHREADED TRUE) endif() I think thats the problem, so imho a fresh checkout shouldn't solve anything... Am i right that it is dangerous to edit that file by myself? How did it come to this situation? As you say, wheezy used this suffix (http://packages.debian.org/wheezy/i386/libboost-signals1.49-dev/filelist) So why didn't i get a new findboost.cmake? the old suffix is completly gone from my usr/lib/ Or do i just have to wait for a new cmake to arrive? Or am i wrong and "set to OFF to use non-multithreaded libraries ('mt' tag)" means it will look for this suffix if set to off, and i have to do a fresh checkout? (i think i will try it this evening) greetings Edited: 2013-09-10, 15:45 Top Quote

QCS Joined: 2009-12-29, 21:47 Posts: 256 Tribe Member	Posted at: 2013-09-10, 16:10 I am just at this moment installing a new test system with Jessie to see what this all is about Please have a little patience! Thanks CMake is evil. Top Quote

QCS Joined: 2009-12-29, 21:47 Posts: 256 Tribe Member	Posted at: 2013-09-10, 17:05 Hmm... did a fresh setup of a Jessie system, installed the packages according to the BuildingWidelands wiki page (sudo apt-get install bzr cmake g++ gettext libboost-signals-dev libboost-test-dev libglew-dev libpng-dev libsdl-gfx1.2-dev libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-net1.2-dev libsdl-ttf2.0-dev liblua5.1-dev python zlib1g-dev), mkdir widelands; cd widelands bzr init-repo . bzr branch lp:widelands cd widelands ./compile.sh Everything works as expected... I don't have an -mt file : # locate boost_signals /usr/lib/libboost_signals.a /usr/lib/libboost_signals.so /usr/lib/libboost_signals.so.1.54.0 # cmake -version cmake version 2.8.11.2 Edited: 2013-09-10, 17:06 CMake is evil. Top Quote

chaos91 Topic Opener Joined: 2009-03-15, 21:14 Posts: 31 Pry about Widelands Location: germany	Posted at: 2013-09-10, 17:41 same cmake version here, so I'm doing a fresh checkout atm btw. is "bzr init-repo ." really necessary? it's not mentioned at CompilingWidelands and i'm sure i didn't use it before (this time i did) Top Quote

QCS Joined: 2009-12-29, 21:47 Posts: 256 Tribe Member	Posted at: 2013-09-10, 18:18 No, bzr init-repo is not necessary. It is a habit for any developer... shared repository for different widelands branches are more convenient this way. CMake is evil. Top Quote

hjd Joined: 2011-06-12, 19:24 Posts: 164 At home in WL-forums Location: bugs.launchpad.net/widelands	Posted at: 2013-09-10, 18:26 chaos91 wrote: same cmake version here, so I'm doing a fresh checkout atm I don't think you need to do a new checkout, unfortunately you will need to compile WL from scratch again. I tested this on Debian Sid but I reckon the same will be true for testing. I got the same error when running update.sh, however after removing the content of the build directory and re-running compile.sh it built without any problems. I assume the issue is that it is looking for the old location of the boost libraries which of course has changed due to the update. There's been some similar errors in the past, and I guess the update script is not able to deal with path changes like this. (Also explains why it worked for QCS when attempting to reproduce it.) In general, if you run into a FTBFS (failed to build from source) issue, it can be useful to check whether it is reproducible with a clean compile. Of course, we'd still want to hear about it, in case others run into the same. Ships! Top Quote

QCS Joined: 2009-12-29, 21:47 Posts: 256 Tribe Member	Posted at: 2013-09-10, 18:42 We could also make compile.sh create a cleaning script which does basically remove the symlinks and everything in build/*. CMake is evil. Top Quote

chaos91 Topic Opener Joined: 2009-03-15, 21:14 Posts: 31 Pry about Widelands Location: germany	Posted at: 2013-09-10, 20:32 Well, i made a fresh checkout, and it compiled without problems. thanks for your help so, if i run in this issue again, i only need to delete the build folder and run compile.sh in order to get a clean compile? Edited: 2013-09-10, 20:33 Top Quote

1 2 next ››