> 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 it to use GCC_BUILTINS and compiles OSG and my code > > with the "-march=pentium4" option it works. > Hmm, it is designed to work around that problem. > Can you help me why it fails? > > The problem is that i386 (not x86_64) compiles with gcc have > no fixed support for these builtins. Support for them varies > dependent on -march settings. So the only way to make sure > that this is available is at osg compile time - not at osg > include time. > Therefore there is this special case asking for i386 compiles > in the decision for the use of library routines. > But once this decision is made, it is used consistently.
The problem is that since the CMAKE script CheckAtomicOps.cmake, that checks if _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS are available, fails we will never get to the line: #if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS) && defined(__i386__) So the __i386__ part will always be omitted in this case since the first part of the condition always is false in my case. > > BTW: the final outcome of that decision is the presence of > _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES which should be > defined for any gcc > i386 architecture. > Thus, OpenThreads library must in any case on i386 contain > the implementations of the methods. > > Well, looking at the source, this define is defined either > with _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS && __i386__ or with > _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED. > > So the win32 case should not happen on your machine (true?? > you do not set this define in some build, makefile, whatever??). > > That leaves us at the 1.st case. > The _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS is set in the Config > file. If you made sure that there are no 2 versions of the > Config file that are inconsistently used or you do not define > or undefine that macro at the command line/makefile/whatever, > this cannot be a problem - thing to recheck! After I run the CMAKE script I will get the following Config file: #define _OPENTHREADS_ATOMIC_USE_MUTEX If I then compile OSG and then my application I will get the previously described link errors. (I still do not understand why...) So my quick fix is to MANUALLY edit the Config file so that: #defined _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS I then compile osg with the -march pentium4 option. Then my application compiles and links just fine. > So what is left is the __i386__ define. My available versions > of gcc (ranging from 3.3 to 4.4-svn-trunk) all define that > macro when compiling for 32bit intel architectures. > Does your gcc from that ubuntu machine behave different? Can > you recheck if your gcc defines the __i386__ macro? May be by > checking some small source file and look at the preprocessed > output? Hint, make sure that you compile with -m32 to make > sure you get 32 bit builds - even when you call the preprocessor ... > > When these two preconditions are the same. then the final > outcome of _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES must be > the same and you should not see unresolved symbols. As I said. When I edit the config file manually to enable _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS and then it works. So the __386__ macro is definitivly defined. /Björn _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
