Fw: [ODE] Unresolved externals...
Sébastien Duval
Sébastien Duval
Fri Jan 17 17:36:02 2003
This is a multi-part message in MIME format.
------=_NextPart_000_0025_01C2BE60.FAE71020
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I guess you guys are trying to compile the DLL. There is a perl script =
that extracts all function names from ode.doc and puts it in =
mscvdefs.def.
It's clever and all, but as you can see, it doesn't work perfectly. For =
example, there is 3 functions(prototypes) in the code that does not have =
an implementation:
dGeomDisable
dGeomEnable
dGeomIsEnabled
This creates unresolved external symbol while compiling the DLL.
There is also functions that are not documented but, used in the tests =
provided with ODE. This creates more unresolved externals at application =
(demo) compile. But, there is no problem when compiled statically, which =
means the built dynamic and static libraries do not have exactly the =
same interface.
I think that the best way to solve this problem is to tag each function =
with a export flag through some type of macro (that support syntaxe for =
both shared object and dll). Anyway, I'll look into it and let you know.
> Hello,
> I downloaded 0.035 and was able to compile it into a lib with BCB5.=20
> However, when I tried to compile a very simple test program, it came =
up
> with a few unresolved externals. The only functions I used were:
> dWorldCreate
> dSimpleSpaceCreate
> dJointGroupCreate
> dWorldSetGravity ...
------=_NextPart_000_0025_01C2BE60.FAE71020
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I guess you guys are trying to compile =
the DLL.=20
</FONT><FONT face=3DArial size=3D2>There is a perl script that extracts =
all function=20
names from ode.doc and puts it in mscvdefs.def.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>It's clever and all, but as you can =
see, it doesn't=20
work perfectly. </FONT><FONT face=3DArial size=3D2>For example, =
there is 3=20
functions(prototypes) in the code that does not have an=20
implementation:</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>dGeomDisable<BR>dGeomEnable</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>dGeomIsEnabled</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This creates unresolved external=20
symbol while compiling the DLL.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>There is also functions that are not =
documented=20
but, used in the tests provided with ODE. This creates more unresolved =
externals=20
at application (demo) compile. But, t</FONT><FONT face=3DArial =
size=3D2>here is no=20
problem when compiled statically, which means the built dynamic and =
static=20
libraries do not have exactly the same interface.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think that the best way to solve this =
problem is=20
to tag each function with a export flag through some type of macro =
(that=20
support syntaxe for both shared object and dll). Anyway, I'll look into =
it and=20
let you know.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>> Hello,<BR>> I downloaded 0.035 and was able to =
compile=20
it into a lib with BCB5. <BR>> However, when I tried to compile a =
very simple=20
test program, it came up<BR>> with a few unresolved externals. =
The only=20
functions I used were:<BR>> dWorldCreate<BR>> =
dSimpleSpaceCreate<BR>>=20
dJointGroupCreate<BR>> dWorldSetGravity ...</DIV></BODY></HTML>
------=_NextPart_000_0025_01C2BE60.FAE71020--