Hi Ronald,
Am 12.11.2013 um 08:52 schrieb Ronald Aldrich <[email protected]>:
> I gave up on static linking of OSG - while it worked for the main libraries,
> it didn't help with loading plugins.
static linking needs some manual work on your code side. See the
osgstaticviewer-example. Basically the linker strips all plugins out of the
product when not taking some precautions.
I am using a similar bundle-layout as yours, I usually don’t use the
osgPlugins-3.x-folder at all. All plugins are sitting in Plugins/
This is working w/o problems.
cheers,
Stephan
> 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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
