GCC Compile error with Code::Blocks


#1

Hi folks,

Trying to compile juce example application for windows with Code::Blocks and GNU GCC compiler. I have eliminated 14 compiler errors and now I’m down to 2 last errors, “throws different exceptions”.

juce_amalgamated.cpp:

line x: error: declaration of `void juce::juce_setWindowStyleBit(HWND__*, int, int, bool) throw ()’ throws different exceptions|

line x: error: than previous declaration `void juce::juce_setWindowStyleBit(HWND__*, int, int, bool)’|

I’ve tried adding or removing the throw() exception to the two different lines, but then I get a different compiler hanging problem with Code::Blocks.

Has anyone gotten around this before? It seems to be a bug or known issue with GNU GCC:

I know that this will compile just fine in VC++ compiler, but I have to use GNU GCC compiler. Why? Because I am porting a linux console application to Windows GUI with Juce.


#2

In my code, all the definitions of that function have the same throw() directive, so I guess you’re using v1.46. But if the definitions all match, I can’t think of any other reason why it’d still have a problem…


#3

With all due respect, they don’t appear to match in the definitions, in my juce_amalgamated.cpp, v1.46.

Line 237071 declaration doesn’t have throw() exception.

Line 241095 declaration does have the throw() exception.

That is why it appears that gnu gcc is giving an error of “declaration throws different exceptions than previous declaration”.

Maybe I am missing something obvious though…


#4

Like I said, in my latest code the definitions match, which is why I said you must be talking about the old v1.46 code.

But when you do make fix it, what’s the follow-up problem?


#5

My bad entirely and my apologies - I didn’t know 1.46 was the old code. I downloaded from the svn trunk what I believe is the latest tarball, and sure enough, the definitions match.

So back to your question, when the fix is made, the follow-up problem is a debug warning message that ‘description field is too big…try a different debug format’. It lists continuously in the build log, until I abort. So it doesn’t look like the compile will ever finish. This is the message:

C:\Documents and Settings\Jason Ostrom\Desktop\dev\juce-proj-test-4\juce\extras\example projects\common…\juce_amalgamated.cpp||In function int OggVorbisNamespace::ov_time_seek_page(OggVorbisNamespace::OggVorbis_File*, double)':| C:\Documents and Settings\Jason Ostrom\Desktop\dev\juce-proj-test-4\juce\extras\example projects\common\..\..\..\juce_amalgamated.cpp|187898|warning: converting toOggVorbisNamespace::ogg_int64_t’ from `double’|
C:\DOCUME~1\JASONO~1\LOCALS~1\Temp\cc9h6s9M.s|461414|Warning: .stabs: description field ‘10125’ too big, try a different debug format|
C:\DOCUME~1\JASONO~1\LOCALS~1\Temp\cc9h6s9M.s|461415|Warning: .stabs: description field ‘10125’ too big, try a different debug format|
C:\DOCUME~1\JASONO~1\LOCALS~1\Temp\cc9h6s9M.s|461419|Warning: .stabn: description field ‘10125’ too big, try a different debug format|
C:\DOCUME~1\JASONO~1\LOCALS~1\Temp\cc9h6s9M.s|461425|Warning: .stabn: description field ‘10128’ too big, try a different debug format|
C:\DOCUME~1\JASONO~1\LOCALS~1\Temp\cc9h6s9M.s|461436|Warning: .stabn: description field ‘10129’ too big, try a different debug format|
C:\DOCUME~1\JASONO~1\LOCALS~1\Temp\cc9h6s9M.s|461446|Warning: .stabs: description field ‘10125’ too big, try a different debug format|
C:\DOCUME~1\JASONO~1\LOCALS~1\Temp\cc9h6s9M.s|461447|Warning: .stabs: description field ‘10125’ too big, try a different debug format|
C:\DOCUME~1\JASONO~1\LOCALS~1\Temp\cc9h6s9M.s|461451|Warning: .stabn: description field ‘10125’ too big, try a different debug format|

When build target is Debug Win32, I get this problem. When build target is Release Win32, I get a different error.

Thanks so much.
J


#6

Don’t know how to do it in code blocks but you may want to move to DWARF debug information as it looks like an issue with stabs format.

HTH


#7

It could also be that the ancient 3.x version of gcc can’t cope with the size of the amalgamated file…


#8

Thanks for the help. It must have been either of those, or both :wink: Turning off the -g debug flag in build options for gcc did the trick.

I’m down to three final gcc errors:

Debug\common\juce_LibrarySource.o:juce_LibrarySource.cpp:(.text+0x1c1c2a)||undefined reference to `_GetFileVersionInfoSizeW@8’|

Debug\common\juce_LibrarySource.o:juce_LibrarySource.cpp:(.text+0x1c1c79)||undefined reference to `_GetFileVersionInfoW@16’|

Debug\common\juce_LibrarySource.o:juce_LibrarySource.cpp:(.text+0x1c1ca8)||undefined reference to `_VerQueryValueW@16’|

Any ideas?


#9

A couple of notes, for additional information:

I am not linking to libjuce.a or libjucedebug.a. Would this be causing the problem with “undefined reference to” the functions in question?

I’m not linking to them because I can’t build the “Juce Library” project when I open up the Code::Blocks project file in:
juce/build/win32/codeblocks/juce.cbp

When I open it and build, it should just work.

Firstly, when Code::Blocks open up the project file, I get a notice saying that the project was created with an older version of Code::Blocks.

Second, I get a bunch of “file not found” errors with messed up paths to the directories when I try to build. After spending an hour manually fixing these paths, the compile finally finishes, but the library files (libjuce.a, libjucedebug.a) are not being output to the bin\codeblocks directory.

Examining the “readme.html”, it says, " If your build environment is set up correctly, these should just work and the demo app should run." I’m wondering what are the special build environment settings for Code::Blocks??

I’d greatly appreciate any help. Thanks.


#10

Those undefined functions are just win32 functions - a quick google should show you which win32 libs you’d need to add for it to link correctly.


#11

Jules, thank you, fearless leader :wink: I saw that those are ms functions after my post, so I should have posted after I had researched further. But it looks like those functions should be recognized by including windows.h, and I thought juce source code took care of that automatically in ‘juce_amalgamated.cpp’ ? I see windows.h included in this file.

Back to my question - why aren’t these ms functions automatically recognized? I am sure I am missing something, I just don’t know what it is. I see no special build instructions required by Code::Blocks.


#12

It’s a link error, not an include problem. In MSVC the juce code automatically tells the compiler which libs to link to, but you can’t do that with gcc.


#13

Thanks.

I specified in the linker settings to link to comdlg32.lib and version.lib, and now it compiles. I guess this was the correct “build environment settings” in the readme.html for Code::Blocks compile. But I don’t know how someone new to juce and Code::Blocks would know this on their own.

Again, appreciate the help.