Linux progress

QBasicer · Post by **QBasicer** » Wed Jun 09, 2004 7:30 am

Besides GCC, what other compilers are there?

I thought GCC followed the ANSI C standards?

If the GCC in Windows doesn't work, that probably means the GCC in Linux will have a hard time too, right?

Post by **Graf Zahl** » Wed Jun 09, 2004 7:53 am

It's only the SEH that's not supported by it. Linux doesn't support SEH anyway and you can compile ZDoom without it (but that means you'll get no crash logs.)

Post by **Chris** » Wed Jun 09, 2004 4:26 pm

From what I remember, Randy added the crash logs because WinXP doesn't give you any crash info by default (without searching through a few clickable option in the crash box), as opposed to Win9x where all you had to do was click a button and get the backtrace and stack state. Granted the crash logs give more info than Win9x did, but still. I'm sure *nix OSs have some way to get the kind of crash info the crash log generates (manually, at least).

Jim · Post by **Jim** » Wed Jun 09, 2004 5:22 pm

Chris wrote:From what I remember, Randy added the crash logs because WinXP doesn't give you any crash info by default (without searching through a few clickable option in the crash box), as opposed to Win9x where all you had to do was click a button and get the backtrace and stack state. Granted the crash logs give more info than Win9x did, but still. I'm sure *nix OSs have some way to get the kind of crash info the crash log generates (manually, at least).

Crashes leave core dump files, unless your system has this disabled. You can check the core file size limit by "ulimit" at the command prompt. If this is 0 or otherwise too low, enable unlimited size for later crash dumps by "ulimit -c unlimited". You can examine these core files in gdb (The GNU Debugger) by "gdb nameandpathofexecutable corefilename". You can then, for example, do a backtrace by typing "bt". You can type "help" for help and "quit" to quit.

QBasicer · Post by **QBasicer** » Wed Jun 09, 2004 7:10 pm

I've been trying to install a lot of the dependancies/libaries to compile ZDoom. With any luck it should compile by tommorow.

So, does the makefile work?

[EDIT] Doesn't it piss you off then a site you need goes down? Well, the SDL site just did, and I need the cross complier stuff...[/EDIT]

QBasicer · Post by **QBasicer** » Thu Jun 10, 2004 6:09 am

I know I should have edited my first post, but then people don't get an alert I edited it again...

So, I tried to compile ZDoom this morning, but I have a feeling the makefile is NOT for Windows, or maybe it is, but anyways, here's the errors:

Code: Select all

C:\zdoom>mingw32-make
process_begin: CreateProcess((null), uname -s, ...) failed.
process_begin: CreateProcess((null), uname -s, ...) failed.
makefile:53: src//files.mak: No such file or directory
makefile:77: dspfiles: No such file or directory
process_begin: CreateProcess((null), uname -s, ...) failed.
process_begin: CreateProcess((null), uname -s, ...) failed.
process_begin: CreateProcess((null), uname -s, ...) failed.
process_begin: CreateProcess((null), uname -s, ...) failed.
process_begin: CreateProcess((null), uname -s, ...) failed.
process_begin: CreateProcess((null), uname -s, ...) failed.
process_begin: CreateProcess((null), uname -s, ...) failed.
makefile:142: no file name for `include'
makefile:143: no file name for `include'
mingw32-make: *** No rule to make target `util/cvdsp.c', needed by `util/cvdsp'.
  Stop.

C:\zdoom>

So my question is, how to I compile this puppy.

Post by **Chris** » Thu Jun 10, 2004 6:13 am

Dev-C++, or try Relo (recomended) which can open Dev-C++ (and VC++) project files.

QBasicer · Post by **QBasicer** » Thu Jun 10, 2004 6:27 am

Ok, I have Dev-CPP, I'll load it up and configure it and try to compile.

ERROR(S)!

Code: Select all

C:\zdoom\src\am_map.cpp: [Warning] In function `void AM_drawGrid(int)':
1682 C:\zdoom\src\am_map.cpp: `sqrtf' undeclared (first use this function)
(Each undeclared identifier is reported only once for each 
C:\zdoom\Makefile.win: [Build Error] exe: *** [devcobj/am_map.o] Error 1

What's this error now?

The errornous line is:

Code: Select all

	// [RH] Calculate a minimum for how long the grid lines should be so that
	// they cover the screen at any rotation.
	[b]minlen = (fixed_t)sqrtf ((float)m_w*(float)m_w + (float)m_h*(float)m_h);[/b]
	extx = (minlen - m_w) / 2;
	exty = (minlen - m_h) / 2;

The middle line is the offender.

What scares me is that it did it right away, on the first file.... That's a bad sign.

Post by **Graf Zahl** » Thu Jun 10, 2004 9:50 am

sqrtf is a float version of sqrt. I always thought they were part of the ANSI specification. It seems your math.h is old.

Post by **randi** » Thu Jun 10, 2004 9:50 am

I've never had problems using the float versions (rather than the double versions) of the floating point functions with GCC.

QBasicer · Post by **QBasicer** » Thu Jun 10, 2004 12:43 pm

I quick scan (or rather, Windows search), found that math.h does not seem to be included anywhere. Where should it be?

Post by **Chris** » Thu Jun 10, 2004 6:50 pm

If you're using the version of MinGW that came with Dev-C++, I recommend you upgrade MinGW from the official MinGW site. The version that comes with Dev-C++ has always caused problems.

Hirogen2 · Post by **Hirogen2** » Sat Jun 12, 2004 5:18 am

Graf Zahl wrote:sqrtf is a float version of sqrt. I always thought they were part of the ANSI specification. It seems your math.h is old.

Code: Select all

CONFORMING TO
       SVID  3, POSIX, BSD 4.3, ISO 9899.  The float and the long
       double variants are C99 requirements.

QBasicer · Post by **QBasicer** » Fri Jul 09, 2004 1:44 pm

So, how has the Linux ZDoom been going?

BTW: I kinda gave up on Dev-CPP, as it's too slow for such a huge source tree, it takes a while to open all the files...

Hirogen2 · Post by **Hirogen2** » Mon Jul 12, 2004 4:57 am

If the GCC in Windows doesn't work, that probably means the GCC in Linux will have a hard time too, right?

At least the other way round. Compiling a perfectly fine *Unix* (including Linux) code makes trouble in MINGW, because simple constants like S_IRUSR are missing.

mingw32-make: *** No rule to make target `util/cvdsp.c', needed by `util/cvdsp'.

That's because util/cvsdsp.c IS MISSING, so this one doesnot even compile on Linux.

I like to use MSYS for it's a good GNU environment in Win32. Together with gnuwin32.sf.net and of course the mingw compiler besides MSYS.