Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Hmmm okay... i've just looked at the definition of USE_OSGPLUGIN(...) and I
finally understood what you mean by static object to register the
plugin...
By the way, the difference between you and me could be the compiler: I'm
using gcc-4.1.2 with a target=i686-pc-linux-gnu... i'm on FedoraCore 6,
kernel 2.6.18, and running this in VMWare workstation 5.5.3 with a WinXP
host computer.
Manu.
2007/6/1, Emmanuel Roche [EMAIL PROTECTED]:
Hi Robert !
Sorry I took so long to answer, I was absent for a few days :-). Any way,
I tried the changes you made :
- The compilation went fine, osgstaticviewer was created,
- First I noticed the function graphicwindow_X11 was commented in
osgstaticviewer.cpp,
- This function also had an empty body in GraphicWindowX11.cpp, I simply
added something like osg::GraphicsContext:setWindowingSystemInterface(new
X11WindowingSystemInterface);
And this worked for me... I tryed to start osgstaticviewer multiple times
with an .ive file and had no particular error...
if i can make a small suggestion by the way: wouldn't it be more logical
to simply have a graphicwindow() function (and a more friendly function
name or a MACRO could be even better...) rather than graphicwindow_X11()
-- we could then define this same function in GraphicWindowX11.cpp,
GraphicWindowWin32.cpp, etc... as only a single .o file is linked there
should be no conflict no ? and we would hide implementation details for this
default windowing system to the users... (they would not have to change the
function they call depending on the platform used...).
Any way, concerning your sudden pointer reset, I've trully never seen this
and have now clue either (try a linux reboot maybe :-D )...
Manu.
2007/5/25, Robert Osfield [EMAIL PROTECTED]:
Hi Manu,
I have done some experiments with the static build side, and while its
not a full solution, I've checked in a few additions. First up is
some additions to osgDB that add a proxy help class and a couple of
macros. The first macro replaces the old Proxy object usage in the
plugin, for the ive plugin it now looks like:
// now register with Registry to instantiate the above
// reader/writer.
REGISTER_OSGPLUGIN(ive, ReaderWriterIVE)
This both constructs the C++ proxy and provides the extern C void
osgdb_ive(void) function.
Then in the application you now add:
#include...
USE_OSGPLUGIN(ive)
main(...)
{
...
}
Note, the macro doesn't require you to add the function call to the
main. This is thanks the USE_OSGPLUGIN use a local C++ proxy object
to call it for you automatically.
I also copied and pasted osgviewer app across to example and called it
osgstaticviewer, this example only builds during static build. It
includes the extra plugin link line in the CMakeLists.txt as well as
the above USE_OSGPLUGIN(ive). It'll need further expanding on in
future.
I have also add a C function into GraphicsWindowX11.cpp call void
graphicswindow_X11(void), and calling of this in osgstaticviewer's
main but while it does cause the GraphicsWindowX11.o to be linked and
even the proxies to register the WindowSystemInterfaceX11, the related
static pointer in src/osg/GraphicsContext.cpp resets itself to 0 for
some unknown reason, programatically its never reset to 0, it just
happens?#!. I have now clue why it doesn't work.
Anyway, what I've checked in might inch us closer to a final easing of
making static apps.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Hi Manu, - The compilation went fine, osgstaticviewer was created, - First I noticed the function graphicwindow_X11 was commented in osgstaticviewer.cpp, - This function also had an empty body in GraphicWindowX11.cpp, I simply added something like osg::GraphicsContext:setWindowingSystemInterface(new X11WindowingSystemInterface); Did you need to do anything in this function body, I didn't add anything because the X11WindowSystemInterface was registering itself anyway. And this worked for me... I tryed to start osgstaticviewer multiple times with an .ive file and had no particular error... Good to hear it worked. if i can make a small suggestion by the way: wouldn't it be more logical to simply have a graphicwindow() function (and a more friendly function name or a MACRO could be even better...) rather than graphicwindow_X11() -- we could then define this same function in GraphicWindowX11.cpp, GraphicWindowWin32.cpp, etc... as only a single .o file is linked there should be no conflict no ? and we would hide implementation details for this default windowing system to the users... (they would not have to change the function they call depending on the platform used...). Potentially we could have more than one GraphicsWindow* implementation on a single platfom, this is currently supported, but its technically possible and something I had in mind when I designed osgViewer. In this instance we need to be explict. For the time being I guess we could just go for the one function entry point. A macro could hide this too. Any way, concerning your sudden pointer reset, I've trully never seen this and have now clue either (try a linux reboot maybe :-D )... Reboot linux to try an fix a problem? You've obviously been too near a Windows machine recently. My guess is that their is a double initialization of the static for some reason. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Hi Robert !
Sorry I took so long to answer, I was absent for a few days :-). Any way, I
tried the changes you made :
- The compilation went fine, osgstaticviewer was created,
- First I noticed the function graphicwindow_X11 was commented in
osgstaticviewer.cpp,
- This function also had an empty body in GraphicWindowX11.cpp, I simply
added something like osg::GraphicsContext:setWindowingSystemInterface(new
X11WindowingSystemInterface);
And this worked for me... I tryed to start osgstaticviewer multiple times
with an .ive file and had no particular error...
if i can make a small suggestion by the way: wouldn't it be more logical to
simply have a graphicwindow() function (and a more friendly function name
or a MACRO could be even better...) rather than graphicwindow_X11() -- we
could then define this same function in GraphicWindowX11.cpp,
GraphicWindowWin32.cpp, etc... as only a single .o file is linked there
should be no conflict no ? and we would hide implementation details for this
default windowing system to the users... (they would not have to change the
function they call depending on the platform used...).
Any way, concerning your sudden pointer reset, I've trully never seen this
and have now clue either (try a linux reboot maybe :-D )...
Manu.
2007/5/25, Robert Osfield [EMAIL PROTECTED]:
Hi Manu,
I have done some experiments with the static build side, and while its
not a full solution, I've checked in a few additions. First up is
some additions to osgDB that add a proxy help class and a couple of
macros. The first macro replaces the old Proxy object usage in the
plugin, for the ive plugin it now looks like:
// now register with Registry to instantiate the above
// reader/writer.
REGISTER_OSGPLUGIN(ive, ReaderWriterIVE)
This both constructs the C++ proxy and provides the extern C void
osgdb_ive(void) function.
Then in the application you now add:
#include...
USE_OSGPLUGIN(ive)
main(...)
{
...
}
Note, the macro doesn't require you to add the function call to the
main. This is thanks the USE_OSGPLUGIN use a local C++ proxy object
to call it for you automatically.
I also copied and pasted osgviewer app across to example and called it
osgstaticviewer, this example only builds during static build. It
includes the extra plugin link line in the CMakeLists.txt as well as
the above USE_OSGPLUGIN(ive). It'll need further expanding on in
future.
I have also add a C function into GraphicsWindowX11.cpp call void
graphicswindow_X11(void), and calling of this in osgstaticviewer's
main but while it does cause the GraphicsWindowX11.o to be linked and
even the proxies to register the WindowSystemInterfaceX11, the related
static pointer in src/osg/GraphicsContext.cpp resets itself to 0 for
some unknown reason, programatically its never reset to 0, it just
happens?#!. I have now clue why it doesn't work.
Anyway, what I've checked in might inch us closer to a final easing of
making static apps.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Hi again Robert, concerning the self registering of the X11WindowingSystemInterface: no, if I remove the stuff I added it's not working anymore... And I don't see how it could work ? we are just calling an empty function in this case... how do you know the X11WindowSystemInterface was registering itself anyway ??... it seems quite impossible to me with the sources on the SVN... :-( Manu. 2007/6/1, Robert Osfield [EMAIL PROTECTED]: Hi Manu, - The compilation went fine, osgstaticviewer was created, - First I noticed the function graphicwindow_X11 was commented in osgstaticviewer.cpp, - This function also had an empty body in GraphicWindowX11.cpp, I simply added something like osg::GraphicsContext:setWindowingSystemInterface(new X11WindowingSystemInterface); Did you need to do anything in this function body, I didn't add anything because the X11WindowSystemInterface was registering itself anyway. And this worked for me... I tryed to start osgstaticviewer multiple times with an .ive file and had no particular error... Good to hear it worked. if i can make a small suggestion by the way: wouldn't it be more logical to simply have a graphicwindow() function (and a more friendly function name or a MACRO could be even better...) rather than graphicwindow_X11() -- we could then define this same function in GraphicWindowX11.cpp, GraphicWindowWin32.cpp, etc... as only a single .o file is linked there should be no conflict no ? and we would hide implementation details for this default windowing system to the users... (they would not have to change the function they call depending on the platform used...). Potentially we could have more than one GraphicsWindow* implementation on a single platfom, this is currently supported, but its technically possible and something I had in mind when I designed osgViewer. In this instance we need to be explict. For the time being I guess we could just go for the one function entry point. A macro could hide this too. Any way, concerning your sudden pointer reset, I've trully never seen this and have now clue either (try a linux reboot maybe :-D )... Reboot linux to try an fix a problem? You've obviously been too near a Windows machine recently. My guess is that their is a double initialization of the static for some reason. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
On 6/1/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hi again Robert, concerning the self registering of the X11WindowingSystemInterface: no, if I remove the stuff I added it's not working anymore... And I don't see how it could work ? we are just calling an empty function in this case... how do you know the X11WindowSystemInterface was registering itself anyway ??... it seems quite impossible to me with the sources on the SVN... :-( I know because I added debug messages to the constructor of X11WindowSystemInterface, the proxy in GraphicsWindowX11.cpp was doing the registeration automatically as it does when you link to the osgViewer.so, but it then was being screwed over by the static pointer reset somehow - I've got the debug message record showing the pointer set to the object in question, then changing back to zero without it ever being set programmaticaly. What is probably happening at your end is that the proxy was registering the X11WidowSystemInterface, then the static pointer was re-initialized, then your version of graphhicswindow_x11() function was registering X11WindowSystemInterface. Perhaps the solution is not to compile the proxy in static build, just rely upon the function to it. Curious the ive plugin is working and their is a proxy involved there too. This suggests to be that the static Registry pointer is already initialized in that case. Its seems to be a fluke though... Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Yes... I've just realized also that the plugins use the same system and seem
to work correctly... :-( really really strange... as you said, maybe it
would be a better idea not to use those proxy classes and rely simply on the
function call, no ?
In GraphicsWindowX11.cpp i was using this code:
RegisterWindowingSystemInterfaceProxy createWindowingSystemInterfaceProxy;
// declare C entry point for static compilation.
extern C {
void graphicswindow(void)
{
osg::GraphicsContext::setWindowingSystemInterface(new
X11WindowingSystemInterface);
}
}
... whereas the REGISTER_OSGPLUGIN() was creating a static proxy object...
so I tried with the following code:
static RegisterWindowingSystemInterfaceProxy
createWindowingSystemInterfaceProxy;
// declare C entry point for static compilation.
extern C {
void graphicswindow(void)
{
}
}
... but this didn't work for me :-(...
Manu.
2007/6/1, Robert Osfield [EMAIL PROTECTED]:
On 6/1/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hi again Robert,
concerning the self registering of the X11WindowingSystemInterface: no,
if I
remove the stuff I added it's not working anymore... And I don't see how
it
could work ? we are just calling an empty function in this case...
how do you know the X11WindowSystemInterface was registering itself
anyway
??... it seems quite impossible to me with the sources on the SVN... :-(
I know because I added debug messages to the constructor of
X11WindowSystemInterface, the proxy in GraphicsWindowX11.cpp was doing
the registeration automatically as it does when you link to the
osgViewer.so, but it then was being screwed over by the static pointer
reset somehow - I've got the debug message record showing the pointer
set to the object in question, then changing back to zero without it
ever being set programmaticaly.
What is probably happening at your end is that the proxy was
registering the X11WidowSystemInterface, then the static pointer was
re-initialized, then your version of graphhicswindow_x11() function
was registering X11WindowSystemInterface.
Perhaps the solution is not to compile the proxy in static build, just
rely upon the function to it.
Curious the ive plugin is working and their is a proxy involved there
too. This suggests to be that the static Registry pointer is already
initialized in that case. Its seems to be a fluke though...
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Hi Manu,
I have done some experiments with the static build side, and while its
not a full solution, I've checked in a few additions. First up is
some additions to osgDB that add a proxy help class and a couple of
macros. The first macro replaces the old Proxy object usage in the
plugin, for the ive plugin it now looks like:
// now register with Registry to instantiate the above
// reader/writer.
REGISTER_OSGPLUGIN(ive, ReaderWriterIVE)
This both constructs the C++ proxy and provides the extern C void
osgdb_ive(void) function.
Then in the application you now add:
#include...
USE_OSGPLUGIN(ive)
main(...)
{
...
}
Note, the macro doesn't require you to add the function call to the
main. This is thanks the USE_OSGPLUGIN use a local C++ proxy object
to call it for you automatically.
I also copied and pasted osgviewer app across to example and called it
osgstaticviewer, this example only builds during static build. It
includes the extra plugin link line in the CMakeLists.txt as well as
the above USE_OSGPLUGIN(ive). It'll need further expanding on in
future.
I have also add a C function into GraphicsWindowX11.cpp call void
graphicswindow_X11(void), and calling of this in osgstaticviewer's
main but while it does cause the GraphicsWindowX11.o to be linked and
even the proxies to register the WindowSystemInterfaceX11, the related
static pointer in src/osg/GraphicsContext.cpp resets itself to 0 for
some unknown reason, programatically its never reset to 0, it just
happens?#!. I have now clue why it doesn't work.
Anyway, what I've checked in might inch us closer to a final easing of
making static apps.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Great !! I'm on this now: I will need to find how to retrieve the symbols in
lib file under linux then how to force gcc to include specific symbols, then
how to tell CMake to force gcc to do this :-)
I'll tell you as soon as I find something.
Manu.
2007/5/23, Robert Osfield [EMAIL PROTECTED]:
Forgot to mention my change is now checked in.
On 5/23/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Manu,
My suggested change to CMakeModules/OsgMacroUtils.cmake works just
fine, both dynamic and static builds work, with both libs and plugins
compiling as static when requested.
osgviewer tells me that it can't find plugins or
windowsysteminterface, but hey you've been there before.
So how did you go about fixing these?
Robert.
On 5/23/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Manu,
On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
And changing this 'MODULE' variable tout STATIC leads to the
construction
of static plugin libs ! bingo !
I guess someone should include somewhere the test done for the core
libs to
decide here if we should have SHARED or STATIC... what was this
'MODULE'
used for in fact ??
The plugin macro in OpenSceneGraph/CMakeModules/OsgMacroUtils.cmake,
and the macro specifically is:
MACRO(SETUP_PLUGIN PLUGIN_NAME)
...
It should be easy to put a conditional, looking at the compile of core
libs, it looks like it should be possible to use:
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} MODULE ${TARGET_SRC}
${TARGET_H})
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} STATIC ${TARGET_SRC}
${TARGET_H})
ENDIF(DYNAMIC_OPENSCENEGRAPH)
I'll do a clean dynamic build, then try out the static build too.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: And changing this 'MODULE' variable tout STATIC leads to the construction of static plugin libs ! bingo ! I guess someone should include somewhere the test done for the core libs to decide here if we should have SHARED or STATIC... what was this 'MODULE' used for in fact ?? I missed most of the thread, but unlike Windows and ELF, Mach-O makes a hard distinction between a dynamic library and loadable bundle (a.k.a. plugin a.k.a module). CMake handles this by providing SHARED vs. MODULE. Don't use/mix-up SHARED with MODULE or Mach-O derived systems will break. -Eric ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Okay, here are some news: - under linux we can use the command 'nm' to retrieve the symbol table from a static library: ie: nm libosgdb_osg.a osg.symbols will write the file osg.symbols then we can retrieve the valuable symbols with sed: - for osgViewer: sed -n -e s/RegisterWindowingSystemInterfaceProxy/RegisterWindowingSystemInterfaceProxy/p osgViewer.symbols osgViewer.sym -for the plugins: sed -n -e s/RegisterReaderWriterProxy/RegisterReaderWriterProxy/p -e s//RegisterDotOsgWrapperProxy/RegisterDotOsgWrapperProxy/p osg.symbols osg.sym for osgViewer I get something like: W _ZN37RegisterWindowingSystemInterfaceProxyC1Ev W _ZN37RegisterWindowingSystemInterfaceProxyD1Ev I created a simple scons project from osganimate source file, with the following file system structure: test_project build osganimate src osganimate.cpp Scontruct and as Scontruct file: Program(build/osganimate,src/osganimate.cpp, CPPFLAGS=['-g0','-O3','-pthread'], LIBPATH=[/usr/local/lib,/home/kenshin/dev/libraries/linux32/gcc-4.1.2 /OSG-static-release/lib,/home/kenshin/dev/libraries/linux32/gcc-4.1.2 /OSG-static-release/lib/osgPlugins-1.9.5], CPPPATH=[/usr/local/include,/home/kenshin/dev/libraries/linux32/gcc-4.1.2/OpenSceneGraph-svn/include], LIBS=['osgdb_osg','osgDB','osgFX','osgParticle','osgViewer','osgGA','osgUtil','osgText','osgManipulator','osgSim','osg','OpenThreads','GLU','GL'], CPPDEFINES=['OSG_LIBRARY_STATIC','OT_LIBRARY_STATIC'], LINKFLAGS=['-u_ZN37RegisterWindowingSystemInterfaceProxyD1Ev'] ) -- As you may see the command to force gcc to include a symbol is thus '-u'+symbol linking with either the D or the C version give the save result... and... IT WORKS ! :-D ... I mean at least for the registering of the osgViewer stuff... unfortunately it is not the case for the plugins yet :-(... in fact, as valuable symbols for the osgdb_osg plugin, I retrieve something like: W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Hmmm yet it works fine for plugin with their single RegisterReaderWriterProxy object !! :-) -- I managed to start osgviewer with a .ive file !!! :-D So considering the symbol lists I already have for windows I would say that the only problematic plugins (in the common and image series at least) are osg and osgParticle Manu. 2007/5/24, Emmanuel Roche [EMAIL PROTECTED]: Okay, here are some news: - under linux we can use the command 'nm' to retrieve the symbol table from a static library: ie: nm libosgdb_osg.a osg.symbols will write the file osg.symbols then we can retrieve the valuable symbols with sed: - for osgViewer: sed -n -e s/RegisterWindowingSystemInterfaceProxy/RegisterWindowingSystemInterfaceProxy/p osgViewer.symbols osgViewer.sym -for the plugins: sed -n -e s/RegisterReaderWriterProxy/RegisterReaderWriterProxy/p -e s//RegisterDotOsgWrapperProxy/RegisterDotOsgWrapperProxy/p osg.symbols osg.sym for osgViewer I get something like: W _ZN37RegisterWindowingSystemInterfaceProxyC1Ev W _ZN37RegisterWindowingSystemInterfaceProxyD1Ev I created a simple scons project from osganimate source file, with the following file system structure: test_project build osganimate src osganimate.cpp Scontruct and as Scontruct file: Program(build/osganimate,src/osganimate.cpp, CPPFLAGS=['-g0','-O3','-pthread'], LIBPATH=[/usr/local/lib,/home/kenshin/dev/libraries/linux32/gcc-4.1.2/OSG-static-release/lib,/home/kenshin/dev/libraries/linux32/gcc- 4.1.2/OSG-static-release/lib/osgPlugins-1.9.5], CPPPATH=[/usr/local/include,/home/kenshin/dev/libraries/linux32/gcc- 4.1.2 /OpenSceneGraph-svn/include], LIBS=['osgdb_osg','osgDB','osgFX','osgParticle','osgViewer','osgGA','osgUtil','osgText','osgManipulator','osgSim','osg','OpenThreads','GLU','GL'], CPPDEFINES=['OSG_LIBRARY_STATIC','OT_LIBRARY_STATIC'], LINKFLAGS=['-u_ZN37RegisterWindowingSystemInterfaceProxyD1Ev'] ) -- As you may see the command to force gcc to include a symbol is thus '-u'+symbol linking with either the D or the C version give the save result... and... IT WORKS ! :-D ... I mean at least for the registering of the osgViewer stuff... unfortunately it is not the case for the plugins yet :-(... in fact, as valuable symbols for the osgdb_osg plugin, I retrieve something like: W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W _ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev W
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Hi Many, On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hmmm yet it works fine for plugin with their single RegisterReaderWriterProxy object !! :-) -- I managed to start osgviewer with a .ive file !!! :-D So considering the symbol lists I already have for windows I would say that the only problematic plugins (in the common and image series at least) are osg and osgParticle Good to hear that you've made further progress. It would be nice to be able to automate some of this leg work. I do also wonder about the possibility of use a C functions in the plugins to allow one to grab the sybmol with the name manging, this might help the process of making things more automated. W.r.t .osg plugin and others of its type they all use an proxy mechanism for registering the ReaderWriter (read.write files) and the DotOsgWrappers (read/write the objects), its the later which is different from the rest of the plugins. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Well, things aren't going that well unfortunately: I've just realize that every plugin that use even a single RegisterDotOsgWrapperProxy return the exact SAME symbol for this object... and I cannot find anyway to tell gcc to include the same symbol from multiple libraries (or worse from multiple objets files in a single library in the case of osg...): This means for example that we can't link with osgdb_osgText and osgdb_osgFX at the same time for example... :'( concerning the automation of the process, indeed, it's quite heavy... but I doubt there is any C function to retrieve the mangled name internally the best solution would be to use small scripts just after core and plugins libs construction to find all the needed symbols and then to include them for each sample... and for other projets... hmm... well... we can still use the generated symbols but I don't see anything better for the moment :-) Manu. 2007/5/24, Robert Osfield [EMAIL PROTECTED]: Hi Many, On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hmmm yet it works fine for plugin with their single RegisterReaderWriterProxy object !! :-) -- I managed to start osgviewer with a .ive file !!! :-D So considering the symbol lists I already have for windows I would say that the only problematic plugins (in the common and image series at least) are osg and osgParticle Good to hear that you've made further progress. It would be nice to be able to automate some of this leg work. I do also wonder about the possibility of use a C functions in the plugins to allow one to grab the sybmol with the name manging, this might help the process of making things more automated. W.r.t .osg plugin and others of its type they all use an proxy mechanism for registering the ReaderWriter (read.write files) and the DotOsgWrappers (read/write the objects), its the later which is different from the rest of the plugins. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
HI Manu,
My thought about using C functions would be for them to be unique for
each ReaderWriter i.e :
extern C {
void osgdb_ive(void)
{
}
};
Would be added to the ive plugin, and the same goes for the other
plugins. One could possible do this via a macro when doing the proxy
instantiation just to simplify the source code. Could you try this
as a quick hack and let me know how you get on.
The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.
Robert.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Well, things aren't going that well unfortunately:
I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this object...
and I cannot find anyway to tell gcc to include the same symbol from
multiple libraries (or worse from multiple objets files in a single library
in the case of osg...): This means for example that we can't link with
osgdb_osgText and osgdb_osgFX at the same time for example... :'(
concerning the automation of the process, indeed, it's quite heavy... but I
doubt there is any C function to retrieve the mangled name internally
the best solution would be to use small scripts just after core and plugins
libs construction to find all the needed symbols and then to include them
for each sample...
and for other projets... hmm... well... we can still use the generated
symbols but I don't see anything better for the moment :-)
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)
-- I managed to start osgviewer with a .ive file !!! :-D
So considering the symbol lists I already have for windows I would say
that
the only problematic plugins (in the common and image series at
least)
are osg and osgParticle
Good to hear that you've made further progress. It would be nice to
be able to automate some of this leg work. I do also wonder about the
possibility of use a C functions in the plugins to allow one to grab
the sybmol with the name manging, this might help the process of
making things more automated.
W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter (read.write files) and the
DotOsgWrappers (read/write the objects), its the later which is
different from the rest of the plugins.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
I'm not sure to understand : what would be this function for ? to register
the plugin in static mode ? so every sample and projects would have to call
the needed functions when starting its process (checking for static mode):
is this what you're thinking about ?
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
HI Manu,
My thought about using C functions would be for them to be unique for
each ReaderWriter i.e :
extern C {
void osgdb_ive(void)
{
}
};
Would be added to the ive plugin, and the same goes for the other
plugins. One could possible do this via a macro when doing the proxy
instantiation just to simplify the source code. Could you try this
as a quick hack and let me know how you get on.
The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.
Robert.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Well, things aren't going that well unfortunately:
I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
and I cannot find anyway to tell gcc to include the same symbol from
multiple libraries (or worse from multiple objets files in a single
library
in the case of osg...): This means for example that we can't link with
osgdb_osgText and osgdb_osgFX at the same time for example... :'(
concerning the automation of the process, indeed, it's quite heavy...
but I
doubt there is any C function to retrieve the mangled name internally
the best solution would be to use small scripts just after core and
plugins
libs construction to find all the needed symbols and then to include
them
for each sample...
and for other projets... hmm... well... we can still use the generated
symbols but I don't see anything better for the moment :-)
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)
-- I managed to start osgviewer with a .ive file !!! :-D
So considering the symbol lists I already have for windows I would
say
that
the only problematic plugins (in the common and image series
at
least)
are osg and osgParticle
Good to hear that you've made further progress. It would be nice to
be able to automate some of this leg work. I do also wonder about the
possibility of use a C functions in the plugins to allow one to grab
the sybmol with the name manging, this might help the process of
making things more automated.
W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter (read.write files) and the
DotOsgWrappers (read/write the objects), its the later which is
different from the rest of the plugins.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
In this case, I think we should add two functions: one to register the
readerwriter and an other to unregister it... no ? (I don't see how to
provide the same functionalities than the Register..Proxy in a single
function call...)
Manu.
2007/5/24, Emmanuel Roche [EMAIL PROTECTED]:
I'm not sure to understand : what would be this function for ? to register
the plugin in static mode ? so every sample and projects would have to call
the needed functions when starting its process (checking for static mode):
is this what you're thinking about ?
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
HI Manu,
My thought about using C functions would be for them to be unique for
each ReaderWriter i.e :
extern C {
void osgdb_ive(void)
{
}
};
Would be added to the ive plugin, and the same goes for the other
plugins. One could possible do this via a macro when doing the proxy
instantiation just to simplify the source code. Could you try this
as a quick hack and let me know how you get on.
The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.
Robert.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Well, things aren't going that well unfortunately:
I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
and I cannot find anyway to tell gcc to include the same symbol from
multiple libraries (or worse from multiple objets files in a single
library
in the case of osg...): This means for example that we can't link with
osgdb_osgText and osgdb_osgFX at the same time for example... :'(
concerning the automation of the process, indeed, it's quite heavy...
but I
doubt there is any C function to retrieve the mangled name internally
the best solution would be to use small scripts just after core and
plugins
libs construction to find all the needed symbols and then to include
them
for each sample...
and for other projets... hmm... well... we can still use the generated
symbols but I don't see anything better for the moment :-)
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)
-- I managed to start osgviewer with a .ive file !!! :-D
So considering the symbol lists I already have for windows I would
say
that
the only problematic plugins (in the common and image series
at
least)
are osg and osgParticle
Good to hear that you've made further progress. It would be nice to
be able to automate some of this leg work. I do also wonder about
the
possibility of use a C functions in the plugins to allow one to grab
the sybmol with the name manging, this might help the process of
making things more automated.
W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter (read.write files) and
the
DotOsgWrappers (read/write the objects), its the later which is
different from the rest of the plugins.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote: I'm not sure to understand : what would be this function for ? to register the plugin in static mode ? so every sample and projects would have to call the needed functions when starting its process (checking for static mode): is this what you're thinking about ? One would only ever use this function for the symbol it generates, its purely a helper to you when you statically link. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
yes but... thinking about it:
- if we build in static mode this means that we already know what plugins
will be used at compile time. So the code can be changed instead of changing
the symbols to include... What I mean is : instead of trying to play with
those unfriendly symbols (depends on architecture, compiler, platform,
etc... ?), since we ARE already linking with the plugin libraries anyway, on
could simply do something like:
In main project or sample file:
#ifdef OSG_LIBRARY_STATIC
extern C {
extern void register_ive();
extern void unregister_ive();
};
#endif
main() {
#ifdef OSG_LIBRARY_STATIC
register_ive();
#endif
// do what you want
// clean and quit:
#ifdef OSG_LIBRARY_STATIC
unregister_ive();
#endif
return 0;
}
at the end of the ReaderWriterIVE.cpp file:
extern C {
IVEReaderWriter* re_ive;
void register_ive(void)
{
re_ive = new IVEReaderWriter;
Registry::instance()-addReaderWriter(re_ive);
}
void unregister_ive(void)
{
Registry::instance()-removeReaderWriter(re_ive);
}
};
... I've just tested this and it works.. :-) no need to find the symbol for
the ive plugin anymore, no additional includes, just a few more code
lines... But I think this is the most friendly solution to all coders, no ?
With good macros this could even become something like:
DECLARE_PLUGIN(ive)
main() {
REGISTER_PLUGIN(ive)
// do what you want
UNREGISTER_PLUGIN(ive)
}
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
I'm not sure to understand : what would be this function for ? to
register
the plugin in static mode ? so every sample and projects would have to
call
the needed functions when starting its process (checking for static
mode):
is this what you're thinking about ?
One would only ever use this function for the symbol it generates, its
purely a helper to you when you statically link.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
You can't unload a static plugin... so why would you want to unload
the readerwriter?
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
In this case, I think we should add two functions: one to register the
readerwriter and an other to unregister it... no ? (I don't see how to
provide the same functionalities than the Register..Proxy in a single
function call...)
Manu.
2007/5/24, Emmanuel Roche [EMAIL PROTECTED]:
I'm not sure to understand : what would be this function for ? to register
the plugin in static mode ? so every sample and projects would have to call
the needed functions when starting its process (checking for static mode):
is this what you're thinking about ?
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
HI Manu,
My thought about using C functions would be for them to be unique for
each ReaderWriter i.e :
extern C {
void osgdb_ive(void)
{
}
};
Would be added to the ive plugin, and the same goes for the other
plugins. One could possible do this via a macro when doing the proxy
instantiation just to simplify the source code. Could you try this
as a quick hack and let me know how you get on.
The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.
Robert.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Well, things aren't going that well unfortunately:
I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
and I cannot find anyway to tell gcc to include the same symbol from
multiple libraries (or worse from multiple objets files in a single
library
in the case of osg...): This means for example that we can't link with
osgdb_osgText and osgdb_osgFX at the same time for example... :'(
concerning the automation of the process, indeed, it's quite heavy...
but I
doubt there is any C function to retrieve the mangled name internally
the best solution would be to use small scripts just after core and
plugins
libs construction to find all the needed symbols and then to include
them
for each sample...
and for other projets... hmm... well... we can still use the generated
symbols but I don't see anything better for the moment :-)
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)
-- I managed to start osgviewer with a .ive file !!! :-D
So considering the symbol lists I already have for windows I would
say
that
the only problematic plugins (in the common and image series
at
least)
are osg and osgParticle
Good to hear that you've made further progress. It would be nice to
be able to automate some of this leg work. I do also wonder about
the
possibility of use a C functions in the plugins to allow one to grab
the sybmol with the name manging, this might help the process of
making things more automated.
W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter (read.write files) and
the
DotOsgWrappers (read/write the objects), its the later which is
different from the rest of the plugins.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
You can't unload a static plugin... so why would you want to unload
the readerwriter?
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
In this case, I think we should add two functions: one to register the
readerwriter and an other to unregister it... no ? (I don't see how to
provide the same functionalities than the Register..Proxy in a single
function call...)
Manu.
2007/5/24, Emmanuel Roche [EMAIL PROTECTED]:
I'm not sure to understand : what would be this function for ? to
register
the plugin in static mode ? so every sample and projects would have to
call
the needed functions when starting its process (checking for static
mode):
is this what you're thinking about ?
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
HI Manu,
My thought about using C functions would be for them to be unique
for
each ReaderWriter i.e :
extern C {
void osgdb_ive(void)
{
}
};
Would be added to the ive plugin, and the same goes for the other
plugins. One could possible do this via a macro when doing the
proxy
instantiation just to simplify the source code. Could you try this
as a quick hack and let me know how you get on.
The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.
Robert.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Well, things aren't going that well unfortunately:
I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
and I cannot find anyway to tell gcc to include the same symbol
from
multiple libraries (or worse from multiple objets files in a
single
library
in the case of osg...): This means for example that we can't link
with
osgdb_osgText and osgdb_osgFX at the same time for example... :'(
concerning the automation of the process, indeed, it's quite
heavy...
but I
doubt there is any C function to retrieve the mangled name
internally
the best solution would be to use small scripts just after core
and
plugins
libs construction to find all the needed symbols and then to
include
them
for each sample...
and for other projets... hmm... well... we can still use the
generated
symbols but I don't see anything better for the moment :-)
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)
-- I managed to start osgviewer with a .ive file !!! :-D
So considering the symbol lists I already have for windows I
would
say
that
the only problematic plugins (in the common and image
series
at
least)
are osg and osgParticle
Good to hear that you've made further progress. It would be
nice to
be able to automate some of this leg work. I do also wonder
about
the
possibility of use a C functions in the plugins to allow one to
grab
the sybmol with the name manging, this might help the process of
making things more automated.
W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter (read.write files)
and
the
DotOsgWrappers (read/write the objects), its the later which is
different from the rest of the plugins.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
oups... I pressed Send too fast :-)
I just wanted to say:
Good point ! you're right: unloading the readerwriter seems useless in most
cases... (at least for me :-) ) [except maybe if someone has multiple
version of the same plugin changing dynamically... but that would be a bit
weird I guess :-)]
So, are you planning to had this C function to all plugins now ?...
I guess the same behavior could be used internally to register the
DotOsgWrappers too... I'll test that tomorrow.
Manu.
2007/5/24, Emmanuel Roche [EMAIL PROTECTED]:
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
You can't unload a static plugin... so why would you want to unload
the readerwriter?
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
In this case, I think we should add two functions: one to register the
readerwriter and an other to unregister it... no ? (I don't see how to
provide the same functionalities than the Register..Proxy in a single
function call...)
Manu.
2007/5/24, Emmanuel Roche [EMAIL PROTECTED]:
I'm not sure to understand : what would be this function for ? to
register
the plugin in static mode ? so every sample and projects would have to
call
the needed functions when starting its process (checking for static
mode):
is this what you're thinking about ?
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
HI Manu,
My thought about using C functions would be for them to be unique
for
each ReaderWriter i.e :
extern C {
void osgdb_ive(void)
{
}
};
Would be added to the ive plugin, and the same goes for the other
plugins. One could possible do this via a macro when doing the
proxy
instantiation just to simplify the source code. Could you try
this
as a quick hack and let me know how you get on.
The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.
Robert.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Well, things aren't going that well unfortunately:
I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
and I cannot find anyway to tell gcc to include the same symbol
from
multiple libraries (or worse from multiple objets files in a
single
library
in the case of osg...): This means for example that we can't
link with
osgdb_osgText and osgdb_osgFX at the same time for example...
:'(
concerning the automation of the process, indeed, it's quite
heavy...
but I
doubt there is any C function to retrieve the mangled name
internally
the best solution would be to use small scripts just after core
and
plugins
libs construction to find all the needed symbols and then to
include
them
for each sample...
and for other projets... hmm... well... we can still use the
generated
symbols but I don't see anything better for the moment :-)
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
Hi Many,
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)
-- I managed to start osgviewer with a .ive file !!! :-D
So considering the symbol lists I already have for windows I
would
say
that
the only problematic plugins (in the common and image
series
at
least)
are osg and osgParticle
Good to hear that you've made further progress. It would be
nice to
be able to automate some of this leg work. I do also wonder
about
the
possibility of use a C functions in the plugins to allow one
to grab
the sybmol with the name manging, this might help the process
of
making things more automated.
W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter ( read.write files)
and
the
DotOsgWrappers (read/write the objects), its the later which
is
different from the rest of the plugins.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
I quite like the macro option. It makes sense.
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
yes but... thinking about it:
- if we build in static mode this means that we already know what plugins
will be used at compile time. So the code can be changed instead of changing
the symbols to include... What I mean is : instead of trying to play with
those unfriendly symbols (depends on architecture, compiler, platform,
etc... ?), since we ARE already linking with the plugin libraries anyway, on
could simply do something like:
In main project or sample file:
#ifdef OSG_LIBRARY_STATIC
extern C {
extern void register_ive();
extern void unregister_ive();
};
#endif
main() {
#ifdef OSG_LIBRARY_STATIC
register_ive();
#endif
// do what you want
// clean and quit:
#ifdef OSG_LIBRARY_STATIC
unregister_ive();
#endif
return 0;
}
at the end of the ReaderWriterIVE.cpp file:
extern C {
IVEReaderWriter* re_ive;
void register_ive(void)
{
re_ive = new IVEReaderWriter;
Registry::instance()-addReaderWriter(re_ive);
}
void unregister_ive(void)
{
Registry::instance()-removeReaderWriter(re_ive);
}
};
... I've just tested this and it works.. :-) no need to find the symbol for
the ive plugin anymore, no additional includes, just a few more code
lines... But I think this is the most friendly solution to all coders, no ?
With good macros this could even become something like:
DECLARE_PLUGIN(ive)
main() {
REGISTER_PLUGIN(ive)
// do what you want
UNREGISTER_PLUGIN(ive)
}
Manu.
2007/5/24, Robert Osfield [EMAIL PROTECTED]:
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
I'm not sure to understand : what would be this function for ? to
register
the plugin in static mode ? so every sample and projects would have to
call
the needed functions when starting its process (checking for static
mode):
is this what you're thinking about ?
One would only ever use this function for the symbol it generates, its
purely a helper to you when you statically link.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
On 5/24/07, Emmanuel Roche [EMAIL PROTECTED] wrote: oups... I pressed Send too fast :-) I just wanted to say: Good point ! you're right: unloading the readerwriter seems useless in most cases... (at least for me :-) ) [except maybe if someone has multiple version of the same plugin changing dynamically... but that would be a bit weird I guess :-)] So, are you planning to had this C function to all plugins now ?... I guess the same behavior could be used internally to register the DotOsgWrappers too... I'll test that tomorrow. Well if it works, then a macro helper for users mains, and then C functions entry points in the plugins would be a good step forward. I don't plan on going through all the plugins myself though, my RSI won't cope with that I'm afraid. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
On 5/24/07, Robert Osfield [EMAIL PROTECTED] wrote: I don't plan on going through all the plugins myself though, my RSI won't cope with that I'm afraid. Forgot to say... need a willing helper. Might I suggest modifying one plugin (i.e. ive) and osgViewer to work, then submit this for review, then once we have this refined I can give the go ahead for it being rolled out to all plugins. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Re: OSG 1.9.5 static build on linux 2.6
I finished this first build test (static core libs + shared plugin libs): two remarks: 1) the example osgDepthShadow won't compile: [ 88%] Building CXX object examples/osgdepthshadow/CMakeFiles/example_osgdepthshadow.dir/osgdepthshadow.o Linking CXX executable ../../bin/osgdepthshadow /home/kenshin/dev/libraries/linux32/gcc-4.1.2/OpenSceneGraph-1.9.5 /lib/libosgShadow.a(ShadowMap.o):(.data+0x0): multiple definition of `fragmentShaderSource_noBaseTexture' CMakeFiles/example_osgdepthshadow.dir/osgdepthshadow.o:(.data+0x0): first defined here /home/kenshin/dev/libraries/linux32/gcc-4.1.2/OpenSceneGraph-1.9.5 /lib/libosgShadow.a(ShadowMap.o):(.data+0xe0): multiple definition of `fragmentShaderSource_withBaseTexture' CMakeFiles/example_osgdepthshadow.dir/osgdepthshadow.o:(.data+0xe0): first defined here collect2: ld a retourné 1 code d'état d'exécution make[2]: *** [bin/osgdepthshadow] Erreur 1 .. obviously this is linked to the static build process... 2) I have the same problem than I had under WinXP at the beginning: when I try to run osganimate I get: [EMAIL PROTECTED] bin]$ ./osganimate Warning: Could not find plugin to read objects from file glider.osg. Warning: Could not find plugin to read objects from file cessna.osg. View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows. Viewer::realize() - failed to set up any windows -- the auto referencing of the GraphicWindowX11 interface doesn't happen neither :-) By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... regards, Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED]: Hello ! I'm trying to build this release of OSG on linux this time. First thing noticable: the plugins are still built as shared libraries (in mode OPENSCENEGRAPH_DYNAMIC=OFF)... is this normal ?? I've got a question any way: On windows, when I was trying to use .dll for the plugins mixed with static core libraries it didn't work: I'm not un expert, but I guess this could have something to do with static objects in osgDB.lib existing in two places (the application and the plugin) and not being shared as one would expect (please tell me if this explanation is totally wrong :-) ). So I came to the conclusion that everything must be shared or static... is this still true under linux with gcc ??? if it is, then it means we have to build static plugin libs and then to force the compiler to include the needed symbols again... (correct me if I'm wrong but I think that current gcc versions (4.1 at least...) perform function level linking by default). Does anyone know how to retrieve the symbol list from the librairy ? (ie: what is the corresponding command for MS dumpbin.exe ? :-)) still if my previous assumption is true for linux, could someone just tell me what should be changed in order to built static plugin libs in the Cmake files ? Now, if this assumption is wrong, it would mean that I should expect this current compilation (static core libs + shared plugin libs) to work just fine ? regards, Manu. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... You may well be the first under Windows and Unix :-) W.r.t the multiple definitions in osgShadow/osgdepthshadow example, I've just made the local definiations of the shaders static in the osgShadow and checked it in. Could you let me know if this fixes it. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
It's good ! the correction you made solved the problem for osgdepthshadow sample ! :-) Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED]: Okay, the compilation is in progress... Now, is there a simple way to force Cmake to build static libs for the plugins ? I really don't understand nothing to those files lol... Manu. 2007/5/23, Robert Osfield [EMAIL PROTECTED]: On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... You may well be the first under Windows and Unix :-) W.r.t the multiple definitions in osgShadow/osgdepthshadow example, I've just made the local definiations of the shaders static in the osgShadow and checked it in. Could you let me know if this fixes it. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Okay, the compilation is in progress... Now, is there a simple way to force Cmake to build static libs for the plugins ? I really don't understand nothing to those files lol... Manu. 2007/5/23, Robert Osfield [EMAIL PROTECTED]: On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... You may well be the first under Windows and Unix :-) W.r.t the multiple definitions in osgShadow/osgdepthshadow example, I've just made the local definiations of the shaders static in the osgShadow and checked it in. Could you let me know if this fixes it. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Concerning the build process for the plugins I think I finally have a clue: everything seems to come to the function ADD_LIBRARY in the CMake files... for the core libs, the second parameter for this function can apparently be SHARED or STATIC depending on the configuration whereas for the plugins, it seems to always be the variable 'MODULE' :-). I keep digging... :-) Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED]: It's good ! the correction you made solved the problem for osgdepthshadow sample ! :-) Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED] : Okay, the compilation is in progress... Now, is there a simple way to force Cmake to build static libs for the plugins ? I really don't understand nothing to those files lol... Manu. 2007/5/23, Robert Osfield [EMAIL PROTECTED]: On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... You may well be the first under Windows and Unix :-) W.r.t the multiple definitions in osgShadow/osgdepthshadow example, I've just made the local definiations of the shaders static in the osgShadow and checked it in. Could you let me know if this fixes it. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
And changing this 'MODULE' variable tout STATIC leads to the construction of static plugin libs ! bingo ! I guess someone should include somewhere the test done for the core libs to decide here if we should have SHARED or STATIC... what was this 'MODULE' used for in fact ?? Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED]: Concerning the build process for the plugins I think I finally have a clue: everything seems to come to the function ADD_LIBRARY in the CMake files... for the core libs, the second parameter for this function can apparently be SHARED or STATIC depending on the configuration whereas for the plugins, it seems to always be the variable 'MODULE' :-). I keep digging... :-) Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED]: It's good ! the correction you made solved the problem for osgdepthshadow sample ! :-) Manu. 2007/5/23, Emmanuel Roche [EMAIL PROTECTED] : Okay, the compilation is in progress... Now, is there a simple way to force Cmake to build static libs for the plugins ? I really don't understand nothing to those files lol... Manu. 2007/5/23, Robert Osfield [EMAIL PROTECTED]: On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote: By the way, Is someone else working on this static build process or am I on my own... ? I guess I have to find out a bit more about CMake and linux symbols anyway... You may well be the first under Windows and Unix :-) W.r.t the multiple definitions in osgShadow/osgdepthshadow example, I've just made the local definiations of the shaders static in the osgShadow and checked it in. Could you let me know if this fixes it. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Hi Manu,
On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
And changing this 'MODULE' variable tout STATIC leads to the construction
of static plugin libs ! bingo !
I guess someone should include somewhere the test done for the core libs to
decide here if we should have SHARED or STATIC... what was this 'MODULE'
used for in fact ??
The plugin macro in OpenSceneGraph/CMakeModules/OsgMacroUtils.cmake,
and the macro specifically is:
MACRO(SETUP_PLUGIN PLUGIN_NAME)
...
It should be easy to put a conditional, looking at the compile of core
libs, it looks like it should be possible to use:
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} MODULE ${TARGET_SRC} ${TARGET_H})
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} STATIC ${TARGET_SRC} ${TARGET_H})
ENDIF(DYNAMIC_OPENSCENEGRAPH)
I'll do a clean dynamic build, then try out the static build too.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Hi Manu,
My suggested change to CMakeModules/OsgMacroUtils.cmake works just
fine, both dynamic and static builds work, with both libs and plugins
compiling as static when requested.
osgviewer tells me that it can't find plugins or
windowsysteminterface, but hey you've been there before.
So how did you go about fixing these?
Robert.
On 5/23/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Manu,
On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
And changing this 'MODULE' variable tout STATIC leads to the construction
of static plugin libs ! bingo !
I guess someone should include somewhere the test done for the core libs to
decide here if we should have SHARED or STATIC... what was this 'MODULE'
used for in fact ??
The plugin macro in OpenSceneGraph/CMakeModules/OsgMacroUtils.cmake,
and the macro specifically is:
MACRO(SETUP_PLUGIN PLUGIN_NAME)
...
It should be easy to put a conditional, looking at the compile of core
libs, it looks like it should be possible to use:
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} MODULE ${TARGET_SRC} ${TARGET_H})
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} STATIC ${TARGET_SRC} ${TARGET_H})
ENDIF(DYNAMIC_OPENSCENEGRAPH)
I'll do a clean dynamic build, then try out the static build too.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6
Forgot to mention my change is now checked in.
On 5/23/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Manu,
My suggested change to CMakeModules/OsgMacroUtils.cmake works just
fine, both dynamic and static builds work, with both libs and plugins
compiling as static when requested.
osgviewer tells me that it can't find plugins or
windowsysteminterface, but hey you've been there before.
So how did you go about fixing these?
Robert.
On 5/23/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Manu,
On 5/23/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
And changing this 'MODULE' variable tout STATIC leads to the construction
of static plugin libs ! bingo !
I guess someone should include somewhere the test done for the core libs to
decide here if we should have SHARED or STATIC... what was this 'MODULE'
used for in fact ??
The plugin macro in OpenSceneGraph/CMakeModules/OsgMacroUtils.cmake,
and the macro specifically is:
MACRO(SETUP_PLUGIN PLUGIN_NAME)
...
It should be easy to put a conditional, looking at the compile of core
libs, it looks like it should be possible to use:
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} MODULE ${TARGET_SRC} ${TARGET_H})
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} STATIC ${TARGET_SRC} ${TARGET_H})
ENDIF(DYNAMIC_OPENSCENEGRAPH)
I'll do a clean dynamic build, then try out the static build too.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
