Building boost against uClibc on arm machine
Hello all. I'm trying to cross-compile boost for arm machine running linux with uClibc. Most of the libs are built ok, but some of them (including one of the most important to me: thread) failed. One of the mesgs was: -------------------------------- gcc.compile.c++ bin.v2/libs/thread/build/gcc-4.3.2/debug/threading-multi/pthread/thread.o libs/thread/src/pthread/thread.cpp: In static member function 'static unsigned int boost::thread::hardware_concurrency()': libs/thread/src/pthread/thread.cpp:394: error: 'get_nprocs' was not declared in this scope -------------------------------- and somehow I'm afraid this is related to uClibc... some facts: Boost 1.39.0 G++ 4.3.2 (cross sysrooted compiler) Any help what I can take a look on? cheers -- Piotr "utak3r" Borys http://utak3r.pl
Piotr Borys wrote:
Hello all.
I'm trying to cross-compile boost for arm machine running linux with uClibc. Most of the libs are built ok, but some of them (including one of the most important to me: thread) failed.
One of the mesgs was:
-------------------------------- gcc.compile.c++ bin.v2/libs/thread/build/gcc-4.3.2/debug/threading-multi/pthread/thread.o libs/thread/src/pthread/thread.cpp: In static member function 'static unsigned int boost::thread::hardware_concurrency()': libs/thread/src/pthread/thread.cpp:394: error: 'get_nprocs' was not declared in this scope --------------------------------
and somehow I'm afraid this is related to uClibc...
I think so. get_nprocs is a gnu extension to C runtime. Since it's fairly obvious oversight, I've checked in the below patch -- can you see if that helps? - Volodya
2009/6/27 Vladimir Prus <vladimir@codesourcery.com>
-------------------------------- gcc.compile.c++ bin.v2/libs/thread/build/gcc-4.3.2/debug/threading-multi/pthread/thread.o libs/thread/src/pthread/thread.cpp: In static member function 'static unsigned int boost::thread::hardware_concurrency()': libs/thread/src/pthread/thread.cpp:394: error: 'get_nprocs' was not declared in this scope --------------------------------
and somehow I'm afraid this is related to uClibc...
I think so. get_nprocs is a gnu extension to C runtime. Since it's fairly obvious oversight, I've checked in the below patch -- can you see if that helps?
libboost-thread is built! :) There're many other places though, where it was complaining about that. Now I have to test if both system and thread libs are working ok - and my test is boost::asio ;) will report.... thanks a lot and cheers! -- Piotr "utak3r" Borys http://utak3r.pl
Piotr Borys wrote:
I'm trying to cross-compile boost for arm machine running linux with uClibc. Most of the libs are built ok, but some of them (including one of the most important to me: thread) failed.
Interesting. I have an ARM Linux system that started out running uClibc but my colleague who was working on it was unable to get it to use the NPTL threads implementation; my understanding was that this was new and/or only available by applying a patch. I think that running using the older threads implementation, LinuxThreads, was possible with uClibc but less efficient and less functional. In the end we changed to glibc despite its larger size. Since then I have heard about "embedded glibc" which might give a better balance between functionality and size.
One of the mesgs was:
-------------------------------- gcc.compile.c++ bin.v2/libs/thread/build/gcc-4.3.2/debug/threading-multi/pthread/thread.o libs/thread/src/pthread/thread.cpp: In static member function 'static unsigned int boost::thread::hardware_concurrency()': libs/thread/src/pthread/thread.cpp:394: error: 'get_nprocs' was not declared in this scope --------------------------------
I think get_nprocs() is a glibc-ism; the POSIX portable equivalent (which I guess Boost::Thread should be using) is sysconf(_SC_NPROCESSORS_ONLN); maybe this will work on uClibc. Regards, Phil.
Phil Endecott wrote:
Piotr Borys wrote:
I'm trying to cross-compile boost for arm machine running linux with uClibc. Most of the libs are built ok, but some of them (including one of the most important to me: thread) failed.
Interesting. I have an ARM Linux system that started out running uClibc but my colleague who was working on it was unable to get it to use the NPTL threads implementation; my understanding was that this was new and/or only available by applying a patch. I think that running using the older threads implementation, LinuxThreads, was possible with uClibc but less efficient and less functional. In the end we changed to glibc despite its larger size. Since then I have heard about "embedded glibc" which might give a better balance between functionality and size.
One of the mesgs was:
-------------------------------- gcc.compile.c++ bin.v2/libs/thread/build/gcc-4.3.2/debug/threading-multi/pthread/thread.o libs/thread/src/pthread/thread.cpp: In static member function 'static unsigned int boost::thread::hardware_concurrency()': libs/thread/src/pthread/thread.cpp:394: error: 'get_nprocs' was not declared in this scope --------------------------------
I think get_nprocs() is a glibc-ism; the POSIX portable equivalent (which I guess Boost::Thread should be using) is sysconf(_SC_NPROCESSORS_ONLN); maybe this will work on uClibc.
This is what fall-back code does, in fact. Whether it works on uClibc, I do not know - Volodya
participants (3)
-
Phil Endecott -
Piotr Borys -
Vladimir Prus