Dirk Reiners wrote: > Hi Patrick, > > Patrick Hartling wrote: >> I was able to build the latest OpenSG sources from the Subversion repository >> on Mac OS X (10.4) today, but I ran into a few problems. First, a linker >> error about an unresolved symbol occurs when building libOSGSystem.dylib. No >> specializations for the function osgSwapBytes<T>() exist for the unsigned >> long and long cases because OSG::UInt32 maps to unsigned int (and OSG::Int32 >> to int). Somewhere in the code, however, the compiler must be interpreting a >> constant as an unsigned long instead of an unsigned int and/or unsigned long >> is being used instead of OSG::UInt32. The first attachment (link.patch) >> fixes the linking problem, but I would not call it a very good patch. It's >> really just a hack, but it seems to me that fixing things without cluttering >> up OSGBaseFunctions.inl would mean tracking down the places in the code >> where the unsigned longs are coming into the picture and forcing them to be >> OSG::Uint32. Even then, this same problem could crop up later since the >> types themselves both represent four-byte values. The name mangling is where >> things go awry. > > Hm, I'm not sure why that's really a problem, as we have cases for 8, 16, 32 > and > 64 bit ints. Or is int64_t and uint64_t different from long and unsigned long > on > your system?
On my PowerPC and Intel Macs, long and unsigned long are 32-bit types, and int32_t is int and uint32_t is unsigned int. As such, they are *almost* interchangeable. What this really boils down to is a subtle difference in the name mangling: __ZN3OSG12osgSwapBytesImEET_S1_ __ZN3OSG12osgSwapBytesIjEET_S1_ The first is unsigned long OSG::osgSwapBytes<unsigned long>(unsigned long); the second is unsigned int OSG::osgSwapBytes<unsigned int>(unsigned int). When trying to link libOSGSystem.dylib, __ZN3OSG12osgSwapBytesImEET_S1_ ends up being an unresolved symbol, whereas there are no problems with __ZN3OSG12osgSwapBytesIjEET_S1_. > The alternative would be to write a generic catch-all, slow swapper, but I > would > like to figure out what's going on first. I agree. >> As far as the build itself goes, it does not behave in what I would call an >> intuitive manner with respect to the var_arch and darwin_universal >> arguments. It seems to me that if I set var_arch to a specific architecture, >> then only that architecture should be built regardless of what the state of >> the universal binary flag is. Looking at SConsAddons, I cannot follow the >> flow of the code, so I do not understand how the decision is made about >> which "-arch <arch>" options get added to the compiler and linker argument >> lists under what circumstances. Given this, I had to build with var_arch set >> to ia32 (for an Intel Mac) and darwin_universal set to no. >> >> Beyond that, the OpenGL and GLUT frameworks on my machines do not include a >> ppc64 binary. Since the universal build appears to include "-arch ppc64" no >> matter what, linking the OpenSG libraries as universal binaries fails. >> Having a way to limit the binaries built when making a universal binary >> would be a big help, and maybe this is already possible with the current >> state of SConsAddons. > > No clue on that one. > >> Finally, running the test programs fails due to two problems. The first is >> that DYLD_LIBRARY_PATH isn't being handled. Second, the call to os.spawnle() >> isn't passing in the program name as is required. I don't know why this >> isn't a problem on other platforms, but maybe Python 2.3 is less forgiving >> about misusing os.spawn[lv]*(). The second attachment (build.patch) fixes >> these problems. > > I committed that. Thanks. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
