Buiding a windows DLL using tdm-MinGW

[Julio Jerez]

according to the FAQ minggw is capable of making DLL that are compatible with Visual Studio
http://oldwiki.mingw.org/index.php/sample%20DLL

[Marc]

Oh I just saw you created a thread on its own for this issue. I never created a dll with mingw before, but I used a precompiled dll by someone else who compiled it in mingw in vc. So I think it has to work unless they changed it to not working anymore over the last 2 years - which I doubt.

I don't know exactly what your problem is, but I tried and here is a simple printhello dll code that compiles with mingw and a vs2008 project that uses the created lib/dll: http://www.transmogrifier.de/temp/mingwvcdll.zip But maybe that wasn't even your problem?

In the dll dir, there is the dll.cpp which implements the actual function. Then there is dll.h for later usage in vc. compile.bat compiles the cpp file with c exports to a dll.dll, dll.def and libdll.a file. Then lib - from vc - creates a dll.lib from the dll.def. App links to dll.lib and needs dll.dll in its working dir, so compile also copies dll.dll in the app dir. (I don't know much about makefiles so I made a .cmd ...) I hope that helps.

One thing I don't know how to solve but maybe irrelevant due to newton's c link interface: exporting classes. Names seem to get mangled differently between compilers in c++, so the method from above only seems to work with the extern c around the exports. They don't work for classes because they are c++.

[Svenstaro]

Julio, you can simply put together a static library using the tools you already know. In particular, that would be AR (just as you do on Linux). All we need is a .a, even on Windows, as long as you have compiled it using MinGW. No need to force it to become a .lib.

You can do this:

Code: Select all

ar rc libfoo.a foo1.o foo2.o foo3.o ...
ranlib libfoo.a

Ranlib does some magic to make random access faster. The ar flags only make replace an existing library or in case nothing pre-exists, it will be created.

By the way, MSVS' lack of pluggable compiler options is not the open-source communities fault, I'm sure.

[agi_shi]

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

Julio, this is Microsoft's fault because using MSVC with a different compiler is incredibly hard. Take a look at the open source Code::Blocks, for example - it supports MSVC's compiler as well as GCC and others.

[Marc]

I tried the Intel compiler several years back and they plugged it into msvc. There was a new option in the vs gui which simply let you choose which compiler to use. There are also apis for implementing plugins for the vc ide. I'ld say it's theoretically possible to do a gcc plugin in the vc ide. You'ld need a whole set of new project compile settings though.

Here is the link I posted in the other thread about how to create a vc compatible dll with mingw:
http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs

There is alsow this page about name mangling and why it is like this at all: http://en.wikipedia.org/wiki/Name_mangling Pretty strange though that they don't decide on a standard for name mangling and internal structures for c++ while they seem to have actual done it for plain c.

[Julio Jerez]

Oh I just saw you created a thread on its own for this issue. I never created a dll with mingw before, but I used a precompiled dll by someone else who compiled it in mingw in vc. So I think it has to work unless they changed it to not working anymore over the last 2 years - which I doubt.

I don't know exactly what your problem is, but I tried and here is a simple printhello dll code that compiles with mingw and a vs2008 project that uses the created lib/dll: http://www.transmogrifier.de/temp/mingwvcdll.zip But maybe that wasn't even your problem?

In the dll dir, there is the dll.cpp which implements the actual function. Then there is dll.h for later usage in vc. compile.bat compiles the cpp file with c exports to a dll.dll, dll.def and libdll.a file. Then lib - from vc - creates a dll.lib from the dll.def. App links to dll.lib and needs dll.dll in its working dir, so compile also copies dll.dll in the app dir. (I don't know much about makefiles so I made a .cmd ...) I hope that helps.

One thing I don't know how to solve but maybe irrelevant due to newton's c link interface: exporting classes. Names seem to get mangled differently between compilers in c++, so the method from above only seems to work with the extern c around the exports. They don't work for classes because they are c++.

So This is possible then.
I will chek that project out, if someone did it I must be able to do it too.

[Julio Jerez]

Julio, this is Microsoft's fault because using MSVC with a different compiler is incredibly hard. Take a look at the open source Code::Blocks, for example - it supports MSVC's compiler as well as GCC and others.

Yes but being Hard is not really an excuse, in my opinion.
if you look around there ate lot of free and inexpensive tools that integrate very well with VS.

CUDA, OpenCL, Visual Assist, the Intel compiler.
And those are the one I use, I am sure there are plenty more.
Even thongs like Bison and Flex you can make rules that integrate with visual Studio.
And if you go into the private sector, you have the tool for console development, like the one for the Play station 2 and 3 they integrate GCC, even the first version of Microsoft for the 360 once were using GCC.

Here you have GCC the more widely compiler used in almost every platform you can think off, but the GCC people do not make and integration with Visual Studio because they hate Microsoft.
So much for the Altruisms of the open Source comunity.

All they need to do is add some option to GCC so that it issue object code in the format the Visual Studio used, and for their these object code can the compiler will take care off.

I’d never messed with Visual Studio, but I am positive they must have an SDK for integrating tool to it.
If I was not doing Newton I would take on a task like that, but I am sure the moment I do that there will be a dozen self appointed experts doing it open source.

[Julio Jerez]

Here is the link I posted in the other thread about how to create a vc compatible dll with mingw:
http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs

Awesome tutorial, it worked I build the DLL and I run the demo,
The only problem is that I works with option O0 but I crashes with option O0
Now I need a way to figure out how to debug it.
Maybe ways to add debug symbols to the Executable,
any way the good news is that this is possible.

[Julio Jerez]

I guess there is no way to debug the mingw dll from visual studio

I am adding the option -g or -gcoff but it appears that that options disable optimization because the DLL works with those options but it is extremetly slow. as if is was in debug mode.
Is there a debugger that I can use in window to debug a MinWG dll.

[Julio Jerez]

Well for what I can see teh cra is random whi mena teh DLL is not initlized properlly.
but when in the rere ocation that is runs, it is extremetly slow, aroun 10 time slower than the old VS, it takl about 200 misecudn per frame to render the scene
It is amost like it was buiding a debug build.
well I spent too much time on this I thought it was going to be easier but it is not, since theer is not way to debug the code, I cannot continue.

[Svenstaro]

I believe the reason nobody created a GCC drop-in for MSVS is not as blatant as "hate for Microsoft" and neither is the reason that the open source community hates you. The reason probably is that nobody saw any use for it. Open source is NOT altruism and because of that, people will not create things from the goodness of their hearts just because somebody is in need. People will create things they need or want themselves and quite often, going open source is an afterthought. They realize that going open source might profit them as well.

The most obvious reason anybody would want to use GCC with MSVS at all is because they like the IDE and they have many projects created in that IDE already but they want to either develop cross-platform or utilize GCC's speed.
Now, the most obvious solution to this would not be using MSVS for the compilation itself at all but rather use a cross-platform way of doing so because it makes stuff simpler. Developing a GCC plugin would mean that compilation is still bound to Windows because the MSVS project file isn't really usable outside of MSVS. A better way would be to use either Makefiles (which I personally hate), CMake (which is easy to set up) or SCons (which I didn't really use so far). Making use of a different IDE which accounts for cross-platform usage would be another idea. Speaking of which, I recommend Code::Block which is able to open or at least convert MSVS project files.

Please also realize that your condemnation for the open source community is just as unhelpful as hate for Microsoft or any other large corporation, for that matter. Not everybody who uses/creates open source or Linux is a zealot and, in fact, those who do preach about open source or Linux without a good reason to do so are from my experiences neither very experienced nor very knowledgeable and thus easily ignored. There are good reasons for using alternative software economies and alternative operating systems.
As in the previous thread, I do not mean to offend you and I'm actually writing this because I care for the Newton project. Whether I'm just another crazy zealot or somebody giving advice and whether, if that be the case, you accept that advice is up to you, of course.

For actual on-topic advice then: I recommend you try out Code::Blocks first because it is able to open MSVS files. If you are unwilling to change your IDE for personal reasons, you could always just use C::B to compile your project for MinGW and therefore offer two Windows libraries, on compiled on MSVS and one compiled on C::B using MinGW.
If that is not an option, you should really try to look into CMake which will happily work alongside your current MSVS projects. Alternatively, you can use Makefiles or SCons as the build system. Of course, going with a cross-platform solution would probably make your life easier when compiling for multiple architectures because you only have to maintain one project.

[Svenstaro]

For a debugger, you should probably go here: http://sourceforge.net/projects/mingw/files/ and grab the "GNU Source-Level Debugger".

[thedmd]

So This is possible then. :mrgreen:
I will chek that project out, if someone did it I must be able to do it too.

Yes it is, as I posted on previous page. You probably miss this, becouse I edited my post rather sending a new one. : )

[Marc]

For debuggers that work with gcc's debug info format on windows, there might be a gdb for windows? But that's a lot less comfortable than the vs debugger. Maybe codeblocks has some debugger included in the ide.

I realized that for the dllmain to be called in my micro test project from above, there have to be these surroundings

Code: Select all

#ifdef __cplusplus
extern "C" {
#endif

#ifdef __cplusplus
}
#endif


around dllmain as well.

Can you reproduce you crash effect in some test dll code? I could try to get it working.

[martinsm]

But the MinGW library do not have DLLMain function, instead they have this code

This is not true. MinGW supports DllMain just fine.
And MinGW can use .lib files for dll imports that are build by MSVC without problems.