Hi folks,

can someone using boost >= 1.50 please try building from the following 
branch:

https://github.com/POV-Ray/povray/tree/hotfix/boost1.49-boost_system

The build should work /without/ explicitly specifying -lboost_system 
when running the configure script.

TIA.

Post a reply to this message

Le 04/01/2014 23:16, clipka nous fit lire :
> Hi folks,
> 
> can someone using boost >= 1.50 please try building from the following
> branch:
> 
> https://github.com/POV-Ray/povray/tree/hotfix/boost1.49-boost_system
> 
> The build should work /without/ explicitly specifying -lboost_system
> when running the configure script.
> 
> TIA.

Well, boost thread library is usable, but it seems to had a fresh
dependency on mkl library. and it was not installed, so configure failed
on that.


Any hint about the package to install to succeed with mkl ?
(on Ubuntu, at least)

Post a reply to this message

On 01/05/2014 05:33 AM, Le_Forgeron wrote:
> Le 04/01/2014 23:16, clipka nous fit lire :
>> Hi folks,
>>
>> can someone using boost >= 1.50 please try building from the following
>> branch:
>>
>> https://github.com/POV-Ray/povray/tree/hotfix/boost1.49-boost_system
>>
>> The build should work /without/ explicitly specifying -lboost_system
>> when running the configure script.
>>
>> TIA.
>
> Well, boost thread library is usable, but it seems to had a fresh
> dependency on mkl library. and it was not installed, so configure failed
> on that.

yep confirmed same problem on the buildbot server (ubuntu/boost 1.53)

>
> Any hint about the package to install to succeed with mkl ?
> (on Ubuntu, at least)
>

dunno ... but following returned:

apt-cache search mkl

mklibs - Shared library reduction script
mklibs-copy - Shared library reduction script

Post a reply to this message

On 01/05/2014 10:03 AM, James Holsenback wrote:
> On 01/05/2014 05:33 AM, Le_Forgeron wrote:
>> Le 04/01/2014 23:16, clipka nous fit lire :
>>> Hi folks,
>>>
>>> can someone using boost >= 1.50 please try building from the following
>>> branch:
>>>
>>> https://github.com/POV-Ray/povray/tree/hotfix/boost1.49-boost_system
>>>
>>> The build should work /without/ explicitly specifying -lboost_system
>>> when running the configure script.
>>>
>>> TIA.
>>
>> Well, boost thread library is usable, but it seems to had a fresh
>> dependency on mkl library. and it was not installed, so configure failed
>> on that.
>
> yep confirmed same problem on the buildbot server (ubuntu/boost 1.53)
>
>>
>> Any hint about the package to install to succeed with mkl ?
>> (on Ubuntu, at least)
>>
>
> dunno ... but following returned:
>
> apt-cache search mkl
>
> mklibs - Shared library reduction script
> mklibs-copy - Shared library reduction script


found another package:
sudo apt-get build-dep revolution-mkl
sudo apt-get install revolution-mkl

yields same results ... the previous packages found /NO/ updates

Post a reply to this message

Am 05.01.2014 16:03, schrieb James Holsenback:
> On 01/05/2014 05:33 AM, Le_Forgeron wrote:
>> Le 04/01/2014 23:16, clipka nous fit lire :
>>> Hi folks,
>>>
>>> can someone using boost >= 1.50 please try building from the following
>>> branch:
>>>
>>> https://github.com/POV-Ray/povray/tree/hotfix/boost1.49-boost_system
>>>
>>> The build should work /without/ explicitly specifying -lboost_system
>>> when running the configure script.
>>>
>>> TIA.
>>
>> Well, boost thread library is usable, but it seems to had a fresh
>> dependency on mkl library. and it was not installed, so configure failed
>> on that.
>
> yep confirmed same problem on the buildbot server (ubuntu/boost 1.53)

Did you already do any probing to identify the change responsible?

We did have some mkl-related change recently.

Post a reply to this message

On 01/05/2014 05:14 PM, clipka wrote:
> Am 05.01.2014 16:03, schrieb James Holsenback:
>> On 01/05/2014 05:33 AM, Le_Forgeron wrote:
>>> Le 04/01/2014 23:16, clipka nous fit lire :
>>>> Hi folks,
>>>>
>>>> can someone using boost >= 1.50 please try building from the following
>>>> branch:
>>>>
>>>> https://github.com/POV-Ray/povray/tree/hotfix/boost1.49-boost_system
>>>>
>>>> The build should work /without/ explicitly specifying -lboost_system
>>>> when running the configure script.
>>>>
>>>> TIA.
>>>
>>> Well, boost thread library is usable, but it seems to had a fresh
>>> dependency on mkl library. and it was not installed, so configure failed
>>> on that.
>>
>> yep confirmed same problem on the buildbot server (ubuntu/boost 1.53)
>
> Did you already do any probing to identify the change responsible?
>
> We did have some mkl-related change recently.
>

saw that ... #18 correct?
I added following to my configure run ... LIBS="-lboost_system 
-lboost_thread" --without-libmkl

which effectively by-passes the mkl requirement on the buildbot server

I don't understand adding a requirement (mkl) so the gentoo distribution 
can build only to require other platform(s) to add --without-libmkl clause

btw: make completed just fine, after configure addition

Post a reply to this message

Am 06.01.2014 00:31, schrieb James Holsenback:
> On 01/05/2014 05:14 PM, clipka wrote:
>> Am 05.01.2014 16:03, schrieb James Holsenback:
>>> On 01/05/2014 05:33 AM, Le_Forgeron wrote:

>>>> Well, boost thread library is usable, but it seems to had a fresh
>>>> dependency on mkl library. and it was not installed, so configure
>>>> failed
>>>> on that.
>>>
>>> yep confirmed same problem on the buildbot server (ubuntu/boost 1.53)
>>
>> Did you already do any probing to identify the change responsible?
>>
>> We did have some mkl-related change recently.
>>
>
> saw that ... #18 correct?
> I added following to my configure run ... LIBS="-lboost_system
> -lboost_thread" --without-libmkl
>
> which effectively by-passes the mkl requirement on the buildbot server
>
> I don't understand adding a requirement (mkl) so the gentoo distribution
> can build only to require other platform(s) to add --without-libmkl clause

I had hoped the author of #18 knew what he was doing, but apparently he 
didn't fully. I've thrown the change overboard again now, and 
implemented some different changes that I /think/ should be sufficient 
to fix the gentoo distro issue.

Learned a lesson today.


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.

Post a reply to this message

On 01/05/2014 07:14 PM, clipka wrote:
> Am 06.01.2014 00:31, schrieb James Holsenback:
>> On 01/05/2014 05:14 PM, clipka wrote:
>>> Am 05.01.2014 16:03, schrieb James Holsenback:
>>>> On 01/05/2014 05:33 AM, Le_Forgeron wrote:
>
>>>>> Well, boost thread library is usable, but it seems to had a fresh
>>>>> dependency on mkl library. and it was not installed, so configure
>>>>> failed
>>>>> on that.
>>>>
>>>> yep confirmed same problem on the buildbot server (ubuntu/boost 1.53)
>>>
>>> Did you already do any probing to identify the change responsible?
>>>
>>> We did have some mkl-related change recently.
>>>
>>
>> saw that ... #18 correct?
>> I added following to my configure run ... LIBS="-lboost_system
>> -lboost_thread" --without-libmkl
>>
>> which effectively by-passes the mkl requirement on the buildbot server
>>
>> I don't understand adding a requirement (mkl) so the gentoo distribution
>> can build only to require other platform(s) to add --without-libmkl
>> clause
>
> I had hoped the author of #18 knew what he was doing, but apparently he
> didn't fully. I've thrown the change overboard again now, and
> implemented some different changes that I /think/ should be sufficient
> to fix the gentoo distro issue.
>
> Learned a lesson today.
>
>
> 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

Post a reply to this message

Am 06.01.2014 02:41, schrieb James Holsenback:

> 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()'

Not much of a surprise for the master, but shouldn't happen with the hotfix.

So here we go for another update...

> 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 named this particular branch "hotfix/boost1.49-boost_system", which 
obviously isn't a good name if we want to use it as a general hotfixing 
branch ;-)

But I do agree that it's quite a good idea to have buildbot crunch 
through all hotfixes we might throw out, so I just renamed the branch to 
"hotfix".

Post a reply to this message

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

>> 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 named this particular branch "hotfix/boost1.49-boost_system", which
> obviously isn't a good name if we want to use it as a general hotfixing
> branch ;-)
>
> But I do agree that it's quite a good idea to have buildbot crunch
> through all hotfixes we might throw out, so I just renamed the branch to
> "hotfix".

thanks ... sounds generic enough!

Post a reply to this message

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