Can't build/link core300 sdk example [mingw32 4.4.1 & 5.3.0]

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Can't build/link core300 sdk example [mingw32 4.4.1 & 5.3.0]

Postby LordHexahedron » Wed Sep 07, 2016 3:45 am

alright, so this is a rather interesting one.
if I compile with this line (just the cpp from the core300 example included, with the stdafx crud removed and tmain changed to main then renamed to ex.cpp because I'm building it in place):

g++ -march=core2 -O2 -o build.exe -g -m32 ex.cpp -lNewton

this looks fine on initial inspection, and indeed - it builds... it just doesn't link.
I suspect that the old mingw32 makefile is invalid since it's trying to build a static library (fine by me, but it's not working so... I guess I'll rewrite it to produce a dynamic library)

Code: Select all
C:\Users\Thunder\AppData\Local\Temp\cciN2ILZ.o: In function `Z18CreateFreeFallBallP11NewtonWorld':
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:53: undefined reference to `_imp__NewtonCreateSphere'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:56: undefined reference to `dGetIdentityMatrix()'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:58: undefined reference to `_imp__NewtonCreateDynamicBody'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:61: undefined reference to `_imp__NewtonBodySetForceAndTorqueCallback'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:65: undefined reference to `_imp__NewtonBodySetMassProperties'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:68: undefined reference to `_imp__NewtonBodySetLinearDamping'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:71: undefined reference to `_imp__NewtonDestroyCollision'
C:\Users\Thunder\AppData\Local\Temp\cciN2ILZ.o: In function `ApplyGravity':
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:45: undefined reference to `_imp__NewtonBodyGetMassMatrix'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:47: undefined reference to `_imp__NewtonBodySetForce'
C:\Users\Thunder\AppData\Local\Temp\cciN2ILZ.o: In function `Z20CreateBackgroundBodyP11NewtonWorld':
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:17: undefined reference to `_imp__NewtonCreateTreeCollision'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:20: undefined reference to `_imp__NewtonTreeCollisionBeginBuild'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:23: undefined reference to `_imp__NewtonTreeCollisionAddFace'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:26: undefined reference to `_imp__NewtonTreeCollisionEndBuild'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:29: undefined reference to `dGetIdentityMatrix()'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:30: undefined reference to `_imp__NewtonCreateDynamicBody'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:33: undefined reference to `_imp__NewtonDestroyCollision'
C:\Users\Thunder\AppData\Local\Temp\cciN2ILZ.o: In function `main':
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:79: undefined reference to `_imp__NewtonCreate'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:86: undefined reference to `_imp__NewtonInvalidateCache'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:90: undefined reference to `_imp__NewtonUpdate'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:93: undefined reference to `_imp__NewtonBodyGetMatrix'
C:\Users\Thunder\Documents\projects\libproto framework\src/ex.cpp:98: undefined reference to `_imp__NewtonDestroy'
collect2: ld returned 1 exit status


so fair enough I think, perhaps my build environment is insane.

so I write up a quick hello world example

Code: Select all
#include <iostream>
using namespace std;

int main()
{
    cout << "Hello World" << endl;
    return 0;
}


and I build that using
g++ -o hello_world.exe hello_world.cpp

lo and behold, it works - perhaps my linker is insane but I can link to irrlicht just fine so I doubt it, rather I suspect the makefile is to blame here which I shall debug asap.

Thus I turn to here to see if any of you could possibly have any suggestions.

cpp.exe (TDM-2 mingw32) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


also tested using vanilla mingw32 5.3.0, same result.

g++.exe (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
LordHexahedron
 
Posts: 11
Joined: Sat Sep 03, 2016 10:05 pm

Re: Can't build/link core300 sdk example [mingw32 4.4.1 & 5.

Postby LordHexahedron » Wed Sep 21, 2016 11:57 pm

I feel I should mention that the solution I came to is that my installations of mingw somehow all ended up being broken, even post reinstall - thus my conclusion is that mingw is currently broken.

this is after repeatedly failing to compile even the most trivial of projects using std=c++11, this implies an insane build environment.
For sake of expedience I'm just using MSVC for my windows builds instead, as much as I hate to admit it - it's at least not entirely broken.
LordHexahedron
 
Posts: 11
Joined: Sat Sep 03, 2016 10:05 pm

Re: Can't build/link core300 sdk example [mingw32 4.4.1 & 5.

Postby XycsoscyX » Thu Sep 22, 2016 2:42 pm

Started to reply, then noticed the other post that I responded to was you switching to MSVC after this.

Just for the sake of anyone viewing this thread later, the issue seems to be that you're building a static library, but not defining _NEWTON_STATIC_LIB before including any Newton headers in your own project. The static build of Newton exports different function names than the DLL build. If you're building the static library, it sets the _NEWTON_STATIC_LIB define in the Newton build, so you need to match that define in your own build when including. This takes care of the macro magic needed to use the extern Newton calls instead of the import ones.
XycsoscyX
 
Posts: 12
Joined: Wed Dec 15, 2004 2:46 am
Location: WA, USA

Re: Can't build/link core300 sdk example [mingw32 4.4.1 & 5.

Postby LordHexahedron » Thu Sep 22, 2016 3:36 pm

XycsoscyX wrote:Started to reply, then noticed the other post that I responded to was you switching to MSVC after this.

Just for the sake of anyone viewing this thread later, the issue seems to be that you're building a static library, but not defining _NEWTON_STATIC_LIB before including any Newton headers in your own project. The static build of Newton exports different function names than the DLL build. If you're building the static library, it sets the _NEWTON_STATIC_LIB define in the Newton build, so you need to match that define in your own build when including. This takes care of the macro magic needed to use the extern Newton calls instead of the import ones.


Right, that would presumably work for MSVC as well - figured it was something simple but I couldn't find it.
More importantly, the c++11 problems with mingw would've caused me to switch eventually anyway.

As for different function names: there's probably a reason but I design my APIs to export the same symbols using aforementioned macro magic, it may be ugly but it makes the library far simpler to use.
LordHexahedron
 
Posts: 11
Joined: Sat Sep 03, 2016 10:05 pm

Re: Can't build/link core300 sdk example [mingw32 4.4.1 & 5.

Postby XycsoscyX » Thu Sep 22, 2016 4:24 pm

Snippet from MSDN: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx

[quote]dllexport of a function exposes the function with its decorated name. For C++ functions, this includes name mangling. For C functions or functions that are declared as extern "C", this includes platform-specific decoration that's based on the calling convention. For information on name decoration in C/C++ code, see Decorated Names. No name decoration is applied to exported C functions or C++ extern "C" functions using the __cdecl calling convention.[/quote]

It's not the SDK/API that's doing the export name change, it's compiler/linker. In fact, nothing actually gets exported for a static library since it's all just a library of compiled data ready to be linked in as needed. No name mangling happens there since it's all just an index in the library. Name mangling and decorators when exporting to a DLL happens entirely for platform reasons, and is different on different platforms (and even on different compilers I assume?).
XycsoscyX
 
Posts: 12
Joined: Wed Dec 15, 2004 2:46 am
Location: WA, USA

Re: Can't build/link core300 sdk example [mingw32 4.4.1 & 5.

Postby LordHexahedron » Thu Sep 22, 2016 8:20 pm

yes, but extern "C" on a compliant platform implies C linkage, this does not involve mangling and allows exporting the same symbols to both static and dynamic, mind. C linkage doesn't really work too well for some C++ constructs and sometimes you need function overloading so. ech.
LordHexahedron
 
Posts: 11
Joined: Sat Sep 03, 2016 10:05 pm


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 14 guests

cron