From: Paul O. <new...@ki...> - 2009-03-23 17:34:46
|
Hello devels, Today for a first time I tried to compile client-side program written in C++ on an x86_64 machine (using Player SVN trunk version). It couldn't be done due to pkg-config playerc++.pc file. It says one of link-time flags is -L/usr/lib, which causes proper 64-bit versions of system libraries couldn't be found since all 64-bit libraries in my multilib environment are in /usr/lib64 (while /usr/lib is for 32-bit libraries). Easy solution was to just remove -L/usr/lib flag, which causes all system libraries are found properly. I suspect (but not sure about it) boost detection cmake code caused this unnecessary flag to be added, which is still wrong, as 64-bit boost libraries are also in /usr/lib64. Paul |
From: Toby C. <tco...@pl...> - 2009-03-29 00:36:24
|
which distro is this? Ubuntu (and I guess Debian) use /lib as the 'native' libs and have lib32 and lib64 dirs with the specific archs in them... So we need a solution which is compatible with both.. Toby 2009/3/24 Paul Osmialowski <new...@ki...> > Hello devels, > Today for a first time I tried to compile client-side program written in > C++ on an x86_64 machine (using Player SVN trunk version). It couldn't be > done due to pkg-config playerc++.pc file. It says one of link-time flags > is -L/usr/lib, which causes proper 64-bit versions of system libraries > couldn't be found since all 64-bit libraries in my multilib environment > are in /usr/lib64 (while /usr/lib is for 32-bit libraries). Easy solution > was to just remove -L/usr/lib flag, which causes all system libraries are > found properly. I suspect (but not sure about it) boost detection cmake > code caused this unnecessary flag to be added, which is still wrong, as > 64-bit boost libraries are also in /usr/lib64. > > Paul > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Paul O. <new...@ki...> - 2009-03-29 09:33:59
|
This problem touches rpm-based distros: Red Hat Enterprise Linux, Scientific Linux and Fedora (at least 9 and 10), quite big part of the market... Paul On Sun, 29 Mar 2009, Toby Collett wrote: > which distro is this? > Ubuntu (and I guess Debian) use /lib as the 'native' libs and have lib32 and > lib64 dirs with the specific archs in them... > > So we need a solution which is compatible with both.. > > Toby > > 2009/3/24 Paul Osmialowski <new...@ki...> > >> Hello devels, >> Today for a first time I tried to compile client-side program written in >> C++ on an x86_64 machine (using Player SVN trunk version). It couldn't be >> done due to pkg-config playerc++.pc file. It says one of link-time flags >> is -L/usr/lib, which causes proper 64-bit versions of system libraries >> couldn't be found since all 64-bit libraries in my multilib environment >> are in /usr/lib64 (while /usr/lib is for 32-bit libraries). Easy solution >> was to just remove -L/usr/lib flag, which causes all system libraries are >> found properly. I suspect (but not sure about it) boost detection cmake >> code caused this unnecessary flag to be added, which is still wrong, as >> 64-bit boost libraries are also in /usr/lib64. >> >> Paul >> >> >> ------------------------------------------------------------------------------ >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > |
From: Toby C. <tco...@pl...> - 2009-03-29 18:10:04
|
Agree we need to fix it, just need a solution that is compatible with both, Toby 2009/3/29 Paul Osmialowski <new...@ki...> > This problem touches rpm-based distros: Red Hat Enterprise Linux, > Scientific Linux and Fedora (at least 9 and 10), quite big part of the > market... > > Paul > > On Sun, 29 Mar 2009, Toby Collett wrote: > > > which distro is this? > > Ubuntu (and I guess Debian) use /lib as the 'native' libs and have lib32 > and > > lib64 dirs with the specific archs in them... > > > > So we need a solution which is compatible with both.. > > > > Toby > > > > 2009/3/24 Paul Osmialowski <new...@ki...> > > > >> Hello devels, > >> Today for a first time I tried to compile client-side program written in > >> C++ on an x86_64 machine (using Player SVN trunk version). It couldn't > be > >> done due to pkg-config playerc++.pc file. It says one of link-time flags > >> is -L/usr/lib, which causes proper 64-bit versions of system libraries > >> couldn't be found since all 64-bit libraries in my multilib environment > >> are in /usr/lib64 (while /usr/lib is for 32-bit libraries). Easy > solution > >> was to just remove -L/usr/lib flag, which causes all system libraries > are > >> found properly. I suspect (but not sure about it) boost detection cmake > >> code caused this unnecessary flag to be added, which is still wrong, as > >> 64-bit boost libraries are also in /usr/lib64. > >> > >> Paul > >> > >> > >> > ------------------------------------------------------------------------------ > >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > >> easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > >> software that enables intelligent coding and step-through debugging. > >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > >> _______________________________________________ > >> Playerstage-developers mailing list > >> Pla...@li... > >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > > > > > > > > -- > > This email is intended for the addressee only and may contain privileged > > and/or confidential information > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: gbiggs <gb...@ki...> - 2009-03-30 00:22:12
|
The only place I can think of that that pkg-config file is getting /usr/lib as a library path from is from the Boost library path. This is itself found by a CMake module, which gets it from the basename of the library file(s). This module does not take into account differing 64- and 32-bit versions of Boost, it just finds the first one it can in the library search path. The solution is probably to set BOOST_ROOT in ccmake to /usr/lib64. This should allow CMake to find the 64-bit version of Boost first. Geoff Toby Collett wrote: > Agree we need to fix it, just need a solution that is compatible with both, > > Toby > > 2009/3/29 Paul Osmialowski <new...@ki... > <mailto:new...@ki...>> > > This problem touches rpm-based distros: Red Hat Enterprise Linux, > Scientific Linux and Fedora (at least 9 and 10), quite big part of the > market... > > Paul > > On Sun, 29 Mar 2009, Toby Collett wrote: > > > which distro is this? > > Ubuntu (and I guess Debian) use /lib as the 'native' libs and have > lib32 and > > lib64 dirs with the specific archs in them... > > > > So we need a solution which is compatible with both.. > > > > Toby > > > > 2009/3/24 Paul Osmialowski <new...@ki... > <mailto:new...@ki...>> > > > >> Hello devels, > >> Today for a first time I tried to compile client-side program > written in > >> C++ on an x86_64 machine (using Player SVN trunk version). It > couldn't be > >> done due to pkg-config playerc++.pc file. It says one of > link-time flags > >> is -L/usr/lib, which causes proper 64-bit versions of system > libraries > >> couldn't be found since all 64-bit libraries in my multilib > environment > >> are in /usr/lib64 (while /usr/lib is for 32-bit libraries). Easy > solution > >> was to just remove -L/usr/lib flag, which causes all system > libraries are > >> found properly. I suspect (but not sure about it) boost detection > cmake > >> code caused this unnecessary flag to be added, which is still > wrong, as > >> 64-bit boost libraries are also in /usr/lib64. > >> > >> Paul |
From: Paul O. <new...@ki...> - 2009-03-30 08:35:06
|
Boost (at least in rpm-based systems) does not provide any .pc file for pkg-config infrastructure, also there's no script like boost-config provided. Cmake finds boost using its own FindBoost.cmake module, wich, entirely sucks (see what it does on Solaris! however this stupid error was easy to fix). This module is too big to investigate in 5 min. what's the problem with 64-bit archs. If I find more time, I'll see what's wrong with it. Paul On Mon, 30 Mar 2009, gbiggs wrote: > The only place I can think of that that pkg-config file is getting > /usr/lib as a library path from is from the Boost library path. This is > itself found by a CMake module, which gets it from the basename of the > library file(s). This module does not take into account differing 64- > and 32-bit versions of Boost, it just finds the first one it can in the > library search path. > > The solution is probably to set BOOST_ROOT in ccmake to /usr/lib64. This > should allow CMake to find the 64-bit version of Boost first. > > Geoff > > Toby Collett wrote: >> Agree we need to fix it, just need a solution that is compatible with both, >> >> Toby >> >> 2009/3/29 Paul Osmialowski <new...@ki... >> <mailto:new...@ki...>> >> >> This problem touches rpm-based distros: Red Hat Enterprise Linux, >> Scientific Linux and Fedora (at least 9 and 10), quite big part of the >> market... >> >> Paul >> >> On Sun, 29 Mar 2009, Toby Collett wrote: >> >> > which distro is this? >> > Ubuntu (and I guess Debian) use /lib as the 'native' libs and have >> lib32 and >> > lib64 dirs with the specific archs in them... >> > >> > So we need a solution which is compatible with both.. >> > >> > Toby >> > >> > 2009/3/24 Paul Osmialowski <new...@ki... >> <mailto:new...@ki...>> >> > >> >> Hello devels, >> >> Today for a first time I tried to compile client-side program >> written in >> >> C++ on an x86_64 machine (using Player SVN trunk version). It >> couldn't be >> >> done due to pkg-config playerc++.pc file. It says one of >> link-time flags >> >> is -L/usr/lib, which causes proper 64-bit versions of system >> libraries >> >> couldn't be found since all 64-bit libraries in my multilib >> environment >> >> are in /usr/lib64 (while /usr/lib is for 32-bit libraries). Easy >> solution >> >> was to just remove -L/usr/lib flag, which causes all system >> libraries are >> >> found properly. I suspect (but not sure about it) boost detection >> cmake >> >> code caused this unnecessary flag to be added, which is still >> wrong, as >> >> 64-bit boost libraries are also in /usr/lib64. >> >> >> >> Paul > > ------------------------------------------------------------------------------ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: gbiggs <gb...@ki...> - 2009-03-31 04:47:04
|
The FindBoost.cmake module is pretty nasty, but it's far better than the CMake 2.4 version, which was useless. If only Boost provided a pkg-config file, then we wouldn't have this problem... However, the module is ultimately using CMake's FIND_LIBRARY builtin to do the search, and it's using it in a fairly standard way. As a priority, it searches first in the paths specified by _boost_LIBRARIES_SEARCH_DIRS. This includes these paths: C:/boost/lib "C:/boost" "$ENV{ProgramFiles}/boost/boost_${Boost_FIND_VERSION_MAJOR}_${Boost_FIND_VERSION_MINOR}_${Boost_FIND_VERSION_PATCH}/lib" "$ENV{ProgramFiles}/Boost" /sw/local/lib (most of which are clearly for Windows), and, if set, BOOST_ROOT and BOOST_LIBRARYDIR. After this, it searches any directories in CMAKE_LIBRARY_PATH (empty by default) just before the standard system environment variables PATH and LIB. Then it searches special CMake variables that are set depending on the platform. Since it's likely to be finding the Boost libraries from the system environment variables, this suggests that the distros you've seen this on are treating their 32-bit libraries as the native libraries, in which case finding the 32-bit version of Boost first is expected behaviour. Also, if it's finding that directory for Boost for the pkg-config file, doesn't that mean that Player is built against the 32-bit versions and that is why it's telling clients to build against them too? I'm not sure pkg-config was designed around use cases of building 64-bit apps with a pkg-config from a 32-bit program where the libraries involved differ. If you want to confirm that the -L/usr/lib in the pkg-config file is coming from Boost, compile Player without Boost support and see if it's still there. Geoff Paul Osmialowski wrote: > Boost (at least in rpm-based systems) does not provide any .pc file for > pkg-config infrastructure, also there's no script like boost-config > provided. Cmake finds boost using its own FindBoost.cmake module, wich, > entirely sucks (see what it does on Solaris! however this stupid error was > easy to fix). This module is too big to investigate in 5 min. what's the > problem with 64-bit archs. If I find more time, I'll see what's wrong with > it. > Paul > > On Mon, 30 Mar 2009, gbiggs wrote: > >> The only place I can think of that that pkg-config file is getting >> /usr/lib as a library path from is from the Boost library path. This is >> itself found by a CMake module, which gets it from the basename of the >> library file(s). This module does not take into account differing 64- >> and 32-bit versions of Boost, it just finds the first one it can in the >> library search path. >> >> The solution is probably to set BOOST_ROOT in ccmake to /usr/lib64. This >> should allow CMake to find the 64-bit version of Boost first. >> >> Geoff |
From: Paul O. <new...@ki...> - 2009-03-31 08:48:21
|
Hi Geoff, On Tue, 31 Mar 2009, gbiggs wrote: > > Also, if it's finding that directory for Boost for the pkg-config file, > doesn't that mean that Player is built against the 32-bit versions and > that is why it's telling clients to build against them too? I'm not sure > pkg-config was designed around use cases of building 64-bit apps with a > pkg-config from a 32-bit program where the libraries involved differ. > [newchief@monster bin]$ file player player: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped I doubt player in any way is built against anything 32-bit on this system. [newchief@monster ~]$ file /usr/lib/libboost_thread.so.1.33.1 /usr/lib/libboost_thread.so.1.33.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped [newchief@monster ~]$ file /usr/lib64/libboost_thread.so.1.33.1 /usr/lib64/libboost_thread.so.1.33.1: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped [newchief@monster ~]$ rpm -q boost-devel boost-devel-1.33.1-10.el5.x86_64 boost-devel-1.33.1-10.el5.i386 As you can see, RHEL x86_64 provides libraries for both 64-bit and 32-bit. This includes things like glib (both 1.2 and 2.x), gtk2 and all X libraries. GCC specs are configured to build 64-bit code by default. Also pkg-config and other *-config scripts return proper flags: [newchief@monster ~]$ pkg-config glib-2.0 --libs -L/lib64 -lglib-2.0 [newchief@monster ~]$ rpm -q glib-devel glib-devel-1.2.10-20.el5.x86_64 glib-devel-1.2.10-20.el5.i386 [newchief@monster ~]$ rpm -q glib2-devel glib2-devel-2.12.3-4.el5_3.1.x86_64 glib2-devel-2.12.3-4.el5_3.1.i386 [newchief@monster ~]$ glib-config --libs -L/usr/lib64 -lglib So I suspect FindBoost.cmake as the only source of troubles (keeping in mind all other problems I had with cmake). > > If you want to confirm that the -L/usr/lib in the pkg-config file is > coming from Boost, compile Player without Boost support and see if it's > still there. > Tomoroow, or in next 2 days. Today is my busiest day ever, so all the tests you've asked me for on a tracker, I need to suspend for next days. Sorry for that, I'm the only man in PJIIT able to do miracles - recently that keeps me busy all the time. Regarding HAVE_IEEEFP_H in pmap utility: I knew about that doing this bugfix, but for some reason this variable setting didn't go down to the utils, so I had to put this ieeefp.h check into pmap cmake specs. I'll see if this is still the case, however not today but in next two days, as stated above. Paul > Paul Osmialowski wrote: >> Boost (at least in rpm-based systems) does not provide any .pc file for >> pkg-config infrastructure, also there's no script like boost-config >> provided. Cmake finds boost using its own FindBoost.cmake module, wich, >> entirely sucks (see what it does on Solaris! however this stupid error > was >> easy to fix). This module is too big to investigate in 5 min. what's the >> problem with 64-bit archs. If I find more time, I'll see what's wrong > with >> it. >> Paul >> >> On Mon, 30 Mar 2009, gbiggs wrote: >> >>> The only place I can think of that that pkg-config file is getting >>> /usr/lib as a library path from is from the Boost library path. This is >>> itself found by a CMake module, which gets it from the basename of the >>> library file(s). This module does not take into account differing 64- >>> and 32-bit versions of Boost, it just finds the first one it can in the >>> library search path. >>> >>> The solution is probably to set BOOST_ROOT in ccmake to /usr/lib64. This >>> should allow CMake to find the 64-bit version of Boost first. >>> >>> Geoff > > > ------------------------------------------------------------------------------ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: gbiggs <gb...@ki...> - 2009-03-31 09:18:44
|
Paul Osmialowski wrote: > Hi Geoff, > > On Tue, 31 Mar 2009, gbiggs wrote: > >> Also, if it's finding that directory for Boost for the pkg-config file, >> doesn't that mean that Player is built against the 32-bit versions and >> that is why it's telling clients to build against them too? I'm not sure >> pkg-config was designed around use cases of building 64-bit apps with a >> pkg-config from a 32-bit program where the libraries involved differ. >> > [newchief@monster bin]$ file player > player: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for > GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux > 2.6.9, not stripped > I doubt player in any way is built against anything 32-bit on this system. That's pretty weird, then... it certainly can't be linking against the 32-bit version of Boost when compiling the client libraries then, as you say. Can you try making Player with VERBOSE=1 on the command line and have a look at the link line for libplayerc++? See if it has the -L/usr/bin in it as well (if it's in the pkg-config, it should be there, too). > So I suspect FindBoost.cmake as the only source of troubles (keeping in > mind all other problems I had with cmake). I agree. It's possible that CMake's FIND_LIBRARY() built-in may be hard-coded to look in /usr/lib first. I'll have to look at the CMake source to be sure. > Regarding HAVE_IEEEFP_H in pmap utility: I knew about that doing this > bugfix, but for some reason this variable setting didn't go down to the > utils, so I had to put this ieeefp.h check into pmap cmake specs. I'll see > if this is still the case, however not today but in next two days, as > stated above. That's certainly not supposed to happen. If it still is, we'll have to figure out why. Geoff |
From: Paul O. <new...@ki...> - 2009-04-02 08:02:31
|
Hi Geoff, @multilib: Here are reports you've asked for: http://vlab.pjwstk.edu.pl/~vlabdemo/geoff.zip these are: - UsePlayerC++.cmake and playerc++.pc the only two files in whole build directory to mention -L/usr/lib - report.x86_64.txt - output from VERBOSE=1 make >report.txt 2>&1 - noboost directory - the same files obtained after I've uninstalled boost-devel package, as you can see, no -L/usr/lib is mentioned anymore, so my suspections were correct. @pmap: looks like it is OK now and compiler has HAVE_IEEEFP_H set correctly while compiling pmap utility. @remote_driver: Recent changes didn't solve the problem. As I wrote once before: errno setting for blocking differs from Unix to Unix and recv() call have differ in part where errno values are listed. I've added one debugging message in remote_driver.cc code and look what I saw on Solaris: invoking player_driver_init()... success listening on 6665 Listening on ports: 6665 error : recv() failed: Error 0 warning : errno: 0, ErrNo: 0, ERRNO_EAGAIN: 11, EAGAIN: 11, EINPROGRESS: 150, EWOULDBLOCK: 11 error : error reading message header from remote device error : unable to subscribe to position2d device error : Driver failed to Setup (-1) On Solaris, recv() man page has no EAGAIN listed at all! Proposed patch is on a tracker. Again, it solved the problem. Paul On Tue, 31 Mar 2009, gbiggs wrote: > Paul Osmialowski wrote: >> Hi Geoff, >> >> On Tue, 31 Mar 2009, gbiggs wrote: >> >>> Also, if it's finding that directory for Boost for the pkg-config file, >>> doesn't that mean that Player is built against the 32-bit versions and >>> that is why it's telling clients to build against them too? I'm not sure >>> pkg-config was designed around use cases of building 64-bit apps with a >>> pkg-config from a 32-bit program where the libraries involved differ. >>> >> [newchief@monster bin]$ file player >> player: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for >> GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux >> 2.6.9, not stripped >> I doubt player in any way is built against anything 32-bit on this system. > > That's pretty weird, then... it certainly can't be linking against the > 32-bit version of Boost when compiling the client libraries then, as you > say. Can you try making Player with VERBOSE=1 on the command line and > have a look at the link line for libplayerc++? See if it has the > -L/usr/bin in it as well (if it's in the pkg-config, it should be there, > too). > >> So I suspect FindBoost.cmake as the only source of troubles (keeping in >> mind all other problems I had with cmake). > > I agree. It's possible that CMake's FIND_LIBRARY() built-in may be > hard-coded to look in /usr/lib first. I'll have to look at the CMake > source to be sure. > > >> Regarding HAVE_IEEEFP_H in pmap utility: I knew about that doing this >> bugfix, but for some reason this variable setting didn't go down to the >> utils, so I had to put this ieeefp.h check into pmap cmake specs. I'll see >> if this is still the case, however not today but in next two days, as >> stated above. > > That's certainly not supposed to happen. If it still is, we'll have to > figure out why. > > Geoff > > ------------------------------------------------------------------------------ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: gbiggs <gb...@ki...> - 2009-04-08 08:32:35
|
In the course of reworking library linkage, I noticed that my system adds -L/usr/lib64 to the playerc++ pkg-config file. This is, of course, where the 64-bit boost libraries are located under Gentoo. I think we can be pretty certain that the FindBoost module is not functioning correctly, and is returning library paths that are not necessary (i.e. system library paths). I don't know what the reason for this is. I'm not sure what the best solution to this is. We could work around it by putting in some filtering of our own, but that's a pain to maintain. It'd probably be better to fix the module, I think. Geoff Paul Osmialowski wrote: > Hi Geoff, > > @multilib: Here are reports you've asked for: > http://vlab.pjwstk.edu.pl/~vlabdemo/geoff.zip > these are: > - UsePlayerC++.cmake and playerc++.pc the only two files in whole build > directory to mention -L/usr/lib > - report.x86_64.txt - output from VERBOSE=1 make >report.txt 2>&1 > - noboost directory - the same files obtained after I've uninstalled > boost-devel package, as you can see, no -L/usr/lib is mentioned anymore, > so my suspections were correct. |
From: Paul O. <new...@ki...> - 2010-01-17 13:21:41
|
Looks like this problem is fixed now. After some longer time, I've upgraded Player from SVN trunk on my x86_64 system and now playerc++ 'Libs:' entry is generated correctly (Scientific Linux 5.2 based on RHEL 5.2): Libs: -L${libdir} -lplayerc++ -L/usr/lib64 -lboost_thread -lboost_signals -lm All my c++ client-side examples now compiled fine, no changes to playerc++.pc file were required now, this buggy -L/usr/lib flag is gone. Paul On Wed, 8 Apr 2009, gbiggs wrote: > In the course of reworking library linkage, I noticed that my system > adds -L/usr/lib64 to the playerc++ pkg-config file. This is, of course, > where the 64-bit boost libraries are located under Gentoo. I think we > can be pretty certain that the FindBoost module is not functioning > correctly, and is returning library paths that are not necessary (i.e. > system library paths). I don't know what the reason for this is. > > I'm not sure what the best solution to this is. We could work around it > by putting in some filtering of our own, but that's a pain to maintain. > It'd probably be better to fix the module, I think. > > Geoff > > > Paul Osmialowski wrote: >> Hi Geoff, >> >> @multilib: Here are reports you've asked for: >> http://vlab.pjwstk.edu.pl/~vlabdemo/geoff.zip >> these are: >> - UsePlayerC++.cmake and playerc++.pc the only two files in whole build >> directory to mention -L/usr/lib >> - report.x86_64.txt - output from VERBOSE=1 make >report.txt 2>&1 >> - noboost directory - the same files obtained after I've uninstalled >> boost-devel package, as you can see, no -L/usr/lib is mentioned anymore, >> so my suspections were correct. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Paul O. <new...@ki...> - 2009-04-08 19:18:53
|
On Wed, 8 Apr 2009, gbiggs wrote: > In the course of reworking library linkage, I noticed that my system > adds -L/usr/lib64 to the playerc++ pkg-config file. This is, of course, > where the 64-bit boost libraries are located under Gentoo. I think we > can be pretty certain that the FindBoost module is not functioning > correctly, and is returning library paths that are not necessary (i.e. > system library paths). I don't know what the reason for this is. > > I'm not sure what the best solution to this is. We could work around it > by putting in some filtering of our own, but that's a pain to maintain. > It'd probably be better to fix the module, I think. > > Geoff > > We can't help it I guess. The only thing we can do is to maintain some wiki page with all pre- and post-install workarounds for different systems, different distros, e.g. for RedHat-derived x86_64 Linux distros Player post-installation step is to remove -L/usr/lib from playerc++.pc file. Badly generated .pc files isn't Player-only problem, e.g. on Solaris 10 .pc files must be tweaked after installation of libpqxx (missing link-time flags) and opencv (also missing link-time flags). Since Player uses in different places both libraries, also this kind of hints might be added to our wiki page. Paul. > Paul Osmialowski wrote: >> Hi Geoff, >> >> @multilib: Here are reports you've asked for: >> http://vlab.pjwstk.edu.pl/~vlabdemo/geoff.zip >> these are: >> - UsePlayerC++.cmake and playerc++.pc the only two files in whole build >> directory to mention -L/usr/lib >> - report.x86_64.txt - output from VERBOSE=1 make >report.txt 2>&1 >> - noboost directory - the same files obtained after I've uninstalled >> boost-devel package, as you can see, no -L/usr/lib is mentioned anymore, >> so my suspections were correct. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Toby C. <tco...@pl...> - 2009-04-08 19:38:11
|
The autotools version of player had code to filter unwanted flags from other pkg-config files (i.e. player dependencies). This was mainly to get rid of optimisation and debug flags from the pkgconfig input so we could control these ourselves. Not sure if the equivalent code got ported to player, but if so this would be a resonable place to get rid of the system lib paths as well. Think of it as making player robust to badly behaving upstream modules, this is good programming pratcie rather than a horrible hack... Toby 2009/4/9 Paul Osmialowski <new...@ki...> > > > On Wed, 8 Apr 2009, gbiggs wrote: > > > In the course of reworking library linkage, I noticed that my system > > adds -L/usr/lib64 to the playerc++ pkg-config file. This is, of course, > > where the 64-bit boost libraries are located under Gentoo. I think we > > can be pretty certain that the FindBoost module is not functioning > > correctly, and is returning library paths that are not necessary (i.e. > > system library paths). I don't know what the reason for this is. > > > > I'm not sure what the best solution to this is. We could work around it > > by putting in some filtering of our own, but that's a pain to maintain. > > It'd probably be better to fix the module, I think. > > > > Geoff > > > > > > We can't help it I guess. The only thing we can do is to maintain some > wiki page with all pre- and post-install workarounds for different > systems, different distros, e.g. for RedHat-derived x86_64 Linux distros > Player post-installation step is to remove -L/usr/lib from playerc++.pc > file. > > Badly generated .pc files isn't Player-only problem, e.g. on Solaris 10 > .pc files must be tweaked after installation of libpqxx (missing link-time > flags) and opencv (also missing link-time flags). Since Player uses in > different places both libraries, also this kind of hints might be added to > our wiki page. > > Paul. > > > Paul Osmialowski wrote: > >> Hi Geoff, > >> > >> @multilib: Here are reports you've asked for: > >> http://vlab.pjwstk.edu.pl/~vlabdemo/geoff.zip<http://vlab.pjwstk.edu.pl/%7Evlabdemo/geoff.zip> > >> these are: > >> - UsePlayerC++.cmake and playerc++.pc the only two files in whole build > >> directory to mention -L/usr/lib > >> - report.x86_64.txt - output from VERBOSE=1 make >report.txt 2>&1 > >> - noboost directory - the same files obtained after I've uninstalled > >> boost-devel package, as you can see, no -L/usr/lib is mentioned anymore, > >> so my suspections were correct. > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > High Quality Requirements in a Collaborative Environment. > > Download a free trial of Rational Requirements Composer Now! > > http://p.sf.net/sfu/www-ibm-com > > _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |