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