Eric,

> Okay, this is starting to worry me. This is all supposed to work out
> of the box.

It didn't work out of the box for me, and I don't know why.  
Then again my OS X skills are greatly lacking.  
I didn't know about frameworks until last week.

> I forgot why this one works. Officially we tell people to use:
> /Library/Frameworks/Application Support/OpenSceneGraph/PlugIns (or ~/...)
> We put in some redundancy early on which I think why
> /Library/Frameworks/PlugIns works, but these paths are not the ones we
> advertise.

I have tried the location in many places, and none of them worked.  
I will try putting it where you suggest, and see what happens.

> You shouldn't have to set (DY)LD_LIBRARY_PATH or any other
> environmental variables (sans one for the Intel/ATI bug). The whole
> motivation for our FileUtils.cpp patch was so we could leave
> environmental variables behind.

The only way I have been able to get this working was by setting
the DYLD_LIBRARY_PATH.  Nothing else would find the plugins.

> So are you saying the prebuilt binaries work for you, but when you
> compile yourself, it does not? Compiling it yourself shouldn't really
> matter. Are you using the Xcode projects or Makefiles? This shouldn't
> really matter either for plugins. The difference is the latter builds
> .dylibs instead of frameworks, but this doesn't affect plugin loading
> which is controlled by osgDB. (Just don't mixup the two plugins,
> because they link to different libraries (dylibs or frameworks)).

Nothing works unless I set the DYLD_LIBRARY_PATH.  I have tried the
makefiles and the Xcode.  The Xcode stuff built fine but when I tried
to link against the framework, I got an error saying osg::StateSet::SetMode(unsigned int, unsigned int)
is undefined, and the compile would stop.  Using the makefiles,
everything would compile, but the plugins couldn't be found without
the DYLD_LIBRARY_PATH.  The program will run, but the moment I try
to load a file it is unable to find the plugins and exits.

> Are you using the standard Apple gcc toolset? The code base relies on
> __APPLE__ being defined by the compiler. If this is not being defined
> by your compiler, then building OSG is going to miss out on pretty
> much all the Apple specific code paths.

I am using the standard Apple gcc stuff.  __APPLE__ is defined.

As I said I am a novice on OS X.  I am a LINUX person who is forced to
use windows sometimes.  My first time on a Mac was a week ago Monday.
I got things working but it took me a week.  Maybe the OS is setup
strangely on the two systems I worked on.

Thanks,

Steve
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to