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?
The alternative would be to write a generic catch-all, slow swapper, but I
would
like to figure out what's going on first.
> 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
Dirk
-------------------------------------------------------------------------
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
