Hello everyone, as you may have noticed the unittests are broken on the development branch of xpcc. I have them running on my system again, but before I commit my stuff I would like to talk about linking the boost_thread library. First of all I stumbled over this line in xpcc.py[363]: libpath = ['/usr/lib/'] Two thing: 1.) Why is this not in hosted.py which for me was the first place to search for this. 2.) As far as I understand or at least with my system (Fedora 20) /usr/lib contains 32bit, while /usr/lib64 contains 64bit libraries. Since we want to build for the host architecture, the correct path for 64bit systems would be /usr/lib64 The second point should be easily fixed by just not setting the library path. Either /usr/lib64 or /usr/lib will be set as an environment variable depending on the system. I do not understand why we had to manually set this in the first place. The thing concerning boost_thread that kept the unittests from compiling on my system was this line in xpcc.py[362] - again this should imho be in hosted.py: libs = ['boost_thread-mt', 'boost_system'] On my system there is no libboost_thread-mt.so.x.x.x library, there is only a libboost_thread.so.x.x.x. I can not find any definit information on this, but apparently boost_thread and boost_thread-mt have been the same for quite some time: http://stackoverflow.com/questions/3031768/boost-thread-linking-boost-thread... So maybe newer distributions won't include it anymore. Would it be ok if I changed this to _boost_thread_ without the **-mt**? Kevin
Hello,
libpath = ['/usr/lib/']
Two thing: 1.) Why is this not in hosted.py which for me was the first place to search for this.
I don't think there is any reason for this being there. I would guess it stayed there from the beginning of xpcc.
2.) As far as I understand or at least with my system (Fedora 20) /usr/lib contains 32bit, while /usr/lib64 contains 64bit libraries. Since we want to build for the host architecture, the correct path for 64bit systems would be /usr/lib64
The second point should be easily fixed by just not setting the library path. Either /usr/lib64 or /usr/lib will be set as an environment variable depending on the system. I do not understand why we had to manually set this in the first place.
I don't know. Maybe it can just be deleted.
So maybe newer distributions won't include it anymore. Would it be ok if I changed this to _boost_thread_ without the **-mt**?
The problem was that not everyone had both versions. I think it is the way it is because this way it worked for most. Here (Ubuntu 12.04) I have both versions of the library. Cheers, Fabian
participants (2)
-
Fabian Greif
-
Kevin Laeufer