Glide64 vs GCC. Need help

[Gonetz]

I'm trying to build new version of Glide64 with GCC.

Tools:
NASM
MinGW
Dev-C++

Problem:
Resulted dll does not work.

Symptoms:
When project type is 'Win32 DLL', emulators just don't see the plugin.
When I set project type as 'Win32 Console', set Linker parameters '-shared' and rename result from *.exe to *.dll, resulted dll is initialized by emulators, but actual call of any function causes crash.
Stripping Glide64.dll with strip.exe does not help.

Can anybody create for me Dev-C++ project for Mupen64Plus version of Glide64? I need to know, which options are actually needed to build N64 video plugin for windows emulators with GCC. I'm not familiar with GCC and makefile format, but with Dev-C++ I can see in which direction to dig.

Another question: which NASM output format to use with GCC for windows? For MSVS I use '-f win32', the result works with GCC too, but it's probably better to use another format? Elf does not work.

[Slougi]

I suspect that WIN32 DLL is the right type. Are you sure you are marking your DLL entry functions (those defined in the gfx spec) correctly for export/import? The syntax between GCC and MSVC is different, see here. Look for dllimport/dllexport.

Note: I am not intimately familiar with the whole windows linking system (it is weird viewed from a unix perspective).

[Slougi]

Another question: which NASM output format to use with GCC for windows? For MSVS I use '-f win32', the result works with GCC too, but it's probably better to use another format? Elf does not work.

I strongly suspect you want -f win32 regardless of the compiler.

[Pyromanik]

I recommend diging through the (vanilla) Mupen64 v0.5 source, specifically at the RSP plugin to see how it compiles using Dev-C++.
Here you can see all the entry points for opening the DLL and you can also inspect how it is set up within the environment.

Also be aware that the GCC version bundled in with Dev-C++ is somewhat old and deprecated. This may be giving you issues.

[h4tred]

And Gonetz, if you want a more updated GCC:

http://www.tdragon.net/recentgcc/


Thats what I use. Much better than the trash in Dev-C++.

Plus, Dev-C++ is outdated, you could try Code::Blocks. That supports loading Dev-C++ projects too.
--mudlord

[Gonetz]

I recommend diging through the (vanilla) Mupen64 v0.5 source, specifically at the RSP plugin to see how it compiles using Dev-C++.
Here you can see all the entry points for opening the DLL and you can also inspect how it is set up within the environment.

I'll try it, thanks

Also be aware that the GCC version bundled in with Dev-C++ is somewhat old and deprecated. This may be giving you issues.

Dev-C++ is just is a wrapper over MinGW binaries, and MinGW GCC in particular. Since my MinGW version is not very old, GCC should be quite fresh too.

[Gonetz]

I suspect that WIN32 DLL is the right type. Are you sure you are marking your DLL entry functions (those defined in the gfx spec) correctly for export/import? The syntax between GCC and MSVC is different, see here. Look for dllimport/dllexport.

dll export is defined as
#define EXPORT __declspec(dllexport)

The document you pointed says:
"dllexport:
...
You can use __declspec(dllexport) as a synonym for __attribute__ ((dllexport)) for compatibility with other compilers."

Thus, there should be no problems.

I tried to check my dll with Dependency Walker. This tool shows all exported functions - all are there. But emulators can't call them.

[Richard42]

I tried to check my dll with Dependency Walker. This tool shows all exported functions - all are there. But emulators can't call them.

One likely cause for this problem is that the glide64.dll itself may have dependencies on other libraries (SDL, opengl, etc) which cannot be satisfied at load time. This happens a lot for mupen64plus with our blight input plugin; if a user doesn't have the SDL_ttf package installed (which is a dependency for the blight input plugin), then the plugin won't even show up in the drop-down list.

IIRC, dependency walker should flag any unresolved dependency in red.

[Pyromanik]

Dev-C++ is just is a wrapper over MinGW binaries, and MinGW GCC in particular. Since my MinGW version is not very old, GCC should be quite fresh too.

No, I don't think you understand...

Dev-C++ comes with it's own localized copy of GCC, which it will use even if you have a system wide install. Unless you do some tricky business to tell it otherwise. This is extremely old and very depricated (being that Dev-C++ itself hasn't been updated in about 8 years).

Also the most recent stable ports of GCC by mingw are still in version 3, which in itself is old. To get the mingw gcc version 4 alpha you need to get the manual install file from their sourceforge page.

"GCC Version 4 Testing: gcc-4.3.0-20080502-mingw32-alpha"



But I suggest your problem is probably more with your DLL entry points and environment setup rather than the compiler. Otherwise as Richard said, it's probably a runtime problem rather than compile time.

[h4tred]

Also the most recent stable ports of GCC by mingw are still in version 3, which in itself is old. To get the mingw gcc version 4 alpha you need to get the manual install file from their sourceforge page.

"GCC Version 4 Testing: gcc-4.3.0-20080502-mingw32-alpha"

The site I linked to, is more up to date, and its even maintained by a MinGW dev.....And I had zero problems in using it for development.