Lots of Leopard information added.
This commit is contained in:
Eric WING
parent
94c57ecff5
commit
fab7c66061
@ -1,6 +1,6 @@
|
||||
{\rtf1\mac\ansicpg10000\cocoartf824\cocoasubrtf440
|
||||
{\fonttbl\f0\fswiss\fcharset77 Helvetica-Bold;\f1\fswiss\fcharset77 Helvetica;\f2\fswiss\fcharset77 Helvetica-Oblique;
|
||||
\f3\fmodern\fcharset77 Courier;\f4\fnil\fcharset77 Monaco;}
|
||||
{\rtf1\ansi\ansicpg1252\cocoartf949
|
||||
{\fonttbl\f0\fswiss\fcharset0 Helvetica;\f1\fmodern\fcharset0 Courier;\f2\fnil\fcharset0 Monaco;
|
||||
}
|
||||
{\colortbl;\red255\green255\blue255;}
|
||||
{\*\listtable{\list\listtemplateid1\listhybrid{\listlevel\levelnfc23\levelnfcn23\leveljc2\leveljcn2\levelfollow0\levelstartat1\levelspace360\levelindent0{\*\levelmarker \{disc\}}{\leveltext\leveltemplateid0\'02\'05.;}{\levelnumbers\'01;}}{\listname ;}\listid1}
|
||||
{\list\listtemplateid2\listhybrid{\listlevel\levelnfc23\levelnfcn23\leveljc2\leveljcn2\levelfollow0\levelstartat1\levelspace360\levelindent0{\*\levelmarker \{disc\}}{\leveltext\leveltemplateid0\'02\'05.;}{\levelnumbers\'01;}}{\listname ;}\listid2}
|
||||
@ -10,41 +10,165 @@
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f0\b\fs24 \cf0 OpenSceneGraph on Mac OS X
|
||||
\f1\b0 \
|
||||
\b0 \
|
||||
\
|
||||
This is the readme for the entire OpenThreads/OpenSceneGraph distribution for the OS X frameworks and Xcode projects. This readme was originally written for the binary distribution, but there is a lot of useful information in here so it has also been included with the source code in the Xcode section. This was sync'd with the OSG 2.2 release.\
|
||||
\
|
||||
The source code is available at {\field{\*\fldinst{HYPERLINK "http://www.openscenegraph.org/"}}{\fldrslt http://www.openscenegraph.org/}}\
|
||||
\
|
||||
|
||||
\f0\b \
|
||||
\b \
|
||||
Quick Start:
|
||||
\f1\b0 \
|
||||
\b0 \
|
||||
Screencasts of how to install and get going with OSG for Mac OS X can be found here:\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
{\field{\*\fldinst{HYPERLINK "http://www.openscenegraph.org/projects/osg/wiki/Support/TipsAndTricks"}}{\fldrslt \cf0 http://www.openscenegraph.org/projects/osg/wiki/Support/TipsAndTricks}}\
|
||||
\
|
||||
\
|
||||
\
|
||||
{\field{\*\fldinst{HYPERLINK "http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/MacOSXTips"}}{\fldrslt \cf0 http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/MacOSXTips}}\
|
||||
\pard\pardeftab720\ql\qnatural
|
||||
\cf0 \
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
\cf0 \
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f0\b \cf0 What's New in this release (2.2):
|
||||
\f1\b0 \
|
||||
\pard\tx220\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\li720\fi-720\ql\qnatural\pardirnatural
|
||||
\ls1\ilvl0\cf0 \
|
||||
\b \cf0 Special Notes for Leopard:\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\b0 \cf0 (See {\field{\*\fldinst{HYPERLINK "http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MacOSX10.5"}}{\fldrslt http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MacOSX10.5}} for up-to-date information.)\
|
||||
\
|
||||
|
||||
\b Broken Binary Compatibility:
|
||||
\b0 \
|
||||
Apple has broken binary compatibility in a limited way between 10.4 and 10.5 when using OpenGL and C++. Under 32-bit, the GLenum type was changed from long (in 10.4 and before) to int (in 10.5).\
|
||||
\
|
||||
Under 32-bit, sizeof(long) == sizeof(int) == 4-bytes.\
|
||||
(In 64-bit, sizeof(long) == 8-bytes, sizeof(int) == 4-bytes)\
|
||||
So in C 32-bit, binary compatibility is preserved.\
|
||||
\
|
||||
But under C++, even though both types are 4-bytes under 32-bits, C++ name mangling rules treat int and long as fundamentally different types. Thus binary compatibility is broken if you try linking two pieces of code that use different types for GLenum.\
|
||||
\
|
||||
\
|
||||
This means:\
|
||||
1) If you have a 10.4 SDK (or before) built OSG framework, you cannot build an application using the 10.5 SDK or you will get strange undefined symbol errors if GLenum is used. This means don't develop against the 10.5 SDK on Leopard.\
|
||||
\
|
||||
2) You cannot use a 10.5 SDK built OSG framework to build an application using the 10.4 SDK, otherwise this will also give you undefined symbol errors. This means don't develop with 10.5 built OSG frameworks when using the 10.4u SDK on Leopard or developing on 10.4 itself.\
|
||||
\
|
||||
3) If you have a 10.4 SDK built OSG framework and a 10.4 SDK built application that uses it, this does *not* present a binary compatibility problem and you may be able to run on 10.5 (ignoring any different compatibility issues).\
|
||||
\
|
||||
4) Similarly to #3, if you have a 10.5 SDK built framework and a 10.5 SDK built application that uses it, this does *not* present a binary compatibility problem and you may be able to run on 10.4 presuming there are no specific 10.5 dependencies. (But it is safer to build against the 10.4 SDK if you plan on deploying to 10.4 and use no 10.5 specific features.)\
|
||||
\
|
||||
Basically, this means you can't intermix 10.4 and 10.5 frameworks.\
|
||||
\
|
||||
You can slip around this problem if you manage to avoid the use of any code that uses GLenum. And pure C is not affected.\
|
||||
\
|
||||
|
||||
\b \
|
||||
OSG 10.4 and 10.5 SDKs:\
|
||||
|
||||
\b0 Xcode 3.0 introduces formal support for SDKs created by 3rd parties (like us). Since we now have binary incompatible frameworks, developing binaries for both 10.4 and 10.5 on the same system is a pain. Having a separate OSG 10.4 and 10.5 SDK may help minimize that pain.\
|
||||
\
|
||||
Stay tuned for the SDKs and instructions.\
|
||||
\
|
||||
\
|
||||
\
|
||||
|
||||
\b X11 Link problems:\
|
||||
|
||||
\b0 Another common problem developers might experience is:\
|
||||
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
|
||||
\cf0 ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib\
|
||||
collect2: ld returned 1 exit status\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
\cf0 \
|
||||
Apple has a posted a Technical Q&A (QA1567) on this entitled "Compiling X11 / OpenGL applications on Mac OS X v.10.5 Leopard"\
|
||||
{\field{\*\fldinst{HYPERLINK "http://developer.apple.com/qa/qa2007/qa1567.html"}}{\fldrslt http://developer.apple.com/qa/qa2007/qa1567.html\
|
||||
}}\
|
||||
Some people have reported a problem similar to this and/or used the solution posted in this Q&A to resolve a problem building the osgdb_freetype plugin. However, I believe this is the wrong solution to this specific problem. In the osgdb_freetype case, the problem was one of two things:\
|
||||
1) The wrong libfreetype.dylib was being used (wrong SDK)\
|
||||
2) The libfreetype.dylib was not found (wrong path)\
|
||||
\
|
||||
For #1, the Xcode project was linking to /usr/X11R6/lib, but we should have been linking to $(SDKROOT)/usr/X11R6/lib. You would normally experience this problem when compiling against the 10.4u SDK on 10.5.\
|
||||
\
|
||||
For #2, the problem was usually experienced by people building against the 10.5 SDK (on 10.5). The problem here is that Leopard has moved from XFree86.org to X.org and the path is now /usr/X11/lib instead of X11R6. Within the SDK, there is no X11R6 path, so the library was not found.\
|
||||
\
|
||||
The solution is quite simple and change the link path line to:\
|
||||
-L$(SDKROOT)/usr/X11/lib -L$(SDKROOT)/usr/X11R6/lib in the Other Linker Flags for the osgdb_freetype plugin.\
|
||||
\
|
||||
This is now fixed in the Xcode project in Subversion.\
|
||||
\
|
||||
\
|
||||
\
|
||||
|
||||
\b CMake:\
|
||||
|
||||
\b0 The CMake/OSG build system is still not quite ready for prime time. CMake has some general Leopard issues and the OS X/CMake community is trying to work through SDK support issues as the SDKs have become a more prominent part of building on OS X correctly. Framework support is still lacking in the CMake/OSG build system, though CMake CVS is gradually adding/fixing this feature to its code base. \
|
||||
\
|
||||
\
|
||||
|
||||
\b 64-bit:\
|
||||
|
||||
\b0 OSG for OS X 64-bit is not ready. There are two major obstacles:\
|
||||
1) osgViewer\
|
||||
2) osgdb_qt\
|
||||
\
|
||||
The osgViewer backend is written in Carbon and as far as I know, uses some deprecated APIs that are not available in 64-bit. I do not know if this can be easily cleaned up or not. However, I still believe the better long term solution is for a Cocoa based osgViewer backend to be written. However, nothing yet has been written for this as far as I know.\
|
||||
\
|
||||
The example, osgviewerCocoa is close to if not already 64-bit clean. However, because the example uses osgViewer::GraphicsWindowEmbedded which needlessly pulls in all the osgViewer Carbon backend dependencies, you will be unable to actually build osgviewerCocoa as 64-bit. But if you are in a hurry to get 64-bit on OS X, this might be where you want to start. Either strip away the Carbon dependencies from osgViewer, or take osgviewerCocoa and transform it into a Cocoa backend for osgViewer.\
|
||||
\
|
||||
\
|
||||
osgdb_qt is a QuickTime based plugin that handles all image handling and movie handling on OS X. However, it is based on the old QuickTime API which has been marked deprecated and will not survive the 64-bit transition. Thus this plugin needs to be replaced.\
|
||||
\
|
||||
I have already submitted a new plugin called osgdb_ImageIO to osgSubmissions which attempts to assume all the image handling duties. This plugin is based on Apple's ImageIO framework which is the new low-level entry point to deal with all image types handled by the platform. Thus this plugin should handle a lot more image formats than the old QuickTime plugin (e.g. JPEG2000, RAW, etc) and will get more as Apple adds support their system. It also adds support for C++ stream support which was missing from the QuickTime plugin. ImageIO is available on 10.4 and 10.5.\
|
||||
\
|
||||
However, the osgdb_ImageIO plugin does not handle movies unlike the old QuickTime plugin. The current plan is to introduce a second plugin (osgdb_QTKit), which is based on the new QuickTime Kit framework (10.4 and 10.5). This plugin will replace the movie handling capabilities of the old QuickTime plugin. \
|
||||
\
|
||||
Once both new plugins are in place and osgViewer is sorted out, we should be able to build a 32-bit/64-bit Universal Binary of OSG for OS X.\
|
||||
\
|
||||
Mac OS X 10.3 and earlier users and QuickTime for Windows users will still need to use the old QuickTime plugin.\
|
||||
\
|
||||
|
||||
\b Xcode Project Templates:\
|
||||
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
|
||||
|
||||
\b0 \cf0 Xcode 3.0 has moved things around. The old location was:\
|
||||
/Library/Application Support/Apple/Developer Tools/Project Templates/Application\
|
||||
\
|
||||
The new scheme is:\
|
||||
/Library/Application Support/Developer/\{3.0,Shared\}/Xcode/Project Templates/Application\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
\cf0 \
|
||||
\pard\pardeftab720\ql\qnatural
|
||||
\cf0 Specifying 3.0 will restrict them to only be available in Xcode 3.0, specifying Shared will make them available to 2.5, 3.0 and beyond.\
|
||||
\
|
||||
I believe our templates will work in both, so Shared is a good location:\
|
||||
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
|
||||
\cf0 /Library/Application Support/Developer/Shared/Xcode/Project Templates/Application\
|
||||
\
|
||||
Also note you may place it in per-user locations, e.g.\
|
||||
~/Library/Application Support/Developer/Shared/Xcode/Project Templates/Application\
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
\cf0 \
|
||||
\
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f0\b Notes for 2.0 release:\
|
||||
\b \cf0 What's New in this release (2.2):
|
||||
\b0 \
|
||||
\pard\tx220\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\li720\fi-720\ql\qnatural\pardirnatural
|
||||
\ls1\ilvl0\cf0 (Sorry, no OS X specific notes.)\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
\cf0 \
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\b \cf0 Notes for 2.0 release:\
|
||||
\pard\tx220\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\li720\fi-720\ql\qnatural\pardirnatural
|
||||
\ls2\ilvl0
|
||||
\f1\b0 \cf0 {\listtext \'a5 }OpenThreads now uses Subversion 'externals' to make it look like part of the OSG source distribution.\
|
||||
{\listtext \'a5 }Producer has been removed from the distribution. osgViewer is supposed to replace it. The Mac OS X backend is currently Carbon based.\
|
||||
{\listtext \'a5 }GDAL has been removed as it is no longer a dependency.\
|
||||
{\listtext \'a5 }osgviewerCocoa (previously osgsimpleviewerCocoa in CVS) is an example program demonstrating tight integration between OpenSceneGraph and Cocoa. It demonstrates many of the things you should consider in building a first-class OS X application that uses OSG.\
|
||||
{\listtext \'a5 }Dwarf debugging format\
|
||||
{\listtext \'a5 }osgsimpleviewerSDL\
|
||||
\b0 \cf0 {\listtext \'95 }OpenThreads now uses Subversion 'externals' to make it look like part of the OSG source distribution.\
|
||||
{\listtext \'95 }Producer has been removed from the distribution. osgViewer is supposed to replace it. The Mac OS X backend is currently Carbon based.\
|
||||
{\listtext \'95 }GDAL has been removed as it is no longer a dependency.\
|
||||
{\listtext \'95 }osgviewerCocoa (previously osgsimpleviewerCocoa in CVS) is an example program demonstrating tight integration between OpenSceneGraph and Cocoa. It demonstrates many of the things you should consider in building a first-class OS X application that uses OSG.\
|
||||
{\listtext \'95 }Dwarf debugging format\
|
||||
{\listtext \'95 }osgsimpleviewerSDL\
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
\cf0 OSG has changed its versioning number scheme. 2.0 is the stable release following 1.2.\
|
||||
@ -59,18 +183,20 @@ With Leopard on the horizon, the need to deal with 64-bit readiness and deprecat
|
||||
\
|
||||
\
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f0\b Notes for 1.2 release:\
|
||||
\b \cf0 Notes for 1.2 release:\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f1\b0 1.2 was originally intended as a bug fix release for 1.1 (going for 1.1.1), but OSG broke ABI again so the number was bumped to 1.2. There are no significant changes to the Xcode projects or significant OS X specific changes.\
|
||||
\b0 \cf0 1.2 was originally intended as a bug fix release for 1.1 (going for 1.1.1), but OSG broke ABI again so the number was bumped to 1.2. There are no significant changes to the Xcode projects or significant OS X specific changes.\
|
||||
\
|
||||
Since the 1.1 release, we have learned of serious problems (freezing of the window manager) on the (Intel) MacBook Pros using osgText. We believe the problem is with a serious driver bug for ATI in OS X 10.4.7. We believe the bug affects the ATI Radeon X1600. (You can get this string by calling glGetString(GL_RENDERER) when you have a valid OpenGL Context. The string returned to us on affected MacBook Pros is "ATI Radeon X1600 OpenGL Engine".)\
|
||||
\
|
||||
Robert Osfield says:\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\li720\ri0\ql\qnatural\pardirnatural
|
||||
|
||||
\f2\i \cf0 osgText subloads small glyphs one by one rather than the whole image, so I'd suspect it is this that is broken. There is a path way in osgText::Font for uploading the whole image at once, which original was specifically implement as a work around for an Octane driver bug, but for 1.1 I enabled this pathway to be selectable via an env var to see if OSX users could work around the OSX driver bug.
|
||||
\f1\i0 \
|
||||
\i \cf0 osgText subloads small glyphs one by one rather than the whole image, so I'd suspect it is this that is broken. There is a path way in osgText::Font for uploading the whole image at once, which original was specifically implement as a work around for an Octane driver bug, but for 1.1 I enabled this pathway to be selectable via an env var to see if OSX users could work around the OSX driver bug.
|
||||
\i0 \
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ri0\ql\qnatural\pardirnatural
|
||||
\cf0 \
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
@ -89,10 +215,10 @@ James Hopper suggests another solution that doesn't require you to launch throug
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx9360\li720\ri0\ql\qnatural\pardirnatural
|
||||
|
||||
\f2\i \cf0 you can set environement variables that work with applications by creating a file ~/.MacOSX/.environment.plist and put them in there. easiest way is to use the preference pane called RCEnvironment at\
|
||||
\i \cf0 you can set environement variables that work with applications by creating a file ~/.MacOSX/.environment.plist and put them in there. easiest way is to use the preference pane called RCEnvironment at\
|
||||
\
|
||||
{\field{\*\fldinst{HYPERLINK "http://www.rubicode.com/Software/RCEnvironment/"}}{\fldrslt http://www.rubicode.com/Software/RCEnvironment/}}
|
||||
\f1\i0 \
|
||||
\i0 \
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
\cf0 \
|
||||
\
|
||||
@ -130,14 +256,15 @@ If you are affected by this, please file a bug report at {\field{\*\fldinst{HYPE
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f2\i \cf0 (Note: We believe this has been fixed in 10.4.8)
|
||||
\f1\i0 \
|
||||
\i \cf0 (Note: We believe this has been fixed in 10.4.8)
|
||||
\i0 \
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f0\b \cf0 Notes for 1.1 release:\
|
||||
\b \cf0 Notes for 1.1 release:\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f1\b0 We are now distributing Universal Binaries. These binaries were built using Xcode 2.3 and gcc 4.0.1.\
|
||||
\b0 \cf0 We are now distributing Universal Binaries. These binaries were built using Xcode 2.3 and gcc 4.0.1.\
|
||||
The Xcode projects are also set to build as Universal Binaries for both Development and Deployment\
|
||||
targets. If you do not need this and want to save build time, you should change the architecture option\
|
||||
to your desired setting (most likely to $(NATIVE_ARCH)). It is overridden in the top-level "OpenSceneGraph" project in the Group & Files panel. Don't forget to change OpenThreads \
|
||||
@ -158,9 +285,10 @@ PlugIns, the file size shrunk from about 1GB to about 100MB.\
|
||||
We have stopped maintaining the Xcode 1.5/2.0 projects.\
|
||||
\
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f0\b Notes for 1.0 release:
|
||||
\f1\b0 \
|
||||
\b \cf0 Notes for 1.0 release:
|
||||
\b0 \
|
||||
These projects were primarily developed with gcc 4.0.1 under Tiger 10.4.3 using Xcode 2.2. Starting with gcc 4.0, Apple no longer statically links in the C++ runtime. Apple has made available the g++ 4.0 dynamic runtime for Panther under the 10.3.9 release. To run under Panther, your system must have this update (or you must recompile the binaries for your system).\
|
||||
\
|
||||
With gcc 4.0, serious bugs have been fixed from gcc 3.3 and new features are available to us so we have experimented with more aggressive optimizations. For these binaries we have enabled -O3 optimization and -mtune=G5. We have also enabled autovectorization. We also enabled -fvisibility-inlines-hidden which is expected to shrink the binary sizes, but noticed very little difference. (There may be something wrong.) We have not done the proper benchmarking with these options, so feedback is welcome.\
|
||||
@ -172,8 +300,8 @@ With Apple's announcement of the Intel transition, Xcode 2.1 was released to hel
|
||||
\
|
||||
\
|
||||
|
||||
\f0\b Acknowledgments:
|
||||
\f1\b0 \
|
||||
\b Acknowledgments:
|
||||
\b0 \
|
||||
\
|
||||
Many thanks should be given to the people that have helped make these projects possible and for their contributions to make OSG run well on OS X through the multiyear run-up to 1.0. I unfortunately don't have a comprehensive list as many contributions have been submitted directly to OpenSceneGraph, but I wanted to give mention to these specific people I've had the pleasure of working with in trying to make this corner of the universe work.\
|
||||
\
|
||||
@ -181,14 +309,14 @@ James Hopper (work on Xcode templates, GDAL frameworks)\
|
||||
David Guthrie (various patches, testing, Xcode project compiler options refinement)\
|
||||
Jeremy Bell (original comprehensive discussion on OS X frameworks, patches)\
|
||||
Stephen Travis Pope (provider of the OSG on OS X website)\
|
||||
Markus St\'9abe (web site design, documentation reviewer and formatter)\
|
||||
Markus St\'f6be (web site design, documentation reviewer and formatter)\
|
||||
(And for the curious) Eric Wing (Xcode projects and frameworks, patches, documentation)\
|
||||
\
|
||||
\
|
||||
\
|
||||
|
||||
\f0\b Installation:
|
||||
\f1\b0 \
|
||||
\b Installation:
|
||||
\b0 \
|
||||
\
|
||||
To "Install" the Frameworks, copy the Frameworks inside the \
|
||||
frameworks folder to a standard location.\
|
||||
@ -225,8 +353,8 @@ Also be aware that if using the 10.4 Universal SDK, you may have to explicitly s
|
||||
\
|
||||
\
|
||||
|
||||
\f0\b Running the examples:
|
||||
\f1\b0 \
|
||||
\b Running the examples:
|
||||
\b0 \
|
||||
\
|
||||
Now that osgViewer supports a native Window manager, we have attempted to provide double clickable .app bundles. We cheat a little to keep the download size smaller by symbolically linking the Frameworks, PlugIns, and Resources directories for each .app bundle instead of giving each its own copy. This allows the apps to find their resources when trying to run directly from the .dmg without having to copy anything to your computer. \
|
||||
\
|
||||
@ -258,14 +386,15 @@ Also remember that OSG will still respond to standard OSG environmental variable
|
||||
\
|
||||
\
|
||||
|
||||
\f0\b Prebinding Addresses:\
|
||||
\b Prebinding Addresses:\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f1\b0 \
|
||||
\b0 \cf0 \
|
||||
These are now obsolete. Prebinding is now disabled. The old addresses were:\
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f3 \cf0 OpenThreads -seg1addr 0x1FF00000\
|
||||
\f1 \cf0 OpenThreads -seg1addr 0x1FF00000\
|
||||
osg -seg1addr 0x1FF10000\
|
||||
osgUtil -seg1addr 0x20230000\
|
||||
osgDB -seg1addr 0x20380000\
|
||||
@ -278,13 +407,13 @@ osgFX -seg1addr 0x20690000\
|
||||
osgViweer -seg1addr 0x20700000\
|
||||
gdal -seg1addr 0x207d0000\
|
||||
osgTerrain -seg1addr 0x20c40000
|
||||
\f1 \
|
||||
\f0 \
|
||||
\
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f0\b \cf0 Xcode Projects:
|
||||
\f1\b0 \
|
||||
\b \cf0 Xcode Projects:
|
||||
\b0 \
|
||||
\
|
||||
The Xcode Projects are now included as part of the official OpenSceneGraph distribution.\
|
||||
\
|
||||
@ -293,20 +422,38 @@ Xcode 2.0 and below have the extension .xcode (no longer maintained)\
|
||||
\
|
||||
\
|
||||
|
||||
\f0\b Xcode Templates:\
|
||||
\b Xcode Templates:\
|
||||
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
|
||||
|
||||
\f1\b0 \cf0 \
|
||||
\b0 \cf0 \
|
||||
We have included a "New Project" template for OpenSceneGraph projects. We recommend you place the "OSG Application" folder into either:\
|
||||
\
|
||||
Xcode 2.4 and before:\
|
||||
/Library/Application Support/Apple/Developer Tools/Project Templates/Appllcation (for system-wide)
|
||||
\f0\b \
|
||||
\b \
|
||||
|
||||
\f1\b0 ~/Library/Application Support/Apple/Developer Tools/Project Templates/Appllcation (for per-user)
|
||||
\f0\b \
|
||||
\b0 ~/Library/Application Support/Apple/Developer Tools/Project Templates/Appllcation (for per-user)
|
||||
\b \
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f1\b0 \cf0 \
|
||||
\b0 \cf0 \
|
||||
Xcode 2.5/3.0:\
|
||||
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
|
||||
\cf0 System-wide:\
|
||||
/Library/Application Support/Developer/Shared/Xcode/Project Templates/Application (both 2.5 and 3.0)\
|
||||
/Library/Application Support/Developer/3.0/Xcode/Project Templates/Application (3.0 only)\
|
||||
/Library/Application Support/Developer/2.5/Xcode/Project Templates/Application (2.5 only)\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
\cf0 \
|
||||
Per-user\
|
||||
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
|
||||
\cf0 ~/Library/Application Support/Developer/Shared/Xcode/Project Templates/Application (both 2.5 and 3.0)\
|
||||
~/Library/Application Support/Developer/3.0/Xcode/Project Templates/Application (3.0 only)\
|
||||
~/Library/Application Support/Developer/2.5/Xcode/Project Templates/Application (2.5 only)\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
\cf0 \
|
||||
\
|
||||
\
|
||||
After doing this, when doing a File->New Project, you will see "OSG Application" under the Application category. Selecting this will create a simple OSG project with some sample source code already in place which currently renders 2 colored tetrahedrons.\
|
||||
\
|
||||
All the OSG related frameworks are listed already, though gdal and osgTerrain are not checked by default. To link against them, you must check their checkboxes to enable them. Feel free to uncheck or remove frameworks you don't need.\
|
||||
@ -327,8 +474,8 @@ Finally, there may still be issues with Zerolink. If you have problems seeing th
|
||||
\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f0\b \cf0 Compatibility:
|
||||
\f1\b0 \
|
||||
\b \cf0 Compatibility:
|
||||
\b0 \
|
||||
\
|
||||
The binaries are built using gcc 4.0.1 under Tiger 10.4.7. These binaries also will run under Panther 10.3.9 (which has the needed C++ runtime library). \
|
||||
\
|
||||
@ -338,38 +485,39 @@ Also keep in mind that the prebinding addresses are finicky. Changing the compil
|
||||
\
|
||||
If you are compiling under Xcode 1.5 and are using our Xcode 1.5/2.0 projects, there have been reports of problems I have been unable to reproduce. If you do encounter these problems, please try the following. \
|
||||
\pard\tx220\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\li720\fi-720\ql\qnatural\pardirnatural
|
||||
\ls3\ilvl0\cf0 {\listtext \'a5 }I have more rigorously tested the Deployment build style than the Development build style so use the Deployment build style. Make sure you are compiling using -Os or -O0 optimization. -O3 is known to have problems under gcc 3.3. \
|
||||
{\listtext \'a5 }The -mtune=G4 is has been tested more under Xcode 1.5 than -mtune=G5. \
|
||||
{\listtext \'a5 }I noticed that for some reason, Xcode has problems compiling the Carbon header with the OpenThreads framework when autovectorization and precompiled headers were enabled. You might try disabling precompiled headers if it is not already. If the problem persists, you may also need to delete the entry that enables autovectorization. In the Groups and Files panel (left side panel), open the Info inspector for the project (top item) and click on the Build tab. Scroll down to the bottom, and remove the autovectorization option. \
|
||||
\ls3\ilvl0\cf0 {\listtext \'95 }I have more rigorously tested the Deployment build style than the Development build style so use the Deployment build style. Make sure you are compiling using -Os or -O0 optimization. -O3 is known to have problems under gcc 3.3. \
|
||||
{\listtext \'95 }The -mtune=G4 is has been tested more under Xcode 1.5 than -mtune=G5. \
|
||||
{\listtext \'95 }I noticed that for some reason, Xcode has problems compiling the Carbon header with the OpenThreads framework when autovectorization and precompiled headers were enabled. You might try disabling precompiled headers if it is not already. If the problem persists, you may also need to delete the entry that enables autovectorization. In the Groups and Files panel (left side panel), open the Info inspector for the project (top item) and click on the Build tab. Scroll down to the bottom, and remove the autovectorization option. \
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
\cf0 \
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
|
||||
\f0\b Universal Binaries:
|
||||
\f1\b0 \
|
||||
\b \cf0 Universal Binaries:
|
||||
\b0 \
|
||||
\
|
||||
Be aware, when building you're own Universal Binaries and you use the 10.4 SDK, you must explicitly\
|
||||
list the search path to the frameworks in the project options. It seems that using any SDK will cause\
|
||||
the standard places like /Library/Frameworks to not be searched.\
|
||||
\
|
||||
|
||||
\f0\b Known Issues:
|
||||
\f1\b0 \
|
||||
\b Known Issues:
|
||||
\b0 \
|
||||
\
|
||||
There is one known serious bug that appears sometimes. With Xcode 2.0 and 2.1, in some cases when you build OpenThreads/OSG from scratch, when you run the examples, they will crash on load. The workaround seems to be to delete just the OpenThreads framework after everything is built. Then rebuild just the OpenThreads framework. Bug reports have been filed with Apple, but the root cause remains to be a mystery. (We have some guesses, but nothing substantial.) I have not yet seen this issue emerge with Xcode 2.2, so maybe the problem is fixed.\
|
||||
\
|
||||
The osgdb_geo plugin is not big endian safe. The Makefile system does not build it for OS X. We have added it for the Xcode projects, but you probably shouldn't use it unless you're on Intel.\
|
||||
\
|
||||
Do not use the
|
||||
\f4\fs22 -fvisibility=hidden
|
||||
\f1\fs24 flag unless you know what you're doing. In some cases, Xcode 2.2 seems to enable this by default in the project settings. You should verify your project settings and make sure this is disabled. Among other things, this flag will hide RTTI information causing dynamic_cast<> operations to fail. Since parts of OSG are dependent on RTTI, this option should remain off. The flag
|
||||
\f4\fs22 -fvisibility-inlines-hidden
|
||||
\f1\fs24 may be safe to use. (This is actually enabled in our Xcode projects. If there are problems, please let us know.)\
|
||||
\f2\fs22 -fvisibility=hidden
|
||||
\f0\fs24 flag unless you know what you're doing. In some cases, Xcode 2.2 seems to enable this by default in the project settings. You should verify your project settings and make sure this is disabled. Among other things, this flag will hide RTTI information causing dynamic_cast<> operations to fail. Since parts of OSG are dependent on RTTI, this option should remain off. The flag
|
||||
\f2\fs22 -fvisibility-inlines-hidden
|
||||
\f0\fs24 may be safe to use. (This is actually enabled in our Xcode projects. If there are problems, please let us know.)\
|
||||
\
|
||||
Finally, there may still be issues with Zerolink. In the Project Template, we defer to the default for this option and in current Xcode versions, the default is on. The OSG Xcode projects themselves have explicitly disabled Zerolink. In the worst cases, scenes will not render correctly or the application may crash. The worst thing about this is that the problems are so strange, you may not realize Zerolink is the problem. To see this for yourself (we tried in Xcode 2.2), you might try comparing the osgdelaunay example with and without Zerolink, toggling through all values of 'n'. With Zerolink certain objects do not even appear and it crashes. So you are probably should disable this to be safe. However, for the daring, Zerolink does seem to work for some projects though we do not fully understand the criteria for this. Furthermore, Apple constantly works on improving this feature so maybe one day it will all just work right.\
|
||||
\
|
||||
|
||||
\f0\b Misc:
|
||||
\f1\b0 \
|
||||
\b Misc:
|
||||
\b0 \
|
||||
\
|
||||
Included with the OSG Xcode projects are some of the little scripts I used to help put everything together. The build script might be of interest to those who wish to produce their own automated nightly builds.\
|
||||
\
|
||||
@ -385,7 +533,7 @@ On the topic of feature requests, another potentially useful thing to have is a
|
||||
\
|
||||
\
|
||||
-Eric Wing\
|
||||
ewing 2121 - at - yahoo (in the commercial domain)\
|
||||
ewing . public - at - gmail (in the commercial domain)\
|
||||
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\ql\qnatural\pardirnatural
|
||||
{\field{\*\fldinst{HYPERLINK "http://www.create.ucsb.edu/OSG/"}}{\fldrslt \cf0 http://www.create.ucsb.edu/OSG/}}\
|
||||
}
|
||||
Loading…
Reference in New Issue
Block a user