Hi, what error messages do you get? does osg find the plugin and fails when trying to open it? (you'll get some error-messages in the console.log, or if you run the plugin from inside xcode with safari as helper-application in the debug console.)
Have you adjusted the @loader_paths for the osg-libs and for the curl-plugin too? It's not sufficient to do this for the bin only. What is the output of "otool -L osgdb_curl.so" ? All references to the osg-libs should begin with @loader_path. cheers, Stephan Am 07.08.11 17:53, schrieb Guido Lucci Baldassari: > Good afternoon to everyone. > I'm on the early deployment phase of our OSG-based web plugin. I'm trying to > embed all the needed libraries inside the package bundle, in order to ease > the distribution and the installation for the final user. Unfortunately I > encountered some problems with the curl plugin, that cannot be found at > runtime. I did many tries and looked through the web, searching a solution, > before posting here. > > My procedure is: > > -build osg with the correct @loader_path for the plugin to work > -build the plugin > -copy inside the plugin bundle all the needed libraries > -fix the bin inside the plugn bundle with install_name_tool > > in this way everything loads correctly, except the curl plugin. > > My env is: > > OSG 3.0.0 (I use frameworks - I tried both: with and without the > osg_plugin_search_install_dir_for_plugins) > CMake 2.8.5 > Safari 5.1 (or Chrome Canary Build) > Mac OSX 10.6.8 > > Trying to understand where lies the problem: > > I used otool to check that everything was correct > > I tried setting explicitly OSG_LIBRARY_PATH to the absolute path, inside the > plugin source code. > > I tried finally with this method: > > I built OSG with INSTALL_PREFIX=<the real path of the future plugin> > then I copied all libraries from a previous build on another machine with the > same specifications, except the plugins directory > and everything worked, so I presume it's something hardcoded into the plugin. > > This last method, maybe can be used (not sure if it will work when moving or > coping the whole final package on other machines - I'll check later), but > seems to be just a workaround. Before to proceed with the job, I'd like to > ask here if anyone knows a better and clearer solution. > Thanks in advance > G. > _______________________________________________ > 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
