Buiding a windows DLL using tdm-MinGW

[Julio Jerez]

Guy I download teh MinWG and I manage to convet teh Linux Make to oen foe window
It managed to buidl the Library and the DLL, but ther si still something wrong

Here is the Rule I am usin to build the DLL, and it works

Newton.dll : $(DG_OBJ_FILES)
dlltool -e $(DG_NEWTON_PATH)Newton.o -l Newton.lib $(DG_NEWTON_PATH)Newton.o
gcc $? C:/MinGW/lib/gcc/mingw32/4.4.1/libstdc++.a -o Newton.dll
copy Newton.lib C:\Newton_200\NewtonSDK\sdk\MinWG\Newton.lib
copy Newton.dll C:\Newton_200\NewtonSDK\sdk\MinWG\Newton.dll

However It does not create the export funtions when I try to use it I get these link errors

Error 1 error LNK2001: unresolved external symbol __imp__NewtonUserJointAddLinearRow Custom6DOF.obj JointLibrary
Error 2 error LNK2001: unresolved external symbol __imp__NewtonUserJointSetRowStiffness Custom6DOF.obj JointLibrary
Error 3 error LNK2001: unresolved external symbol __imp__NewtonUserJointSetRowMaximumFriction Custom6DOF.obj JointLibrary
Error 4 error LNK2001: unresolved external symbol __imp__NewtonUserJointSetRowMinimumFriction Custom6DOF.obj JointLibrary
Error 5 error LNK2001: unresolved external symbol __imp__NewtonUserJointAddAngularRow Custom6DOF.obj JointLibrary
Error 6 error LNK2001: unresolved external symbol __imp__NewtonBodyGetCentreOfMass CustomBasicRayCastCar.obj JointLibrary
Error 7 error LNK2001: unresolved external symbol __imp__NewtonBodyGetMassMatrix CustomBasicRayCastCar.obj JointLibrary
....
...

do anyone know what I need to do to make export the correl lib file?

[thedmd]

Well, in VS is a declaration specifier __declspec(dllexport) which probably is used by you. I'm not sure, but not all versions of GCC can interpret this correctly. Maybe you shold use __attribute__((dllexport)) instead of above?

This article may help: http://gcc.gnu.org/wiki/Visibility

[Julio Jerez]

Ok I think I figure out what is wrong, the comand dlltool build teh DLL an dteh LIB but it apperas that it need to have a .def file to export the import funtions of eth DLL.

I changed the dlltool to using dllwrap, and this works fine, tshi si my make rule now.

Newton.dll : $(DG_OBJ_FILES)
# dlltool -e $(DG_NEWTON_PATH)Newton.o -l Newton.lib $(DG_NEWTON_PATH)Newton.o
# gcc $? C:/MinGW/lib/gcc/mingw32/4.4.1/libstdc++.a -o Newton.dll
dllwrap --driver-name=gcc $? C:/MinGW/lib/gcc/mingw32/4.4.1/libstdc++.a -o Newton.dll --def Newton.def --output-lib newton.lib
copy Newton.lib C:\Newton_200\NewtonSDK\sdk\MinWG\Newton.lib
copy Newton.dll C:\Newton_200\NewtonSDK\sdk\MinWG\Newton.dll
copy Newton.lib C:\Newton_200\NewtonSDK\sdk\x32\dll_vs9\Newton.lib
copy Newton.dll C:\Newton_200\NewtonSDK\samples\bin\X32\Newton.dll

how ever I still have a problem I need to make a DEF file by hand, the format is like this:

LIBRARY Newton.dll
EXPORTS
NewtonCreate
NewtonDestroy

but that is very error prompt and time consuming, there have to be a command that can list the functions from an object file, do you know which one form GCC Tools?

[Julio Jerez]

never mind I found the command, it is called nm

[Julio Jerez]

Now I was ably to build teh DLL and the Library and the SDK demos buidl and link to the new Library,
But the moment I call any funtion form teh dll, I have a very bad crash, I do not know why,
I see If I can buidl it with debug info that can be used from Visual Studio. If that is not possible I do not know how to debug GCC dll from Visual Studio.

[Julio Jerez]

No the dll is still wong because I see all of teh entry point incoddect
for example this is the debug of some funtion

Code: Select all

   NewtonWorld* world = NewtonCreate(0, 0);
0042A849  push        0   
0042A84B  push        0   
0042A84D  call        dword ptr ds:[400000h]
0042A853  add         esp,8
0042A856  mov         dword ptr [world],eax
   NewtonSetPlatformArchitecture(world, 2);
0042A859  push        2   
0042A85B  mov         eax,dword ptr [world]
0042A85E  push        eax 
0042A85F  call        dword ptr ds:[400000h]
0042A865  add         esp,8
 

as you can see all of the function refrrence are dword ptr ds:[400000h]
and that points to a NULL adress in memory.
There has to be something else I need to do.
has anyone used a DLL produced by MinGW with visual studio?

one thing I noticed in that in Visual studion a DLL can be initilize in two different ways,
one is by link the .lib and the function DLLMain is called automatically
the other is by explicity loading the library.
But the MinGW library do not have DLLMain function, instead they have this code

Code: Select all

#ifdef _NEWTON_BUILD_DLL
   #if (defined (_MINGW_32_VER) || defined (_MINGW_64_VER))
      int main(int argc, char* argv[])
      {
         return 0;
      }
   #else
      BOOL APIENTRY DllMain (HANDLE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved)
      {
         return TRUE;
      }
   #endif
#endif

Do dll in GCC have to be explictly load it?
I do no kwnpo what is wrong here now. But my guess is that teh DLL is no loaded by the startup code.
has anyone had this problem with DLLs in MinGW?


when I use the DLL generated by VS the code looks like this

NewtonWorld* world = NewtonCreate(0, 0);
0042A849 push 0
0042A84B push 0
0042A84D call dword ptr [__imp__NewtonCreate (4654ACh)]
0042A853 add esp,8
0042A856 mov dword ptr [world],eax
NewtonSetPlatformArchitecture(world, 2);
0042A859 push 2
0042A85B mov eax,dword ptr [world]
0042A85E push eax
0042A85F call dword ptr [__imp__NewtonSetPlatformArchitecture (4654B0h)]
0042A865 add esp,8

I am at lost here. I do not know what is wrong. I hope that MinGW dll can be use with VS projects.

[agi_shi]

Since I believe the Linux SDK has a static library, could you perhaps simply provide a static library for windows, too? That should at least avoid the DLL trouble for now.

[Svenstaro]

Does the MinGW-produced DLL work with MinGW compiled projects? Testing this would allow for testing if the DLL itself is faulty or if there's a problem between MinGW and MSVS.

[thedmd]

As far as I know *.lib files produced by GCC are differ from those produced by VS and cannot be statically linked to another project in VS. It is always possible to use dynamic lodading but it is not a point.
GCC usually output *.a files and you explictly renamed this to *.lib.

There should be tools which allows to convert from *.a to *.lib, but I'm not sure. Probably the best way in this case is to generate *.lib file from *.dll exports. I saw such solution in the past, but I cannot remember where exacly.

Edit:
Well, actually it isn't hard. Try to use lib.exe tool from VS:

lib /DEF:newton.def /out:newton.lib /machine:x86

I tried this on NewtonDemos and it works. Of course I don't have complete .def file so I had to generate one. After adding some missing exports everything works great. Since you have .def it should just work.

I think it can be don also for x64 version.

[Julio Jerez]

As far as I know *.lib files produced by GCC are differ from those produced by VS and cannot be statically linked to another project in VS. It is always possible to use dynamic lodading but it is not a point.
GCC usually output *.a files and you explictly renamed this to *.lib.
There should be tools which allows to convert from *.a to *.lib, but I'm not sure. Probably the best way in this case is to generate *.lib file from *.dll exports. I saw such solution in the past, but I cannot remember where exacly.

It is a shame GCC does no generate binaries compatible with VS. It was my impression that this was standard for all compliers, after all the opcode must be the same since it is the same CPU.
Those solutions are too contrived for me.
Anyway I will try the trial Version of the Intel compiler, I own Version 8.1 that I bought back in 2003.
I decided not to use it because it was generation defective code for AMDs CPUs.
When I sad that no boy believe me unto some expert said and the Intel was force to fix it, is the y say, let us see what they have for version 11.
I hear that version 11 is very good, and I have to believe is has to be as good as GCC.
Beside when Larrabee comes out we will need to use Intel compiler anyway.

[thedmd]

It is a shame GCC does no generate binaries compatible with VS. It was my impression that this was standard for all compliers, after all the opcode must be the same since it is the same CPU.

Actually it is very common. I don't now all cases but usually intermediate files between source code and final executable are not protable. I think Intel compiler is not an exception.

Those solutions are too contrived for me.

Soution for this specific problem is very simple in pracise. But mixing compilers usually looks like putting engine from Ferrari into Prius, it just don't fit.

Anyway I will try the trial Version of the Intel compiler, I own Version 8.1 that I bought back in 2003.
<...>
Beside when Larrabee comes out we will need to use Intel compiler anyway.

Oh! So you tested Intel compiler allready. Are the import libraries (*.lib if associated with *.dll) compatibile with those generated by VS?
Larrabee is based on modified P4, so I think there will be alternatives for Intel compiler. Ok, I must admit I don't believe in this much.

[Julio Jerez]

Well I just dowloaded teh Intel compile 11.1 and I buld the dll form visual studio.
and rhe result is not better tah what VS can produce.

The tower Tall scene in the SDK in VS and Intel takes about 12 misecund per frame in 32 bit mode,
In Linux GCC and the MAC with GCC 4.x tehn same scene take abput 5 milisecund.
I have not idea how GCC can produce binaries that are more than twice as fast and VS and Intel compiler.
This is not a Fluke I confirm this many time over already.

[Julio Jerez]

Yes I verified twice already in that Scene
Intel compiler 11 with Maximum optimization take 12 milsescund in VS (32 bit) The evaluation copy do no let me build 64 bit IA
VS 2008 with O2 uptimization take 15 milisececunds in 32 bit mode and 12 milisecnd in 64 bit (x87 mode).
GCC 4.3.1 take 4 to 5 milisecend in Linux (64 Bit) and In can not run Linux in 32 bit mode in this machine.

But there is one point. It appears that Intel compiler will vectorize code even at the lowest set up, and the is not acepatble since it will issue SSE code.
without that Intel is slower than Visual Studio.
Even using the Max optimization option of the Intel compiler SSE4 and Ox that scene it is only marginally better than VS.

Plus it looks like the Intel compiler no longer generate code for x87, it does all with SSE, and this is a show stopper for me.

I cannot believe that no one have made a Visual Studio Plug in using GCC. That should be quite simple but the Open source people keep with this Draconian Mentality that ever thing have to be retrograde

[agi_shi]

Did you try using MinGW to produce a static .a library? That should avoid the DLL trouble, at least until it gets solved.

[Julio Jerez]

I will try that but later, but I do not thonk that will work.
I do no even knwo what is teh command for making a static library,
all I know is the AR command that makes an archive of Object files, how do I turn it into a lib file?