Hi, On Tuesday 14 October 2008 09:44, Björn Blissing wrote: > 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. Which is correct in this case! No atomic ops available means: Please use a mutex ... Mutexes are done inline so far ... So if you use mutexes, the references to the atomic methods should not show up since _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES is not defined for that case.
> After I run the CMAKE script I will get the following Config file: > #define _OPENTHREADS_ATOMIC_USE_MUTEX Shure, no atomic ops available if you do not specify at least -march=i486 to the compiler flags of your build. If you add the cflags later you will just stick with that pessimistic configure time decision. But it should still work! > If I then compile OSG and then my application I will get the previously > described link errors. (I still do not understand why...) You build all your object files from scratch in this case? I still belive that you have old objects around then ... > So my quick fix is to MANUALLY edit the Config file so that: > #defined _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS Ok, if you are sure that *everything* that depends on that change is recompiled, this is doable... > I then compile osg with the -march pentium4 option. > Then my application compiles and links just fine. ... if you make sure that every later compile at least includes a march=i486 in the compilers command line. But anyway, the final decision if the methods are in the library or if they are inline is made consistently based on the _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES define. > 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. Ok, the i386 part is the same. Then the _OPENTHREADS_ATOMIC_USE_LIBRARY_ROUTINES decision is purely based on the OpenThreads/Config file. That means there must be objects compiled with two different settings of the _OPENTHREADS_USE_* defines either by building from two different OpenThreads/Config files or by two different set of compiler flags added more or less manually or any combination of these. Please track down why these are different for one object than for the other ... May be you: * use the CMAKE_VERBOSE_MAKEFILE variable set to TRUE to see the actual compiler command line. Is there any of the defines you can usually see in the config file? * use g++ -E to examine the preprocessed files? The implementations of these methods must be available in the headers in the mutex case and must be gone from the headers in the builtins case. Is there any unexpected behaviour? Greetings and hope to nail that down ... 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
