In the end of it, I found that my application was looking for OSG headers in two different places - both in the OSG framework (Where I wanted it to), and in an older Library folder, which had been deleted.
It seems that even though the library folder was gone, XCode was keeping some bit of detritus from it which was confusing things - I finally stumbled on it when I was attempting to step and trace down into OSG, and got an error message complaining that it couldn't find one of the header files. After removing the extra include folder path from the project's settings, everything started working as expected. It all reminds me of something a former (non-computer literate) boss said, after looking over my shoulder at some code. "It'll never work - it has too many moving parts…" Once I have some spare time, I'll put together a script and example program that starts from checking out the OSG source code, and ends by building a cocoa viewer application, so hopefully the next person along the path doesn't run into the same set of issues I did. - Ron On Nov 13, 2013, at 1:41 AM, Stephan Maximilian Huber <[email protected]> wrote: > Hi Ron, > > there might be a bug in osg, but I don’t think so, as loading files and > displaying them is a core feature, and more people would have stumbled over > it. It works perfectly on my end BTW. > > I am using currently OS X 10.9 and xcode 5 to build OpenSceneGraph. But I > have used everything since 10.4 and the various xcode-versions. > > Is there a chance that you have an old/multiple installations of > OpenSceneGraph anywhere on your computer (in one of your Lirbary folders for > example)? Or old release-builds mixed with newer debug-builds? > > > To narrow your problem down I’d start with one of the official examples like > osgviewer. If the example can open an osg-file and display it then osg works > as expected, so the problem is with your app or because of conflicting > build-settings. > > These are my CMake-settings for OpenSceneGraph: > > OSG_COMPILE_FRAMEWORKS:BOOL=ON > OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR:STRING=@executable_path/../Frameworks > OSG_CXX_LANGUAGE_STANDARD:STRING=C++11 > OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX:STRING=imageio > OSG_WINDOWING_SYSTEM:STRING=Cocoa > > I do usually out-of-source-builds, setting the build-binarys-folder to > something different than the source-folder in cMake. > > When using osg-frameworks and plugins from within my app, I make sure that I > use the same standard lib, copy the frameworks and plugins to the correct > locations of my bundle and set the following compile-flags for my app: > > Inline Methods Hidden (GCC_INLINES_ARE_PRIVATE_EXTERN) to 0 > Symbols Hidden by Default (GCC_SYMBOLS_PRIVATE_EXTERN) also to 0 > > To test osgviewer I select the target from the popup, hit "Cmd <" and add an > argument to the run-schema, basically the full path to an osgt-file for > example. Then I hit run. If the console reports that it can’t find the plugin > I’ll check the osgPlugins-folder. (This may be necessary when compiling > dylibs) > > That’s what I did this morning: > > 1. git clone https://github.com/openscenegraph/osg.git > 2. start cmake, chooses xcode, set the variables, use a different > build-folder, hit configure multiple times and then generate > 3. open xcode-file in xcode hit „Cmd-B“, wait 15 minutes > 4. Locate the osgviewer-target in the drop down, select it > 5. Hit "Cmd <„ select the „Arguments“-tab, add a new argument and drop an > osgt-file into it (or paste the full-path to a osgt-file into it) > 6. Hit „Cmd R“ > 7. Now I can see the osg-model fullscreen. > > Note, that this works only for the debug-build. If you switch over to release > make sure, that you build the INSTALL-target, as this target sets up the > dependencies-paths of the frameworks and plugins. This is mandatory to bundle > the osg-frameworks + plugins with your app. > > cheers, > > Stephan > > > Am 13.11.2013 um 04:26 schrieb Ronald Aldrich <[email protected]>: > >> Stephan, >> >> I think I've found the issue - it seems that the >> AvailableReaderWriterIterator isn't being used safely. >> >> In ReaderWriter::ReadResult Registry::read(const ReadFunctor& readFunctor) >> you'll find: >> >>> // first attempt to load the file from existing ReaderWriter's >>> AvailableReaderWriterIterator itr(_rwList, _pluginMutex); >>> for(;itr.valid();++itr) >>> { >>> ReaderWriter::ReadResult rr = readFunctor.doRead(*itr); >>> if (readFunctor.isValid(rr)) return rr; >>> else results.push_back(rr); >>> } >> >> and later on… >> >>> // now look for a plug-in to load the file. >>> std::string libraryName = >>> createLibraryNameForFile(readFunctor._filename); >>> if (loadLibrary(libraryName)!=NOT_LOADED) >>> { >>> for(;itr.valid();++itr) >>> { >>> ReaderWriter::ReadResult rr = readFunctor.doRead(*itr); >>> if (readFunctor.isValid(rr)) return rr; >>> else results.push_back(rr); >>> } >>> } >> >> >> >> The first loop runs through the iterator until itr.valid() returns false. >> >> The second loop never runs because itr.valid() immediately returns false, or >> because a compiler optimization assumed that it would return false. >> >> I suspect that when loadLibrary is called, the library is inserted into >> _rwList, which would cause itr.valid() to return true, but it appears that >> the second call (and the loop it's in) were optimized away. >> >> The following code >> >>> // now look for a plug-in to load the file. >>> std::string libraryName = >>> createLibraryNameForFile(readFunctor._filename); >>> if (loadLibrary(libraryName)!=NOT_LOADED) >>> { >>> AvailableReaderWriterIterator itr(_rwList, _pluginMutex); >>> for(;itr.valid();++itr) >>> { >>> ReaderWriter::ReadResult rr = readFunctor.doRead(*itr); >>> if (readFunctor.isValid(rr)) return rr; >>> else results.push_back(rr); >>> } >>> } >> >> appears to fix the issue. >> >> There's probably a way to tell the compiler that it can't optimize that call >> away (careful placement of a volatile keyword?) but someone more familiar >> with that aspect of C++ would have to do it. >> >> This all begs the question: How does one submit a bug report for >> openscenegraph? >> >> - Ron >> >> On Nov 12, 2013, at 1:01 PM, Ronald Aldrich <[email protected]> wrote: >> >>> Stephan, >>> >>> I've re-organized my application to match your layout as best I can. It >>> appears that I've built a debug build, rather than a release build. I >>> haven't been able to figure out how to make a release build using XCode 5 >>> (This begs the question: What version of XCode and MacOS X are you using?). >>> >>> One issue I'm running into is that I cannot step and trace anything within >>> the OSG library. I'm pretty sure that it's because the modification dates >>> between the library as built, and as copied into my application bundle are >>> different. >>> >>> As far as I can tell both the OSG framework and the plugins are loading >>> correctly - Still, reading a .OSG file doesn't work. >>> >>> I think the error messages are a bit of a red herring - I added trail of >>> bread crumbs (printf statements) so I could see what's happening. >>> >>>> FindFileInPath() : USING >>>> /Users/raldrich/Documents/fu/osgviewercocoa/DerivedData/osgviewercocoa/Build/Products/Debug/osgviewercocoa.app/Contents/PlugIns/osgdb_osgd.so >>>> Opened DynamicLibrary osgPlugins-3.2.0/osgdb_osgd.so >>>> LOADED >>>> LOADED >>>> Warning: Could not find plugin to read objects from file >>>> "/Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg". >>>> 2013-11-12 12:33:43.629 osgviewercocoa[85734:303] File: >>>> /Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg >>>> failed to load >>> >>> The log entry "Opened DynamicLibrary…" comes from >>> DynamicLibrary::DynamicLibrary(name, handle), which shouldn't be reachable >>> if the library doesn't load. >>> The first "LOADED" log entry comes from Registry::loadLibrary(filename), >>> and changes to "PREVIOUSLY_LOADED" the second time I try to load a file. >>> The second "LOADED" log entry comes from Registry::read(readfunctor) >>> >>>> // now look for a plug-in to load the file. >>>> std::string libraryName = >>>> createLibraryNameForFile(readFunctor._filename); >>>> if (loadLibrary(libraryName)!=NOT_LOADED) >>>> { >>>> printf(" LOADED\r"); >>>> for(;itr.valid();++itr) >>>> { >>>> printf(" loop, reading\r"); >>>> ReaderWriter::ReadResult rr = readFunctor.doRead(*itr); >>>> if (readFunctor.isValid(rr)) return rr; >>>> else results.push_back(rr); >>>> } >>>> } >>>> else >>>> { >>>> printf(" NOT_LOADED\r"); >>>> } >>> >>> The "Warning: Could not find plugin…" is a misnomer - The warning is >>> generated if the model couldn't be read, regardless of why. >>> >>> Here's the interesting bit though - you'll notice that I added "printf(" >>> loop, reading\r");" inside the read loop, and it's never being reached. I >>> have no idea why, except that itr.valid must be returning false. >>> >>> Any ideas? >>> >>> TIA, >>> >>> Ron Aldrich >>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
