DJGPP's COFF doesn't support that, nor does PE/COFF (last I checked). GCC's online manual (3.10 Options That Control Optimization) only says it's supported by "most ELF systems, SPARC/Solaris 2, and maybe AIX in the future".marcov wrote:And if you use modern (read: 32-bit) tools, always disable the option to discard unused code (--gc-sections and friends on GCC, -XX "smartlinking" on FPC). Dead code optimization requires a disproportionate amount of memory.
Issues in real DOS on a 486
Re: Issues in real DOS on a 486
Re: Issues in real DOS on a 486
Yeah, that is why we have internal assemblers+ linkers. GCC+binutils sux on non-unix. GDB too, but we haven't found away around that yet :-)
Seriously, there is always poor man's version, not on linker level, but by wrapping each symbol in a separate .o file (which gets its own section by default). Either as used by (very) old versions of FPC, or by doing some creative assembler transformations.
I've seen LD use 1.5+ GB using that method though, to generate a 6MB .EXE.
Seriously, there is always poor man's version, not on linker level, but by wrapping each symbol in a separate .o file (which gets its own section by default). Either as used by (very) old versions of FPC, or by doing some creative assembler transformations.
I've seen LD use 1.5+ GB using that method though, to generate a 6MB .EXE.
Re: Issues in real DOS on a 486
This had been already discussed: http://www.freebasic.net/forum/viewtopi ... 81#p113881Secondly, I found out that FreeBASIC doesn’t work unless you have a FPU
I still think that some sort of "no-init-fpu" switch should be available (and maybe also "no-catch-exceptions" and "no-ntvdm-hacks").