•      Sign In
• Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter. Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running! # MinGW compilation problem Old topic! Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic. 10 replies to this topic ### #1DarkRonin Members - Reputation: 616 Like 0Likes Like Posted 16 March 2014 - 09:10 PM Hi Guys, I am just trying my hand at the MinGW compiler, to eventually try making my applications work cross platform. I am just trying to convert one of my medium size projects so it will compile. I have managed to sucessfully convert the required lib's using reimp. But now I am having an issue with the linker. C:\Users\Jason\Desktop\MinDX>g++ main.cpp -o MinDX.exe -static-libgcc -static-li bstdc++ -s main.cpp: In function 'int WinMain(HINSTANCE, HINSTANCE, LPSTR, int)': main.cpp:36:72: warning: passing NULL to non-pointer argument 4 of 'int MessageB oxA(HWND, LPCSTR, LPCSTR, UINT)' [-Wconversion-null] MessageBox(NULL,"Unable to create render window.","Fatal Error!",NULL); ^ C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x49): undefined re ference to Renderer::createWindow(int, int, bool, bool)' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x8e): undefined re ference to Renderer::getDevice()' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x9d): undefined re ference to D3DXCreateLine@8' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x15a): undefined r eference to Renderer::spriteCreate(std::string)' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x1ae): undefined r eference to Renderer::spriteSetX(float, std::string)' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x202): undefined r eference to Renderer::spriteSetY(float, std::string)' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x255): undefined r eference to Renderer::spriteSetSizeX(int, std::string)' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x2a8): undefined r eference to Renderer::spriteSetSizeY(int, std::string)' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x2fb): undefined r eference to Renderer::spriteSetDepth(int, std::string)' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x331): undefined r eference to Renderer::showWindow(bool)' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x3c2): undefined r eference to Renderer::counterUpdate()' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x3cc): undefined r eference to Renderer::renderStart()' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x3d6): undefined r eference to Renderer::renderSpriteQueue()' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x3e0): undefined r eference to Renderer::framerateGetReal()' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x4b7): undefined r eference to Renderer::renderDebugText(int, int, std::string)' C:\Users\Jason\AppData\Local\Temp\ccpvSbJs.o:main.cpp:(.text+0x4d8): undefined r eference to Renderer::renderEnd()' c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\J ason\AppData\Local\Temp\ccpvSbJs.o: bad reloc address 0xf in section .text$_ZN6
SpriteC1Ev[__ZN6SpriteC1Ev]'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link
failed: Invalid operation
collect2.exe: error: ld returned 1 exit status

From what I can tell the compiler can't find my engine.cpp file (my engine.h file references the above functions).

engine.h & engine.cpp are located in the same folder and I know the compiler can see engine.h (called from main.cpp) as this is where I had to fix up my header files.

I am a long time user of MSVC++ and first time user of MinGW 4.6 (or any version for that matter). So, I am probably missing something simple.

Any help would be greatly appreciated.

Sponsor:

### #2Bacterius  Crossbones+   -  Reputation: 9299

Like
1Likes
Like

Posted 16 March 2014 - 09:16 PM

You need to actually pass all your source files. i.e.:

>g++ main.cpp engine.cpp otherfiles.cpp -o MinDX.exe -static-libgcc -static-libstdc++ -s


Otherwise they won't get compiled. The header files can be found because they are included on-demand via #include directives and the current working directory is implicitly searched for header files, but due to the modular nature of object files you usually compile each source file separately and then link them together (which can be done in a single command as given above, but usually you prefer to create a makefile or use an IDE to only recompile source files which changed so that you don't restart the compilation from scratch every single time).

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- Pessimal Algorithms and Simplexity Analysis

### #3DarkRonin  Members   -  Reputation: 616

Like
0Likes
Like

Posted 16 March 2014 - 09:31 PM

You need to actually pass all your source files. i.e.:

>g++ main.cpp engine.cpp otherfiles.cpp -o MinDX.exe -static-libgcc -static-libstdc++ -s
`

Otherwise they won't get compiled. The header files can be found because they are included on-demand via #include directives and the current working directory is implicitly searched for header files, but due to the modular nature of object files you usually compile each source file separately and then link them together (which can be done in a single command as given above, but usually you prefer to create a makefile or use an IDE to only recompile source files which changed so that you don't restart the compilation from scratch every single time).

Ahh, ok. Thanks for that. I'll give that a try now.

I am used to VC++ doing everything. Makes you lazy and not know what is actually going on behind the scenes.

### #4DarkRonin  Members   -  Reputation: 616

Like
0Likes
Like

Posted 16 March 2014 - 10:34 PM

Ok, it is looking good. But, just having troubles linking to the DX libs that I exported with reimp. It says it cant find them.

c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -libd3d9.a
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -libd3dx9.a
collect2.exe: error: ld returned 1 exit status

Ths is my compilation command.

g++ main.cpp engine.cpp sprite.cpp -o MinDX.exe -static-libgcc -static-libstdc++ -LC:\MinGW\DXSDK\lib -libd3d9.a -libd3dx9.a -s

The files are sitting in C:\MinGW\DXSDK\lib

Thanks again for your help.

### #5Bacterius  Crossbones+   -  Reputation: 9299

Like
3Likes
Like

Posted 16 March 2014 - 10:47 PM

I think you want -ld3d9 and -ld3dx9, the "-l" part is actually the command and the "lib" prefix and ".a/.dll/.so" etc.. extension are automatically added. I'm not sure why it's designed that way, probably historical reasons  but yeah you only want to pass "-l" + the name of the library without the "lib" prefix and the extension, the compiler does the rest.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- Pessimal Algorithms and Simplexity Analysis

### #6DarkRonin  Members   -  Reputation: 616

Like
1Likes
Like

Posted 16 March 2014 - 11:47 PM

Thanks Bacterius.

Everything is working great now! Glad you guys know the idiosyncrasies of MinGW. I would never have thought of that.

### #7Bacterius  Crossbones+   -  Reputation: 9299

Like
2Likes
Like

Posted 16 March 2014 - 11:50 PM

Thanks Bacterius.

Everything is working great now! Glad you guys know the idiosyncrasies of MinGW. I would never have thought of that.

It's not MinGW in particular, all C/C++ compilers work that way - even command-line MSVC I believe. IDE's just hide that

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- Pessimal Algorithms and Simplexity Analysis

### #8Aardvajk  Crossbones+   -  Reputation: 6241

Like
1Likes
Like

Posted 17 March 2014 - 01:11 PM

Just a note - I use the vanilla .lib forms of DX that ship with the SDK with gcc without issues, so no need to convert to .a files.

In that case just supply the full file name of the lib file including the extension.

### #9DarkRonin  Members   -  Reputation: 616

Like
0Likes
Like

Posted 17 March 2014 - 03:16 PM

Just a note - I use the vanilla .lib forms of DX that ship with the SDK with gcc without issues, so no need to convert to .a files.

In that case just supply the full file name of the lib file including the extension.

Seriously? That is awesome to know. I read that you needed to convert dll's made by MS.So this is great

### #10Aardvajk  Crossbones+   -  Reputation: 6241

Like
1Likes
Like

Posted 17 March 2014 - 03:33 PM

Just a note - I use the vanilla .lib forms of DX that ship with the SDK with gcc without issues, so no need to convert to .a files.
In that case just supply the full file name of the lib file including the extension.

Seriously? That is awesome to know. I read that you needed to convert dll's made by MS.So this is great

Yeah I thought that too. Used to be the case but I tried it last year and it worked.

Not sure what gcc version you need though. I use one we use at work built from a very recent source.

### #11DarkRonin  Members   -  Reputation: 616

Like
0Likes
Like

Posted 17 March 2014 - 04:28 PM

Yeah, I just download the latest yesterday. So, I'd imagine that it should be ok to do this with too.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS