Hi Sukender,
I still think that it should work, and the problems you discribe sound
like you have different #defines for the plugin and the main executable,
possibly caused by different include path (or order in the include
path). Possibly different compiler settings (esp. C/C++->Code
Generation->Runtime Library).
To check you could dig up the compler command line from the BuildLog for
the executable and the static lib objects, something like
/O2 /Ob2 /I "X:\osg\3rdparty\include" /I "X:\osg\OpenSceneGraph\include"
/I "X:\osg\vc9\include" /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D
"_SCL_SECURE_NO_WARNINGS" /D "_CRT_SECURE_NO_DEPRECATE" /D
"WIN32_LEAN_AND_MEAN" /D "_WIN32_WINNT=0x0500" /D
"CMAKE_INTDIR=\"Release\"" /D "_MBCS" /FD /EHsc /MD /arch:SSE2
/Fo"osgrc.dir\Release\\" /Fd"X:/osg/osgRC/lib/Release/osgrc.pdb" /W3 /c
/TP /Zm1000 /MP
I suspect there is a difference. If they match the .obj file will be
effectively identical, so the linker should behave identical.
The option to use the .obj files instead of the .lib is avialable in
visual studio if the projects are part of the same solution, in the
property's for the executable:
Configuration Properties->Linker(->General) set
Use Libraray dependencies: Yes
(and make the exe project dependent of the .lib projects and remove the
.lib from Linker->Input Additional Dependencies if this is not already
the configuration)
Use Libraray dependency Inputs: Yes
Laurens.
Sukender wrote:
Hi Laurens,
Many thanks for the examples and the modified readers. I don't have time to
browse it right now but I will soon.
Well, USE_OSGPLUGIN() in Main.cpp causes linker to complain about duplicated
symbols (inline methods in osgDB). I think this is because the compiler can
silently refuse inlining and thus create the methods' code in each .cpp. I
didn't find a way to work around this, except:
- Making OSG static (which is what I don't want, for multiple reasons)
- Directly including reader-writers code into my project (it works as expected)
If you know a way, please tell !
It would be nice to tell CMake to directly include .o/.obj files from a project
into another one at link-time, but I guess it's a bit tricky and non portable...
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
----- "Laurens Voerman" <[email protected]> a écrit :
Hi Sukkender,
if you are linking whith the .lib the USE_OSGPLUGIN() is required. -
Unless your project is set up to silently ignore the lib file and link
the .obj files instead. (can't find the option atm.)
What is the effect of the USE_OSGPLUGIN() in the Main.cpp?
Attached is a reduced version of my project whith all the plugins,
where
our viewer has been replaced by the osgviewer. The cmake files
generate
dynamic link libs (osgdb_dds.dll) and always stuff the plugin into the
final .exe too.
modified dds reader and .mip helper reader are someware in
osg-submissions archive: see the thread "proposing dds mmToSkip
option"
starting on 3 dec 2009. Code is in the attachment.(possibly
updated)
Laurens.
Sukender wrote:
Forgot to mention: under MSVC, I've put /OPT:NOREF to avoid symbols
from being excluded when linking static libs.
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
----- "Sukender" <[email protected]> a écrit :
Hi Laurens, hi all,
Hum, could you give me a hint, please? If I write:
class BBB : public osgDB::ReaderWriter {... blah blah blah ...};
REGISTER_OSGPLUGIN(bbb, BBB)
in "bbb.cpp" (in my main exe), then the "BBB" reader/writer is
constructed and added to the registry when process loads.
However if I put that .cpp in a static lib, which is linked to my
main
exe, then the "BBB" reader/writer is never built (nor added to the
registry).
As far as I know, static libs are roughly a bunch of objects!
Were's
the difference?
And of course, using USE_OSGPLUGIN() doesn't work.
BTW, The feature you're mentioning seems interesting. Is there any
chance you release the code, under a licence or another?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
----- "Laurens Voerman" <[email protected]> a écrit :
Hi Sukender,
my modified dds reader is able to skip reading high res mipmaps
from
the
dds file.
For the version you are using, I am guessing that your link
errors
might
originate in compliling the static plugin lib with
OSG_LIBRARY_STATIC
defined. And/Or linking the plugin with the osg libs.
Mixing debug and release versions will also create confusing link
errors.
Of course the USE_OSGPLUGIN(ext1) must be mirrored by a
REGISTER_OSGPLUGIN(ext1,myReaderWriterExtention1)
Laurens.
Sukender wrote:
Hi Laurens,
This is what I mean. Glad to see it can work! But I have:
- A static lib
- No dllexport stuff
- Two USE_PLUGIN() in the main exe
And I have linker errors.
Any idea?
BTW, what your modified plugin does? I had problems with DDS
(saw
some 3rd-party apps read RGB as BGR and vice-versa).
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
----- "Laurens Voerman" <[email protected]> a écrit :
Hi Sukender,
I'm very confused about Robert's reply, because it's working
fine
for
me. I am using a modified dds reader linked into my app, which
takes
precedence over any osgdb_dds.dll because it registers on
startup.
This
can be done by simply adding the (modified) ReaderWriterDDS.cpp
to
the
project producing the executable, in this version there is no
need
for
USE_PLUGIN() - it will cause a link error.
If you compile the plugin into a static link lib, you need the
USE_PLUGIN() and link to the lib.
This can work because the plugins I am using are not exporting
any
symbols, so there is no __declspec(dllexport) stuff in the way.
Laurens.
Robert Osfield wrote:
Hi Sukender,
On Tue, Apr 6, 2010 at 10:15 AM, Sukender <[email protected]>
wrote:
Hi all,
I found several ressources(*) about static linking but didn't
found
an answer to my question: can I combine "dynamic OSG/OT" +
"dynamic
OSG plugins" + "static custom (= user) plugins"? If yes, how?
I can't see how this would work as it seems to be there would
be
a
conflict between what version of core libraries that the
dynamic
vs
static plugins would need to link to.
If you want dynamic linking then use it everywhere.
Robert.
_______________________________________________
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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
