Hello Andreas,
Andreas Halm wrote:
>>> But did anybody ever try this? My FC-derived classes are in a Lib
>> which is
>>> then statically linked to the app, but the OpenSG DLLs are
>> dynamically
>>> linked.
>> not sure, I've not tried to build static libs before. Is it necessary
>> that you go this route?+
>
> It is the easiest way, as multiple apps use the same data structures you
> usually put the common stuff in a library ;-)
sure, but does it have to be a *static* lib instead of a dynamic one?
>>> I don't quite understand why the error message says something about
>>> missing dllimport, that just doesn't make sense.
>> oh, wait, sorry for not picking up on this earlier: the class
>> annotations are set up so that they are either __declspec(dllexport) or
>> __declspec(dllimport) depending on whether OSG_COMPILE<LIBNAME>LIB is
>> defined or not.
>> You probably have a OSGMyLibDef.h file that defines a
>> OSG_MYLIB_DLLMAPPING macro? I guess it should be defined to nothing if
>> you are going to build a static MyLib.lib then?
>
> Yes I do have that macro defined as empty, I think I got that from the cubes
> example or so. On a side note (and I don't think this is related), the
> compiler keeps generating an import library for my application, which
> doesn't make much sense but it shows that some stuff is created with
> dllexport when it shouldn't have any dll-related decorations.
hm, if you use the OpenSG build machinery it may well pass options to
the compiler/linker that instruct it to generate a dynamic lib - not
sure about this though, I've never really thought about static libs...
[SNIP]
>>> OSG_BEGIN_NAMESPACE
>>> OSG_INSTANTIATE_PTR(Type1)
>>> OSG_END_NAMESPACE
>> ok, but wasn't the original error about
>> OSG::PointerMFieldBase::operator[] ?
>
> That was more like a blind shot as I really have no idea how all the base &
> management classes are connected, and I saw a connection between
> PointerMFieldBase, MTRefCountPtr and the *multi* specifier in my fcd.
the fields that store pointers are separate from those that store
"regular" values, because for pointers the field is actually responsible
for maintaining the ref count (allows the field to store just a plain C
pointer, but act as if it stored smart pointer). PointerMFieldBase is a
class in that small hierarchy of pointer field types.
If you don't have good reasons against it I'd recommend trying to build
a dynamic lib, since that is what all the other OpenSG libs end up
being, it should work much better.
Cheers,
Carsten
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
