Re: [Playerstage-developers] Player SVN trunk: Problem with playerc++ on multilib Linux/x86_64

[gbiggs <gb...@ki...>]

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