What's new

Glide64 vs GCC. Need help

Gonetz

Plugin Developer (GlideN64)
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.
 
Last edited:

Slougi

New member
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

New member
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

New member
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.
 
H

h4tred

Guest
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
 
OP
Gonetz

Gonetz

Plugin Developer (GlideN64)
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.
 
OP
Gonetz

Gonetz

Plugin Developer (GlideN64)
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

Emulator Developer
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

New member
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.
 
Last edited:
H

h4tred

Guest
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.
 
OP
Gonetz

Gonetz

Plugin Developer (GlideN64)
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.
Actually "Bloodshed Dev-C++ is a full-featured Integrated Development Environment (IDE) for the C/C++ programming language. It uses Mingw port of GCC (GNU Compiler Collection) as its compiler." There is distributive of Dev-C++ version 4.9.9.2, without Mingw compiler system, which I use.

The problem is not because of compiler version. Actually, GCC version is working. Crash is because of wxWidgets library, which I use for system-dependent stuff. Functions, which do not use wxWidgets objects, work ok.
Check this for details:
http://wxforum.shadonet.com/viewtopic.php?t=23766
 
OP
Gonetz

Gonetz

Plugin Developer (GlideN64)
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.
I downloaded and installed this package along with Code::Blocks, thanks!
I rebuilt everything with newer version.
Nothing changed, as expected.
 
OP
Gonetz

Gonetz

Plugin Developer (GlideN64)
I solved the problem (mostly). DLLMain must be declared as "C" function to be called by MinGW. Stupid rake.
Now GCC build works with 1964 and Mupen64. Pj64 crashes though.
Anyway, Glide64 sources are GCC ready and can be ported to other platforms.
 
H

h4tred

Guest
Just a notice.

Gonetz and I are working more on porting the wrapper to Unix.

I recently started work on porting the VRAM detection to SDL for Mac/Linux. Though, there is the issue with the wrapper specific extension used for Windows configuration of it.

Just wondering with the source of Mupen64Plus to clarify, how did the Linux port work around that issue?
 
OP
Gonetz

Gonetz

Plugin Developer (GlideN64)
I've an issue with Linux port.
When I run Mupen64Plus, it says
"Couldn't load plugin 'Glide64.so': /home/lipski/Mupen64Plus-1-5-bin-32/plugins/Glide64.so: undefined symbol: DetectSIMD"

DetectSIMD is an asm function, which is in 3dmathSIMD.asm, compiled with "nasm -f elf".
Any ideas, what can cause this? I use the following makefile:

.PHONY: all clean realclean

DLLNAME = Glide64.so

EXT_INC = ./inc
EXT_LIB = ./lib

CC = g++
STRIP = strip
CFLAGS = -DBUILDING_DLL=1 -fexceptions -D__unix__
CFLAGS += -ffast-math -funroll-loops
CFLAGS += -I. -I$(EXT_INC) `wx-config --cppflags`

ifdef DEBUG
CFLAGS += -DDEBUG
endif

LD = g++
LDFLAGS = -shared -lstdc++

LDLIBS = -L"." -L"lib" $(EXT_LIB)/3dmathSIMD.o $(EXT_LIB)/FixedPoint.o $(EXT_LIB)/Texture.o $(EXT_LIB)/glide3x.so `wx-config --libs`

RM = rm

SOURCES = \
3dmath.cpp \
Combine.cpp \
Config.cpp \
CRC.cpp \
Debugger.cpp \
DepthBufferRender.cpp \
Ext_TxFilter.cpp \
FBtoScreen.cpp \
Main.cpp \
rdp.cpp \
TexBuffer.cpp \
TexCache.cpp \
Util.cpp

OBJECTS = $(SOURCES:.cpp=.o)

.cpp.o:
$(CC) -o $@ $(CFLAGS) -c $<

all: $(DLLNAME)

$(DLLNAME): $(OBJECTS)
$(LD) -o $@ $(LDFLAGS) $^ $(LDLIBS)
#$(STRIP) -R .comment $@

clean:
-$(RM) *.o

realclean: clean
-$(RM) $(DLLNAME)

-include depend
 
Last edited:

Richard42

Emulator Developer
I've an issue with Linux port.
When I run Mupen64Plus, it says
"Couldn't load plugin 'Glide64.so': /home/lipski/Mupen64Plus-1-5-bin-32/plugins/Glide64.so: undefined symbol: DetectSIMD"

DetectSIMD is an asm function, which is in 3dmathSIMD.asm, compiled with "nasm -f elf".
Any ideas, what can cause this? I use the following makefile:

One possible cause for this type of problems is that Win32 and Unix have different conventions for C function naming. Windows uses a preceding underscore, while Linux does not. So you need a macro in your .asm file to correctly define the function names, depending upon the target OS. The functions also need to be declared global in the ASM file, but that's true for both Win and Linux.
 
OP
Gonetz

Gonetz

Plugin Developer (GlideN64)
Yes, the problem was caused by a preceding underscore. Thanks!
Now the plugin is attempting to load.
 

Top