I gave up on static linking of OSG - while it worked for the main libraries, it
didn't help with loading plugins.
So, I poked around in dyld a bit.
OSG wants to find its plugins in:
.../OSG_Viewer.app/Contents/PlugIns/osgplugins-3.2.0/
Using OTool to inspect an OSG framework resulted in:
otool -L
/Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/Frameworks/osg.framework/osg
/Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/Frameworks/osg.framework/osg:
@executable_path/../Frameworks/osg.framework/Versions/100/osg
(compatibility version 100.0.0, current version 3.2.0)
@executable_path/../Frameworks/OpenThreads.framework/Versions/13/OpenThreads
(compatibility version 13.0.0, current version 3.2.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 56.0.0)
Using OTool to inspect a plugin resulted in:
otool -L
/Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/PlugIns/osgPlugins-3.2.0/osgdb_3dcd.so
/Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/PlugIns/osgPlugins-3.2.0/osgdb_3dcd.so:
@executable_path/../Frameworks/OpenThreads.framework/Versions/13/OpenThreads
(compatibility version 13.0.0, current version 3.2.0)
@executable_path/../Frameworks/osg.framework/Versions/100/osg
(compatibility version 100.0.0, current version 3.2.0)
@executable_path/../Frameworks/osgDB.framework/Versions/100/osgDB
(compatibility version 100.0.0, current version 3.2.0)
@executable_path/../Frameworks/osgUtil.framework/Versions/100/osgUtil
(compatibility version 100.0.0, current version 3.2.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 169.3.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 155.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.5)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 56.0.0)
And the application is laid out as:
OSG_Viewer.app
Contents
Frameworks
{OpenSceneGraph Frameworks}
MacOS
OSG_Viewer
Plugins
osgPlugins-3.2.0
{OpenSceneGraph Plugins}
Resources
{Application resources}
The documentation for dyld indicates that @executable_path "is replaced with
the path to the directory containing the main executable for the process.",
which should be .../OSG_Viewer.app/Contents/MacOS, so to my eye, the linkages
reported by OTool appear to be correct, but either the library doesn't load, or
doesn't work when it is loaded.
If anyone has a suggestion on how to resolve this, I'd greatly appreciate it.
- Ron
On Nov 11, 2013, at 6:16 PM, Ronald Aldrich <[email protected]> wrote:
> I tried setting OSG_BUILD_APPLICATION_BUNDLES, but couldn't see that it was
> doing anything. At any rate, I find that XCode is better behaved (and
> faster) when it is allowed to use its own build environment (It'll compile
> multiple sources at once, where make is a one-at-a-time process).
>
> I've gotten my variant of osgViewerCocoa to compile, link, run, and display
> the "Drag and drop here" message. The latest issue comes when I try to drag
> an OSG document onto it (cessna.osg).
>
>> 2013-11-11 14:56:03.444 OSG_Viewer[53523:303] -[ViewerCocoa draggingEntered:]
>> 2013-11-11 14:56:04.048 OSG_Viewer[53523:303] -[ViewerCocoa
>> prepareForDragOperation:]
>> 2013-11-11 14:56:04.049 OSG_Viewer[53523:303] -[ViewerCocoa
>> performDragOperation:]
>> osg::Node *osgDB::readNodeFile(const std::string &, const osgDB::Options
>> *)(/Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg)
>> Registry::LoadStatus osgDB::Registry::loadLibrary(const std::string
>> &)(osgPlugins-3.2.0/osgdb_osgd.so)
>> attempting to load
>> osgPlugins-3.2.0/osgdb_osgd.soitr='/Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug'
>> FindFileInPath() : trying
>> /Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/osgPlugins-3.2.0/osgdb_osgd.so
>> ...
>> itr='/usr/local/lib/osgPlugins-3.2.0'
>> FindFileInPath() : trying
>> /usr/local/lib/osgPlugins-3.2.0/osgPlugins-3.2.0/osgdb_osgd.so ...
>> itr='/Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/PlugIns'
>> FindFileInPath() : trying
>> /Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/PlugIns/osgplugins-3.2.0/osgdb_osgd.so
>> ...
>> FindFileInPath() : USING
>> /Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/PlugIns/osgplugins-3.2.0/osgdb_osgd.so
>> Opened DynamicLibrary osgPlugins-3.2.0/osgdb_osgd.so
>> Warning: Could not find plugin to read objects from file
>> "/Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg".
>> 2013-11-11 14:56:04.077 OSG_Viewer[53523:303] File:
>> /Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg
>> failed to load
>
> As you can see from above, it appears to be finding the osgdb_osgd.so library
> where I expect it to, and claims to have opened it, but then claims that it
> couldn't find the plugin, and errors out.
>
> I thought I would try building OSG and its plugins as static libraries, which
> IMO is more bulletproof from an end user standpoint (No way to induce
> dll-hell), but that runs into a different, but related issue:
>
>> 2013-11-11 18:09:01.250 OSG_Viewer[62759:303] -[ViewerCocoa
>> performDragOperation:]
>> osg::Node *osgDB::readNodeFile(const std::string &, const osgDB::Options
>> *)(/Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg)
>> Registry::LoadStatus osgDB::Registry::loadLibrary(const std::string
>> &)(osgPlugins-3.2.0/osgdb_osgd.so)
>> attempting to load
>> osgPlugins-3.2.0/osgdb_osgd.soitr='/Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug'
>> FindFileInPath() : trying
>> /Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/osgPlugins-3.2.0/osgdb_osgd.so
>> ...
>> itr='/usr/local/lib/osgPlugins-3.2.0'
>> FindFileInPath() : trying
>> /usr/local/lib/osgPlugins-3.2.0/osgPlugins-3.2.0/osgdb_osgd.so ...
>> itr='/Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/PlugIns'
>> FindFileInPath() : trying
>> /Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/PlugIns/osgPlugins-3.2.0/osgdb_osgd.so
>> ...
>> itr='/Users/raldrich/Library/Application Support/OpenSceneGraph/PlugIns'
>> FindFileInPath() : trying /Users/raldrich/Library/Application
>> Support/OpenSceneGraph/PlugIns/osgPlugins-3.2.0/osgdb_osgd.so ...
>> itr='/Library/Application Support/OpenSceneGraph/PlugIns'
>> FindFileInPath() : trying /Library/Application
>> Support/OpenSceneGraph/PlugIns/osgPlugins-3.2.0/osgdb_osgd.so ...
>> itr='/Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug'
>> FindFileInPath() : trying
>> /Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/osgdb_osgd.so
>> ...
>> itr='/usr/local/lib/osgPlugins-3.2.0'
>> FindFileInPath() : trying /usr/local/lib/osgPlugins-3.2.0/osgdb_osgd.so ...
>> FindFileInPath() : USING /usr/local/lib/osgPlugins-3.2.0/osgdb_osgd.so
>> Opened DynamicLibrary osgPlugins-3.2.0/osgdb_osgd.so
>> Warning: Could not find plugin to read objects from file
>> "/Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg".
>> 2013-11-11 18:09:01.499 OSG_Viewer[62759:303] File:
>> /Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg
>> failed to load
>
>
> Even though all of the OSG plugins are statically linked to my application,
> OSG is still trying to load them dynamically.
>
>> Hand-maintaining the xcode-project files were error-prone and a mess. Cmake
>> is not perfect but when setup correctly delivers xcode-project-files which
>> work for iOS and OS X.
>
> Perhaps a script that sets Cmake up correctly for different platforms would
> be in order?
>
> Really, my biggest issue is that documentation is lacking with regard to OS
> X. When you find a page on openscenegraph.org that references it, either the
> links point to missing files, or there's simply nothing there. What I was
> able to find usually talks about XCode in pre-Cmake terms, or describes all
> of the things that CMake doesn't handle yet, like building applications
> (Maybe it does now, but I can't find anything official that says so).
>
>
> http://trac.openscenegraph.org/projects/osg//wiki/Support/Tutorials/MacOSXTips
>
> http://www.openscenegraph.org/index.php/documentation/platform-specifics/mac-osx
>
> On Nov 10, 2013, at 11:36 PM, Stephan Maximilian Huber
> <[email protected]> wrote:
>
>> HI,
>>
>> have you tried the cmake-setting OSG_BUILD_APPLICATION_BUNDLES? Haven’t
>> tried this, as for me all example apps run from within xcode when compiling
>> for debug and setting the osgPlugins-folder correctly.
>>
>> OS X is a hard to track development platform as it changes a lot over the
>> years. Basically every year you’ll get a new version of xcode, new APIs, new
>> blablabla. The os x offers so many options in regard of development: do you
>> want to use frameworks, or dylibs, do you want to bundle it with your app or
>> just install it to the usual locations? 32bit, 64bit? Two years ago there
>> was even Carbon around the corner. And now IOS-development. Hand-maintaining
>> the xcode-project files were error-prone and a mess. Cmake is not perfect
>> but when setup correctly delivers xcode-project-files which work for iOS and
>> OS X.
>>
>> There are different ways to integrate osg with an existing os-x app. One
>> approach is using an GraphicsWindowEmbedded and do the context-setup by
>> yourself.
>>
>> Another approach is to setup a osgViewer::GraphicsWindowCocoa::WindowData
>> and feed it into osg::GraphicsContext::Traits-object and create an
>> osg::GraphicsContext manually. After the viewer is realized you can get back
>> the created view via osgViewer::GraphicsWindowCocoa::WindowData::
>> getCreatedNSView or [osgVIewer:: GraphicsWindowCocoa::getContext() view]
>>
>> I haven’t tried the osgViewerCocoa-example in years and can’t speak for it.
>>
>> cheers,
>>
>> Stephan
>>
>>
>> Am 11.11.2013 um 01:31 schrieb Ronald Aldrich <[email protected]>:
>>
>>> Thanks, Robert - I'll check that out.
>>>
>>> I'm wondering if there's a simple example application for cocoa, which
>>> actually compiles and runs. So far, I've gotten osgviewercocoa to compile
>>> and link, but it doesn't run because it's not being packaged as an
>>> application.
>>>
>>> I've gotten my own program to display an OSG window, with a lovely blue
>>> background, but adding scene data to it doesn't seem to do anything, so I
>>> find myself looking for a better starting point.
>>>
>>> It all feels like OSG has taken a huge step backward from where it was
>>> several years ago when I first experimented with it, at least with regard
>>> to Mac. Back when, there were xcode project files which allowed you to
>>> build a complete sample application and run it - now, you get tossed into a
>>> morass of CMake settings, and spend a lot of time exploring dead ends and
>>> configuration mistakes before you get anything at all to work.
>>>
>>> - Ron
>>>
>>> On Nov 10, 2013, at 1:39 AM, Robert Osfield <[email protected]>
>>> wrote:
>>>
>>>> Hi Ron,
>>>>
>>>> Apple keep moving the goal posts on their platform so it's a case of keep
>>>> trying to catch up with whatever the new flavour of the month is. In OSG
>>>> svn/trunk I have checked in a submissions that allows one toggle which
>>>> libs to link against, look out for the OSG_CXX_LANGUAGE_STANDARD option,
>>>> set it to either C++98 or C++11.
>>>>
>>>> Robert.
>>>>
>>>>
>>>> On 9 November 2013 19:25, Ronald Aldrich <[email protected]> wrote:
>>>> It appears that the issue is that OpenSceneGraph is linked against
>>>> libstdc++, while my application was being linked against libc++.
>>>>
>>>> According to the documentation for libc++ ( http://libcxx.llvm.org ), the
>>>> two are not ABI compatible, and with the amount of inline code used in
>>>> OpenSceneGraph, it's not surprising that the two don't co-exist.
>>>>
>>>> Linking my application against libstdc++ stopped it from crashing, which
>>>> should solve the issue for now, but I'd really like to be using libc++
>>>> instead, because it brings C++11 compatibility as well as performance
>>>> improvements.
>>>>
>>>> So, what would it take to configure OpenSceneGraph's build environment to
>>>> link against libc++, rather than libstdc++?
>>>>
>>>> - Ron
>>>>
>>>> On Nov 8, 2013, at 10:37 PM, Ronald Aldrich <[email protected]> wrote:
>>>>
>>>>> Hello All,
>>>>>
>>>>> I'm new to OpenSceneGraph, so please bear with me.
>>>>>
>>>>> I'm attempting to write a Mac OS X native (cocoa) application that uses
>>>>> OpenSceneGraph, and I'm having some difficulty.
>>>>>
>>>>> I created an XCode project to build OpenSceneGraph as a set of frameworks
>>>>> (Using CMake), and I think I was mostly successful at that.
>>>>>
>>>>> Now, I'm trying to use those frameworks within my own application, and
>>>>> having some difficulty.
>>>>>
>>>>> I've created a class (OSGView) along the lines of the OSGViewerCocoa
>>>>> OSGViewer class - simplified, and modified for ARC. That class doesn't
>>>>> populate the scene data, and when the application runs, a view filled
>>>>> with blue is displayed - so good, so far.
>>>>>
>>>>> Next, I tried to create a triangle mesh to populate the scene data with,
>>>>> and that's where my problem occurs - when one of the array objects I
>>>>> created is deleted, the application crashes.
>>>>>
>>>>> I can simplify the problem down to the following:
>>>>>
>>>>> - (void) test
>>>>> {
>>>>> osg::ref_ptr<osg::Vec3Array> theVertices = new osg::Vec3Array(0);
>>>>> }
>>>>>
>>>>> When the Vec3Array is deleted, it crashes at the end of
>>>>> Object::~Object(), with the code
>>>>>
>>>>> Thread 1: EXC_BAD_ACCESS (code=1, address= 0xfffffffffffffff8)
>>>>>
>>>>> I then thought I'd go back to basics, and build the OSGViewerCocoa
>>>>> example, to see how it works, but when I build it, all I get is a unix
>>>>> executable (OSGViewerCocoad), which doesn't run because it isn't
>>>>> assembled as a complete Mac application.
>>>>>
>>>>> I suspect that the problem I'm having is caused by a mix of build
>>>>> environments - CMake for OpenSceneGraph, and XCode (LLVM) for my
>>>>> application, but I've got no idea how to resolve that since CMake doesn't
>>>>> appear to be able to create complete applications.
>>>>>
>>>>> So, does anyone have a suggestion?
>>>>>
>>>>> 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
>>
>> _______________________________________________
>> 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
