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,
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
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
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
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
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:
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
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]:
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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,
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...
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
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
33 matches
Mail list logo
