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@... 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@... ~]$ 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@... ~]$ 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@... ~]$ rpm -q boost-devel
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@... ~]$ pkg-config glib-2.0 --libs
[newchief@... ~]$ rpm -q glib-devel
[newchief@... ~]$ rpm -q glib2-devel
[newchief@... ~]$ glib-config --libs
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
> 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
>> 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
>> 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.
> Playerstage-developers mailing list