Daniel Olivier wrote:
The Wiki page on this issue
(http://www.openscenegraph.org/index.php?page=Tasks.Win32StaticLink) boldly
states to query the community for information regarding new instructions as
to how to get this to work.
Generally, these instructions have worked pretty well. How are they not up
to date (other than some of the stuff appears to have built into the new
"static" project configurations)?
We would all appreciate any edits to bring these instructions up to date. The Wiki edit
password is 'osg'. Make it so!
The size of the resulting exe is much smaller than I expected ($$$!).
Isn't THAT a nice benefit? ;)
Having generated the all the static versions of all the OSG libraries and
plugins (*_s.lib), linking them into a final application is NOT as
straightforward as inserting a few initialization calls into the 'main'
function of an application. I followed the instructions on the Wiki, which
led me to this (mangled symbols extracted with dumpbin /linkermember:1 $i |
grep the_symbol):
Did the wiki suggest init calls in main()? I have always used the dumpbin mangled names
technique. You can either #pragma linker them, or add them to the IDE's linker settings,
both are equivalent.
#if defined(OSG_LIBRARY_STATIC)
#pragma comment(linker,
"/include:?g_IVEReaderWriterProxy@@[EMAIL PROTECTED]
riter@@@osgDB@@A")
#pragma comment(linker,
"/include:?g_readerWriter_RGB_Proxy@@[EMAIL PROTECTED]
iterRGB@@@osgDB@@A")
That looks like I expect it to.
// I'm not sure this is wise (preferable to putting it on the link line)
#if defined(_DEBUG)
#pragma comment(lib, "osgdb_fltd_s.lib")
#else
#pragma comment(lib, "osgdb_flt_s.lib")
#endif
I put it on the linker command line, but the difference is academic.
#pragma comment(linker,
"/include:?g_fltReaderWriterProxy@@[EMAIL PROTECTED]
[EMAIL PROTECTED]@@@osgDB@@A")
#pragma comment(linker,
"/include:?g_readerWriter_ATTR_Proxy@@[EMAIL PROTECTED]
riterATTR@@@osgDB@@A")
Those look about right.
// ...
// ... ~60 symbols here
// ...
#endif
I had to enumerate (force) the symbol for each record type in the FLT
plugin. Surely there must be a better way, either for the FLT plugin or for
any other.
For each record type? I don't use the FLT loader, so I'm not familiar with this. Does
each FLT record type have a unique ReaderWriter then?
Furthermore, I couldn't link-in the freetype plugin, in light of the fact
that freetype219(_D).lib (that it links with) is compiled with /MD(d), which
leads to unresolved externals. This point is addressed in step #1 on the
Wiki.
Is there any alternative to regenerating the dependency (freetype in this
instance) with /MT(d)? (as in redirecting/renaming symbols through arcane
instructions to the linker?) I just don't want to recompile freetype or
worse, double the number of dependency files such as:
- freetype219.lib, freetype219_D.lib, freetype219_D_s.lib, freetype219_s.lib
- gdal, static & dynamic x release & debug, ...
- glut, ...
- libpng, ...
- libtiff, ...
- libungif, ...
- zlib, ...
I rebuilt EVERY library myself. This is because I needed to ensure they were built with
the compiler I use (VC++2005) and that they are built with the proper runtime library
configuration. Unavoidable, I suspect.
Dan
--
Chris 'Xenon' Hanson aka Eric Hammil | http://www.3DNature.com/ eric at logrus
"I set the wheels in motion, turn up all the machines, activate the programs,
and run behind the scenes. I set the clouds in motion, turn up light and
sound,
activate the window, and watch the world go 'round." -Prime Mover, Rush.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
