Hi Rasmus,
On Sat, 2004-12-18 at 17:45, Rasmus Agerholm wrote:
> On Thu, 2004-12-16 at 10:05, Andreas Zieringer wrote:
> > Hi Rasmus,
> >
> > did you add the OSG_COMPILEMYLIB define to your compile line? The VS7.0
> > compiler is quite bad you can try to add the missing symbols in a .def
> > file (like OpenSG/Source/System/FieldContainer/lib.def.cl.net.ms_stl.sym)
> > and link this file with -def:bla.def
>
> What exactly are you doing in that file? Telling the linker that the
> symbols are defined elsewhere, so it shouldn't complain about them?
The core idea for Windows dlls is that only the symbols that are
explicitly marked for export are actually exported in the dll, all other
symbols are not visible from the outside and lead to the kinds of errors
you see. Unix is the other way around, by default everything is
exported, but if you really want to you can hide symbols. You have to be
careful about it, as the name resolution is totally different between
Win and Unix,but AFAIK it's possible.
To mark a symbol (or class) for export you have to use the
Windows-specific __declspec(dllexport) specifier. The problem is that to
use the header for using the dll you have to have a
__declspec(dllimport) instead. This leads to the stupid situation that
you have to change the headers between compiling and using the dll. It's
tedious but no a big deal (thanks to the preprocessor), we just define a
OSG_*LIB_DLLMAPPING macro that is either import or export, depending on
whether you compile or use the lib.
The only problem is that the header needs to know whether the lib is
being compiled or used. To do that we use two symbols: OSG_BUILD_DLL and
OSG_COMPILE*LIB. Both of these have to be defined when compiling the
library (not sure why there are two, honestly. Gerrit?). If you use our
build system that happens automatically. If not, you have to make sure
it does.
An additional complication is that the VS.Net compiler has some bugs
concerning __declspec(dllexport). Especially when templates are
involved, sometimes it just ignores it. The Intel compiler does it
right, so it's not a problem in the source, the compiler is just buggy.
For these cases you can explicitly define some symbols as exported,
kinda like telling the linker "these symbols are in the lib, trust me".
That's what the .def files are for. The tedious part is that you have to
put the mangled C++-names into the .def files, which are easiest to get
from the error messages. But it's easy to miss one of them and this only
shows up when an app tries to use the symbol and fails linking.
> I'll try this as soon as I get time (and my hands on a windows
> development box).
If you have access to an Intel compiler, try that, it might just make
the problem go away. Otherwise make sure the two preprocessor symbols
are defined when compiling the lib. Only if that fails, start adding
symbols to the .def files.
Hope it helps
Dirk
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
