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