Nicolas Alvarez wrote:
> James Holsenback wrote:
>> both branches (main & hotfix) pass configure (without LIBS="...") here's
>> what relevant configure output looks like:
>> checking for the pthreads library -lpthreads... no
>> checking whether pthreads work without any flags... no
>> checking whether pthreads work with -Kthread... no
>> checking whether pthreads work with -kthread... no
>> checking for the pthreads library -llthread... no
>> checking whether pthreads work with -pthread... yes
>> checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
>> checking if more special flags are required for pthreads... no
>> checking for boostlib >= 1.38... yes
>> checking whether the Boost::Thread library is available... yes
>> checking whether the boost thread library is usable... yes
>> checking for sin in -lmkl... no
>> checking for sin in -lm... yes
>> and they both have problems during make starting here (there's more):
>> ../vfe/libvfe.a(vfesession.o): In function
>> vfesession.cpp:(.text+0xcd2): undefined reference to
>> vfesession.cpp:(.text+0xce7): undefined reference to
>> vfesession.cpp:(.text+0xcfb): undefined reference to
>> when we get this sorted out, what are the chances of leaving the hotfix
>> branch for this kind of testing ... I'd like to add it to buildbot
> I'm getting the same problem, with both the 'master' and 'hotfix' branches
> of the official git repository. The build system is only passing
> -lboost_system and not -lboost_thread to the linker.
I see two problems here.
One is that the configure script is claiming that the library it found is
"usable" when it's clearly not, since it's lacking -lboost_thread. The test
program being compiled doesn't make any reference to an external symbol that
would have to be linked, so it works even without linking to boost_thread.
I changed the test program to
[[boost::defer_lock_t(); boost::this_thread::yield(); return 0;]])]
and now the error is at configure time (undefined reference to yield)
instead of when linking povray. Progress!
The second problem is why it's not finding boost_thread. I don't understand
the code in ax_boost_thread.m4, but debugging messages show that
$ax_cv_boost_thread is set to 'yes' while $BOOST_THREAD_LIB is empty.
Further investigation shows that the problem may be multiarch.
The code is searching for the boost_thread .so file in /usr/lib
(why isn't it just testing a link with -lboost_thread?), but I
have it in /usr/lib/x86_64-linux-gnu/libboost_thread.so.
Post a reply to this message