 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
