🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
On compiler issues..
I've discovered that one possible reason the non-VC++ compilers are not working is because DLL's can only be loaded if they are built with the same C runtime libraries. This isn't a VC++, Windows, or Microsoft specific problem, either, as apparently it exists on every other platform (i.e. people trying to link SGI C++ with g++)
The only solution I can think of at the moment is for those without VC++ to find a way to link with the VC++ libraries. Of course, I'm not even sure if this would work, and I don't know how possible this is, as I've never used any of those non-VC++ compilers. I thought I would at least give a heads up and a possible direction for people to take in order to resolve the issue.
In the rewrite, I'll look more into COM so it isn't limited to VC++. I didn't want to use it for various reasons, but I may not have a choice.
Since you're going to be compiling all the bots yourself for the contest, you could provide a different gdarena binary compiled with MinGW, for us to use while we develop our bots (possibly to be replaced with a COM implementation of the interface later).
If you don't want to try and get DevC++ and MinGW working yourself, you could give the gdarena source code to someone else and let them compile it - I'm sure there would be plenty of people willing to go through the code to get it to compile properly with MinGW.
This is mainly suggested as a stop-gap solution until a different interface can be set up, or some other fix found.
Edit: Of course, it'll only help if the problem is something to do with incompatible runtime libraries.
John B
[edited by - JohnBSmall on August 3, 2003 12:42:02 AM]
If you don't want to try and get DevC++ and MinGW working yourself, you could give the gdarena source code to someone else and let them compile it - I'm sure there would be plenty of people willing to go through the code to get it to compile properly with MinGW.
This is mainly suggested as a stop-gap solution until a different interface can be set up, or some other fix found.
Edit: Of course, it'll only help if the problem is something to do with incompatible runtime libraries.
John B
[edited by - JohnBSmall on August 3, 2003 12:42:02 AM]
I don''t know. . . the only standard library function it uses is strcmp, and it gets past that. . . and I used std::fstream to log stuff, and that worked too.
The only reason the C runtime libraries are an issue is because you are declaring classes across the DLL boundary. If you stick with a plain old C interface with stdcall calling convention, then almost every language under the sun on Windows can participate. Forget COM. There's no need to go there.
Edit: Another potential reason for the incompatibility with non-VC++ compilers is that the classes have virtual functions. VC++ puts the pointer to the vtable at the start of the class, whereas other compilers may put the pointer to the vtable at the end of the class. Yet another reason not to use classes across DLL boundaries.
[edited by - sly on August 4, 2003 7:31:26 AM]
Edit: Another potential reason for the incompatibility with non-VC++ compilers is that the classes have virtual functions. VC++ puts the pointer to the vtable at the start of the class, whereas other compilers may put the pointer to the vtable at the end of the class. Yet another reason not to use classes across DLL boundaries.
[edited by - sly on August 4, 2003 7:31:26 AM]
Has anyone using MingW tried this: http://www.mingw.org/mingwfaq.shtml#faq-msvcdll.
I imagine you'd be primarily interested in the first part, as that deals with creating DLL's that are called by executables built with VC++.. which is exactly what we have here. I don't know if this would work or not, but it's worth trying if it hasn't already.
quote:
How can an MSVC program call a MinGW DLL, and vice versa?
Assume we have a testdll.h, testdll.c, and testmain.c. In the first case, we will compile testdll.c with MinGW, and let the MSVC-compiled testmain call it. You should use
gcc -shared -o testdll.dll testdll.c -Wl,--output-def,testdll.def,--out-implib,libtestdll.a
to produce the DLL and DEF files. MSVC cannot use the MinGW library, but since you have already the DEF file you may easily produce one by the Microsoft LIB tool:
lib /machine:i386 /def:testdll.def
Once you have testdll.lib, it is trivial to produce the executable with MSVC:
cl testmain.c testdll.lib
Now for MinGW programs calling an MSVC DLL. We have two methods. One way is to specify the LIB files directly on the command line after the main program. For example, after
cl /LD testdll.c
use
gcc -o testmain testmain.c testdll.lib
The other way is to produce the .a files for GCC. For __cdecl functions (in most cases), it is simple: you only need to apply the reimp tool from Anders Norlander (since his web site is no longer available, you may choose to download here a version enhanced by Jose Fonseca):
reimp testdll.lib
gcc -o testmain testmain.c -L. -ltestdll
However, for __stdcall functions, the above method does not work. For MSVC will prefix an underscore to __stdcall functions while MinGW will not. The right way is to produce the DEF file using the pexports tool included in the mingw-utils package and filter off the first underscore by sed:
pexports testdll.dll | sed "s/^_//" > testdll.def
Then, when using dlltool to produce the import library, add `-U' to the command line:
dlltool -U -d testdll.def -l libtestdll.a
And now, you can proceed in the usual way:
gcc -o testmain testmain.c -L. -ltestdll
Hooray, we got it.
I imagine you'd be primarily interested in the first part, as that deals with creating DLL's that are called by executables built with VC++.. which is exactly what we have here. I don't know if this would work or not, but it's worth trying if it hasn't already.
quote: Original post by Sly
The only reason the C runtime libraries are an issue is because you are declaring classes across the DLL boundary. If you stick with a plain old C interface with stdcall calling convention, then almost every language under the sun on Windows can participate. Forget COM. There''s no need to go there.
Edit: Another potential reason for the incompatibility with non-VC++ compilers is that the classes have virtual functions. VC++ puts the pointer to the vtable at the start of the class, whereas other compilers may put the pointer to the vtable at the end of the class. Yet another reason not to use classes across DLL boundaries.
[edited by - sly on August 4, 2003 7:31:26 AM]
The class is declared, yes, but it is declared as inside the DLL. The DLL interface is standard extern "C" and returns a pointer to the internal bot class. I have reasons for doing this, so if it''s the main problem, then we''ll have to figure out something else for now.
I looked at that FAQ, but I don't see how it helps, since it's talking about linking the DLLs at compile time. If you actually read the relevant section:
John B
[edited by - JohnBSmall on August 4, 2003 11:56:19 AM]
quote: How can an MSVC program call a MinGW DLL , and vice versa?
Assume we have a testdll.h, testdll.c, and testmain.c. In the first case, we will compile testdll.c with MinGW, and let the MSVC-compiled testmain call it. You should use
gcc -shared -o testdll.dll testdll.c -Wl,--output-def,testdll.def,--out-implib,libtestdll.a
to produce the DLL and DEF files. MSVC cannot use the MinGW library, but since you have already the DEF file you may easily produce one by the Microsoft LIB tool:
lib /machine:i386 /def:testdll.def
Once you have testdll.lib, it is trivial to produce the executable with MSVC:
cl testmain.c testdll.lib
John B
[edited by - JohnBSmall on August 4, 2003 11:56:19 AM]
quote: Original post by JohnBSmall
I looked at that FAQ, but I don''t see how it helps, since it''s talking about linking the DLLs at compile time. If you actually read the relevant section:quote: How can an MSVC program call a MinGW DLL , and vice versa?
Assume we have a testdll.h, testdll.c, and testmain.c. In the first case, we will compile testdll.c with MinGW, and let the MSVC-compiled testmain call it. You should use
gcc -shared -o testdll.dll testdll.c -Wl,--output-def,testdll.def,--out-implib,libtestdll.a
to produce the DLL and DEF files. MSVC cannot use the MinGW library, but since you have already the DEF file you may easily produce one by the Microsoft LIB tool:
lib /machine:i386 /def:testdll.def
Once you have testdll.lib, it is trivial to produce the executable with MSVC :
cl testmain.c testdll.lib
John B
[edited by - JohnBSmall on August 4, 2003 11:56:19 AM]
Yeah, makes sense. That certainly defeats the purpose of a DLL.
quote: Original post by Khawk
Yeah, makes sense. That certainly defeats the purpose of a DLL.
Not really. A lot of fairly large libraries are provided as DLLs to be linked at compile time (SDL for example). This means that applications that use the library don't need to have that large block of machine code, and instead just link to the DLL, so file sizes are smaller, and you don't have to have a copy in every application that uses it. It also means in some cases that you can update the DLL, or swap it for a different version without having to individually update every application that uses the library. If you look in the C:\WINDOWS folder, you'll find a large number of DLLs, many of which are only ever linked to at compile time.
John B
[edited by - JohnBSmall on August 4, 2003 12:26:37 PM]
quote: Original post by JohnBSmallquote: Original post by Khawk
Yeah, makes sense. That certainly defeats the purpose of a DLL.
Not really. A lot of fairly large libraries are provided as DLLs to be linked at compile time (SDL for example). This means that applications that use the library don''t need to have that large block of machine code, and instead just link to the DLL, so file sizes are smaller, and you don''t have to have a copy in every application that uses it. It also means in some cases that you can update the DLL, or swap it for a different version without having to individually update every application that uses the library. If you look in the C:\WINDOWS folder, you''ll find a large number of DLLs, many of which are only ever linked to at compile time.
John B
[edited by - JohnBSmall on August 4, 2003 12:26:37 PM]
Right, but everyone loses out when working in the context of this type of plug-in application.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
