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. BTW: the final outcome of that decision is the presence of _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES which should be fedined 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! 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. Can you help me which one of these defines are set for your osg compile/application compile? > Would it be possible to add a field to the list of compile options in CMAKE > so that you could explicitly add compiler flags? That is possible. But there is a bunch of stuff around so that this is not needed. And worse it might break that you should be able to use osg headers with any compile flags, not only those you used for compiling osg ... So, no, lets fix the problem at its root ... Greetings and thanks! Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
