Am 06.01.2014 13:57, schrieb James Holsenback:
> On 01/06/2014 12:01 AM, clipka wrote:
>> Not much of a surprise for the master, but shouldn't happen with the
>> hotfix.
>>
>> So here we go for another update...
>
> still problem with hotfix ... on the other branch, git pull origin
> master shows up to date so I didn't bother trying to build from that branch

Same problem, or different one?

I guess I have to give up here, as I currently don't have access to a 
Linux system to do any meaningful experiments. Can you take over from 
here to figure out what's going wrong?

Post a reply to this message

On 01/06/2014 08:35 AM, clipka wrote:
> Am 06.01.2014 13:57, schrieb James Holsenback:
>> On 01/06/2014 12:01 AM, clipka wrote:
>>> Not much of a surprise for the master, but shouldn't happen with the
>>> hotfix.
>>>
>>> So here we go for another update...
>>
>> still problem with hotfix ... on the other branch, git pull origin
>> master shows up to date so I didn't bother trying to build from that
>> branch
>
> Same problem, or different one?
>
> I guess I have to give up here, as I currently don't have access to a
> Linux system to do any meaningful experiments. Can you take over from
> here to figure out what's going wrong?
>

OK ... kind of goes along with buildbot issues I'm trying to iron out

Post a reply to this message

Le 06/01/2014 16:32, James Holsenback nous fit lire :
> On 01/06/2014 08:35 AM, clipka wrote:
>> Am 06.01.2014 13:57, schrieb James Holsenback:
>>> On 01/06/2014 12:01 AM, clipka wrote:
>>>> Not much of a surprise for the master, but shouldn't happen with the
>>>> hotfix.
>>>>
>>>> So here we go for another update...
>>>
>>> still problem with hotfix ... on the other branch, git pull origin
>>> master shows up to date so I didn't bother trying to build from that
>>> branch
>>
>> Same problem, or different one?
>>
>> I guess I have to give up here, as I currently don't have access to a
>> Linux system to do any meaningful experiments. Can you take over from
>> here to figure out what's going wrong?
>>
> 
> OK ... kind of goes along with buildbot issues I'm trying to iron out

from hotfix (at commit 0b403907a366b56fa07ce286e03ef5258d5bba81), it's
fine if you keep adding LIBS="-lboost_system -lboot_thread", despite the
happy issue that configure does not fail anymore without it.

Without LIBS..., the error is at link-time, about missing symbols
reported by James.

Tests done on Ubuntu 13.10.
No more issue with missing mkl (whatever that be, I do not have it).

Post a reply to this message

On 01/06/2014 01:01 PM, Le_Forgeron wrote:
> Le 06/01/2014 16:32, James Holsenback nous fit lire :
>> On 01/06/2014 08:35 AM, clipka wrote:
>>> Am 06.01.2014 13:57, schrieb James Holsenback:
>>>> On 01/06/2014 12:01 AM, clipka wrote:
>>>>> Not much of a surprise for the master, but shouldn't happen with the
>>>>> hotfix.
>>>>>
>>>>> So here we go for another update...
>>>>
>>>> still problem with hotfix ... on the other branch, git pull origin
>>>> master shows up to date so I didn't bother trying to build from that
>>>> branch
>>>
>>> Same problem, or different one?
>>>
>>> I guess I have to give up here, as I currently don't have access to a
>>> Linux system to do any meaningful experiments. Can you take over from
>>> here to figure out what's going wrong?
>>>
>>
>> OK ... kind of goes along with buildbot issues I'm trying to iron out
>
> from hotfix (at commit 0b403907a366b56fa07ce286e03ef5258d5bba81), it's
> fine if you keep adding LIBS="-lboost_system -lboot_thread", despite the
> happy issue that configure does not fail anymore without it.
>
> Without LIBS..., the error is at link-time, about missing symbols
> reported by James.
>
> Tests done on Ubuntu 13.10.
> No more issue with missing mkl (whatever that be, I do not have it).
>

mkl is Math Kernel Library (Intel) It's a math speed up library ... and 
from what I've read it's somewhat problematic on unbuntu, however I did 
find a couple of recipes that claim success. I think it's specialized 
enough that if the user wants to run that it's on them ... I think what 
the build process seems to be looking for ends up getting satisfied by 
the libm test that follows the mkl test in configure.ac

from my configure output:
checking for sin in -lmkl... no
checking for sin in -lm... yes

btw: mkl recipes had to build from sources ... there appears to be /no/ 
package available via apt-get so I'm not inclined to pursue

about LIBS switches ... I /had/ LIBS="-lboost_system -lboost_thread" as 
configure additions, but noticed -lboost_system listed /twice/  at the 
end of make ... lasest revisions of povray master and hotfix built ok 
fine using just LIBS="-lboost_thread"

Post a reply to this message

Am 06.01.2014 20:21, schrieb James Holsenback:

> about LIBS switches ... I /had/ LIBS="-lboost_system -lboost_thread" as
> configure additions, but noticed -lboost_system listed /twice/  at the
> end of make ... lasest revisions of povray master and hotfix built ok
> fine using just LIBS="-lboost_thread"

Hum... we shouldn't need LIBS="-lboost_thread" on the configure command 
line, should we?

Did we always need this, or is this something new?

Post a reply to this message

On 01/06/2014 02:58 PM, clipka wrote:
> Am 06.01.2014 20:21, schrieb James Holsenback:
>
>> about LIBS switches ... I /had/ LIBS="-lboost_system -lboost_thread" as
>> configure additions, but noticed -lboost_system listed /twice/  at the
>> end of make ... lasest revisions of povray master and hotfix built ok
>> fine using just LIBS="-lboost_thread"
>
> Hum... we shouldn't need LIBS="-lboost_thread" on the configure command
> line, should we?
>
> Did we always need this, or is this something new?
>

I'd been using both entries in LIBS= and only recently discovered that 
it can trimmed down ... -lboost_thread gets rid of the make error 
mentioned in one of my earlier replies.

See also: 
http://wiki.povray.org/content/User:Le_Forgeron/vault/Compilation#Ubuntu_13.10_.26_libboost_1.53

Post a reply to this message

James Holsenback wrote:
> On 01/05/2014 07:14 PM, clipka wrote:
>> Please try again (both master and the hotfix branch).
>>
>> Please make sure to /not/ use the LIBS="-lboost_system -lboost_thread"
>> setting for the hotfix branch, as the whole point of that hotfix is to
>> make configure work reliably without it.
>>
> 
> 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
> `vfe::vfeSession::Shutdown(bool)':
> vfesession.cpp:(.text+0xcd2): undefined reference to
> `boost::thread::native_handle()'
> vfesession.cpp:(.text+0xce7): undefined reference to
> `boost::thread::join_noexcept()'
> vfesession.cpp:(.text+0xcfb): undefined reference to
> `boost::thread::detach()'
> 
> 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.

Post a reply to this message

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
>> `vfe::vfeSession::Shutdown(bool)':
>> vfesession.cpp:(.text+0xcd2): undefined reference to
>> `boost::thread::native_handle()'
>> vfesession.cpp:(.text+0xce7): undefined reference to
>> `boost::thread::join_noexcept()'
>> vfesession.cpp:(.text+0xcfb): undefined reference to
>> `boost::thread::detach()'
>> 
>> 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