[Fixed] .43 -> .47 compile barfs w/gcc

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Anonymous

.43 -> .47 compile barfs w/gcc

Post by Anonymous »

gcc version 3.3.1 (mingw special 20030804-1)

src is the latest available, 2.0.43 patched to 2.0.47 cleanly.

Code: Select all

src/m_options.cpp:612: error: brace-enclosed initializer used to initialize `char*'
...repeated 6 times.


I have *zero* idea why gcc is spazzing on this, but tracing back, I (embarassingly) don't know much about unions, either.

Ideas, perhaps?
~Rai
User avatar
randi
Site Admin
Posts: 7750
Joined: Wed Jul 09, 2003 10:30 pm

Post by randi »

There are some braces around the initializers for char pointers on those lines. Change the corresponding {NULL} to NULL.
User avatar
Hirogen2
Posts: 2033
Joined: Sat Jul 19, 2003 6:15 am
Operating System Version (Optional): Tumbleweed x64
Graphics Processor: Intel with Vulkan/Metal Support
Location: Central Germany

Post by Hirogen2 »

Randy, did you merge that patch from me fixing that -- and some other errors (but not all :( ) ?
Anonymous

Post by Anonymous »

Right, that did it; thanks.

I should have probably studied the declaration and the error both a bit more.


Now for the fun part. Why?

a. Why does gcc spazz? a1. Is that assignment against C99? a2. Is gcc errornous in calling this an error?
b. Why does MSVC/et al [presumably] allow this?
c. If it's against C99, why do it that way?
d. Does it have to do with a difference in the way NULL is defined between MS's stuff and GNU's?


-------------------------
More fun for ya'.

GNU ld version 2.14.90 20030807
NASM version 0.98.36 compiled on Mar 13 2003

f:\dev\MinGW\bin\..\lib\gcc-lib\mingw32\3.3.1\..\..\..\..\mingw32\bin\ld.exe: devcobj/blocks.o: bad reloc address 0x49b in section `.text'

Files are assembled with:

Code: Select all

nasmw -o devcobj/a.o -f win32 src/a.nas
as per the project settings.
-------------------------

Finally got zDoom to compile, but when run, it just plain freezes and hogs up the mouse.
I'll investigate later. Anyway...

I'm including a patch that'll make zDoom play a little nicer with gcc.
Please feel free to clunk me on the head if I did anything noob'ish.



Changed project settings to compile .cpp files as C++, as they weren't, before.


Hunk 2 is optional (not an error); I plan on quelling a bunch of warnings later.
I *think* the rest of the things came up as errors.

I havn't examined the ramifications of Hunk 4 (const byte stuff), but gcc complained very loudly otherwise. I don't think it should be an issue, though.

-DNO_SEH (#define NO_SEH) ... gcc doesn't have SEH support [yet?]. Rumor-mill is churning on gcc 3.4 snapshots.

Hunk 6... for some reason, even while including dinput.h, CLSID-yaddayadda never gets run. I havn't traced the logic path very well, but #including <initguid.h> before dinput.h fixes one thing, then barfs all over with errornous claims of this and that being redefined, that don't even seem to be in the zDoom program! Maybe experiment with this more later, or maybe not.

Code: Select all

diff -durN zdoom-2.0.47/src/b_func.cpp zdoom/src/b_func.cpp
--- zdoom-2.0.47/src/b_func.cpp	Thu Aug 14 11:15:20 2003
+++ zdoom/src/b_func.cpp	Thu Aug 14 23:57:06 2003

@@ -252,6 +252,8 @@
 		case wp_mstaff:
 			m /= GetDefaultByName ("MageStaffFX2")->Speed;
 			break;
+		default:
+		    break;
 		}
 		SetBodyAt (enemy->x + enemy->momx*m*2, enemy->y + enemy->momy*m*2, ONFLOORZ, 1);
 		actor->player->angle = R_PointToAngle2 (actor->x, actor->y, body1->x, body1->y);
diff -durN zdoom-2.0.47/src/decorations.cpp zdoom/src/decorations.cpp
--- zdoom-2.0.47/src/decorations.cpp	Thu Aug 14 11:15:16 2003
+++ zdoom/src/decorations.cpp	Sat Aug 16 04:07:32 2003
@@ -817,7 +817,7 @@
 		else if (def == DEF_Projectile && SC_Compare ("Speed"))
 		{
 			SC_MustGetFloat ();
-			defaults->Speed = sc_Float * 65536.f;
+			defaults->Speed = (fixed_t)(sc_Float * 65536.f);
 		}
 		else if (SC_Compare ("Mass"))
 		{
diff -durN zdoom-2.0.47/src/m_options.cpp zdoom/src/m_options.cpp
--- zdoom-2.0.47/src/m_options.cpp	Fri Mar 21 20:14:36 2003
+++ zdoom/src/m_options.cpp	Sat Aug 16 03:27:18 2003
@@ -596,15 +596,15 @@
 	{ redtext,	" ",					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
 	{ discrete, "Fullscreen",			{&fullscreen},			{2.0}, {0.0},	{0.0}, {YesNo} },
 	{ redtext,	" ",					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
-	{ screenres,{NULL},					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
-	{ screenres,{NULL},					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
-	{ screenres,{NULL},					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
-	{ screenres,{NULL},					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
-	{ screenres,{NULL},					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
-	{ screenres,{NULL},					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
-	{ screenres,{NULL},					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
-	{ screenres,{NULL},					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
-	{ screenres,{NULL},					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
+	{ screenres, NULL,					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
+	{ screenres, NULL,					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
+	{ screenres, NULL,					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
+	{ screenres, NULL,					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
+	{ screenres, NULL,					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
+	{ screenres, NULL,					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
+	{ screenres, NULL,					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
+	{ screenres, NULL,					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
+	{ screenres, NULL,					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
 	{ whitetext,"Note: Only 8 bpp modes are supported",{NULL},	{0.0}, {0.0},	{0.0}, {NULL} },
 	{ redtext,  VMEnterText,			{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
 	{ redtext,	" ",					{NULL},					{0.0}, {0.0},	{0.0}, {NULL} },
diff -durN zdoom-2.0.47/src/r_draw.cpp zdoom/src/r_draw.cpp
--- zdoom-2.0.47/src/r_draw.cpp	Sat Apr  5 17:53:48 2003
+++ zdoom/src/r_draw.cpp	Sat Aug 16 00:15:14 2003
@@ -178,7 +178,7 @@
 		// [RH] Get local copies of these variables so that the compiler
 		//		has a better chance of optimizing this well.
 		byte *colormap = dc_colormap;
-		byte *source = dc_source;
+		const byte *source = dc_source;
 		int pitch = dc_pitch;
 
 		// Inner loop that does the actual texture mapping,
@@ -961,7 +961,7 @@
 	DWORD frac = dc_texturefrac;
 	BYTE *colormap = dc_colormap;
 	int count = dc_count;
-	BYTE *source = dc_source;
+	const BYTE *source = dc_source;
 	BYTE *dest = dc_dest;
 	int bits = vlinebits;
 	int pitch = dc_pitch;
diff -durN zdoom-2.0.47/src/win32/i_crash.cpp zdoom/src/win32/i_crash.cpp
--- zdoom-2.0.47/src/win32/i_crash.cpp	Mon Apr  7 17:23:48 2003
+++ zdoom/src/win32/i_crash.cpp	Sat Aug 16 03:24:46 2003
@@ -40,6 +40,19 @@
 
 #define MAX_CRASH_REPORT (256*1024)
 
+/* FIXME: This will make some code compile. The programs will most
+   likely crash when an exception is raised, but at least they will
+   compile. */
+#ifdef NO_SEH
+#define __try
+#define __except(x) if (0) /* don't execute handler */
+#define __finally
+
+#define _try __try
+#define _except __except
+#define _finally __finally
+#endif
+
 typedef BOOL (WINAPI *THREADWALK) (HANDLE, LPTHREADENTRY32);
 typedef BOOL (WINAPI *MODULEWALK) (HANDLE, LPMODULEENTRY32);
 typedef HANDLE (WINAPI *CREATESNAPSHOT) (DWORD, DWORD);
@@ -436,6 +449,10 @@
 
 static void StackWalk ()
 {
+#ifdef NO_SEH
+  return;
+}
+#else
 	DWORD *addr = (DWORD *)DumpAddress;
 	DWORD_PTR *seh_stack;
 
@@ -622,6 +639,7 @@
 	*CrashPtr++ = '\n';
 	*CrashPtr = 0;
 }
+#endif // NO_SEH
 
 static void DumpBytes ()
 {
diff -durN zdoom-2.0.47/src/win32/i_input.cpp zdoom/src/win32/i_input.cpp
--- zdoom-2.0.47/src/win32/i_input.cpp	Thu Aug 14 11:15:16 2003
+++ zdoom/src/win32/i_input.cpp	Sat Aug 16 01:43:26 2003
@@ -73,8 +73,10 @@
 #endif
 
 #ifdef __GNUC__
-// I don't know if the new MinGW DirectX 9 libs define these or not.
+// The new MinGW DirectX 9 libs still need these.
 const GUID IID_IDirectInput8A = { 0xBF798030,0x483A,0x4DA2,{0xAA,0x99,0x5D,0x64,0xED,0x36,0x97,0x00}};
+const GUID CLSID_DirectInput8 = { 0x25E609E4,0xB259,0x11CF,{0xBF,0xC7,0x44,0x45,0x53,0x54,0x00,0x00}};
+
 static DIOBJECTDATAFORMAT MouseObjectData2[11] =
 {
 	{&GUID_XAxis,  0, 0x00ffff03, 0},


~Rai

(PS: Is there a better forum for this?)
User avatar
Hirogen2
Posts: 2033
Joined: Sat Jul 19, 2003 6:15 am
Operating System Version (Optional): Tumbleweed x64
Graphics Processor: Intel with Vulkan/Metal Support
Location: Central Germany

Post by Hirogen2 »

About the enclosing braces at NULL:

Code: Select all

- { screenres, {NULL},               {NULL},               {0.0}, {0.0},   {0.0}, {NULL} },
for example denotes a struct which has something at the first member, a struct at the second ... to clearify, the struct for the codeline above would be:

Code: Select all

struct {
  char *bla;
  struct {
    char *bla;
  } bb;
  ...;
}
This is a programming error. NULL is correct in this case, not {NULL}. Dunno why ppl do this; i have encountered it way too often. Another one is this

Code: Select all

diff -Ndru zdoom-before/src/r_things.cpp zdoom/src/r_things.cpp
--- zdoom-before/src/r_things.cpp	2003-07-28 20:17:18.000000000 +0200
+++ zdoom/src/r_things.cpp	2003-07-28 20:17:12.000000000 +0200
@@ -90,8 +90,10 @@
 TArray<spriteframe_t> SpriteFrames;
 size_t			NumStdSprites;		// The first x sprites that don't belong to skins.
 
# Your MSVC extension doesnot work under GCC.
-struct : public spriteframe_t
+struct
 {
+	WORD Texture[16];	// texture to use for view angles 0-15
+	WORD Flip;			// flip (1 = flip) to use for view angles 0-15.
 	int rotate;
 }
 sprtemp[MAX_SPRITE_FRAMES];
http://linux01.org:2222/f/zdoom-2.0.47-hx1.diff
Anonymous

If you care...

Post by Anonymous »

My compile log, just in case somebody actually cares.

They're just warnings, but a few of them are pretty bad.
For instance, it *looks like* the FLAC stuff isn't correctly setting up ('long long') 64-bit data types, and is just, for some reason, using long.

I'll try tackling some of that tomorrow.[/url]
User avatar
randi
Site Admin
Posts: 7750
Joined: Wed Jul 09, 2003 10:30 pm

Post by randi »

Just finished doing some cleanup for GCC. My Dev-C++ project now compiles ZDoom with no errors or warnings. (Yes, I even bothered to get rid of the superfluous "variable might be used uninitialized" warnings.)

Return to “Closed Bugs [GZDoom]”