Hi,
On Friday 10 October 2008 17:27, Björn Blissing wrote:
I have dug down on this problem during the day.
The problem is that the code that checks if ATOMIC should use GCC BUILTIN
fails.
I have traced this failure to the combination of the XEON processor and GCC
version.
But if I forces
Line 4:
U OpenThreads::Atomic::operator--() display.cpp:0
Tells that the symbol is referenced from dispay.cpp.
This is one of the offending symbols. Find out why this
display.cpp is compiled with this code non inline?
There seems to be some problem during the preprocessor step
I have dug down on this problem during the day.
The problem is that the code that checks if ATOMIC should use GCC BUILTIN fails.
I have traced this failure to the combination of the XEON processor and GCC
version.
But if I forces it to use GCC_BUILTINS and compiles OSG and my code with the
Hi Björn,
Hmm, did you change the OpenThreads config file by hand?
Looking at the code I can think of hating that effect ...
Also, can you tell, if OpenThreads.so includes that symbol?
nm -C is your friend.
Greetings
Mathias
--
Dr. Mathias Fröhlich, science + computing ag, Software
Hi Björn,
Hmm, did you change the OpenThreads config file by hand?
Looking at the code I can think of hating that effect ...
No. I did not. I let cmake generate it for me.
Also, can you tell, if OpenThreads.so includes that symbol?
nm -C is your friend.
Below is the complete output of
No. I did not. I let cmake generate it for me.
Hmm, strange.
Indeed...
Where are the Atomic operators referenced from?
I am not sure actually. My code is based on the CompositeViewer example. And
contains nothing unusual to my knowledge.
Are there any objrct files from previous builds
Hi,
On Thursday 09 October 2008 15:43, Björn Blissing wrote:
Indeed...
My problem is that I do not see from the defines in the code how this can
happen. May be I miss something ...
Where are the Atomic operators referenced from?
I am not sure actually. My code is based on the
Where are the Atomic operators referenced from?
I am not sure actually. My code is based on the
CompositeViewer example.
And contains nothing unusual to my knowledge.
So, one of the libs/objects you link must contain that
unresolved reference.
So which one?
nm can tell you which
Hi,
On Thursday 09 October 2008 10:27, Björn Blissing wrote:
No. I did not. I let cmake generate it for me.
Hmm, strange.
Where are the Atomic operators referenced from?
Are there any objrct files from previous builds of your application left, that
were built using an other OpenThreads/Config
Hi Björn,
The application that fails linking has been successfully compiled and linked
against the following computers.
Intel Core 2 Duo running Windows XP sp3, Visual Studio 2005 sp1.
Intel Pentium 4 running Ubuntu 8.04, GCC version 4.2.3-2ubuntu7
Both have OSG 2.6.0 built from source.
Can
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För
Jean-Sébastien Guay
Skickat: den 8 oktober 2008 16:20
Till: OpenSceneGraph Users
Ämne: Re: [osg-users] Problem with OpenThreads::Atomic when
buildingapplication with OSG 2.6.0 on SUSE 10.2
Hi
Hello Björn,
Just as you we put OSG under source control, although only the include files.
But the OpenThreads/Config file is NOT under source control.
Ok, just as I suspected.
I have built OSG with CMAKE out of source and if I check the
OpenThreads/Config file on each computer I can
Just as you we put OSG under source control, although only
the include files. But the OpenThreads/Config file is NOT
under source control.
Ok, just as I suspected.
I have built OSG with CMAKE out of source and if I check
the OpenThreads/Config file on each computer I can clearly
Hello Björn,
We actually build OSG out-of-source on each machine. So the OpenTreads/Config
file is generated and used on each computer.
So the problem seems to be something else...
Hmmm, yes in that case it seems to be something else. Sorry, I was under
the impression that you were not
14 matches
Mail list logo
