Mail Archives: djgpp/1994/04/15/20:26:19
> (1) I had the switch '2r1' in my GO32 environment variable in order
> to redirect output for 'stderr' to 'stdout'. As has been noted by
> others on this list before, this can cause problems during compilation
> when the C preprocessor (cpp) outputs error messages !
> I had such an occasion with 'malloc.c'.
> The cpp-warning 'NULL redefined (line 45)' (previous definition
> on line 223 in <stddef.h>) gave a compilation error for this file.
> After removing '2r1' from the GO32 environment 'malloc.c' compiled fine.
This again. Anyone want to volunteer to fix go32 to avoid this
problem?
> (2) In the file 'LIBSRC\MAKE.BAT' forward slashes are used in the
> CD commands (e.g. 'cd ../gcc') which make my MS-DOS 6.0 puke...
> Changing these to backward slashes solved this.
Sorry; I have my own cd.com program that accepts Unix slashes.
> (3) I had an error during linking of 'sample.exe' that '_handlemode'
> was an unresolved external (from 'findiop.c').
> It turned out that I had included in 'libc.a' the wrong version
> of 'open.o' since both 'open.s' (old) and 'open.c' were present
> in 'LIBSRC\C\SYS'.
> The same holds for a couple of other files (chdir.o etc.)
> After having removed the '.s' versions of these sources
> and remaking of libc.a this problem was resolved as well.
You shouldn't unzip the V2.0 sources over a V1.11 source area, because
many files switched from .s to .c or were deleted.
> (4) I used the included version of MAKE this time. I normally
> use Borland MAKE but since we are in the 'no-nonsense' era now
> I decided it was a good moment to switch to GNU make ;-)
> I didn't have copies of 'mv' and 'rm' yet (which are invoked
> during making of the various libraries) but where to obtain these
> must be definitely a FAQ !
> Are they also included somewhere in the DJGPP *.zip distribution ?
Sorry; another program I've had for a while and take for granted.
> (5) Finally, I got 'sample.exe' compiled, linked and running ! Hooray !
> Three out of four test suites worked fine, only the 'show_dpmi()'
> routine was unresolved at link time. Perhaps a part still under
> development, or yet another not-yet-correctly-compiled library ?!?
> Pardon me for my ignorance...
I'll have to check that one out.
> (8) One last question to you, DJ. Is it alright to use the same
> (new, V2.0) include files for both V2.0 compilations as well
> as the standard 1.11m4 compilations ?
The only one that changed noticably is either <dpmi.h> or <dos.h>
where the .x branch of the register union is now 16 bit registers
instead of 32 bit, with a new .e branch for 32-bit. This solves some
problems but might cause others. The structure is still binary
compatible between libc.a's though. V2.0 has extra includes for V2
functions (crt0.h).
I anticipate the V2.0 includes will change radically in early
development to clean them up and bring them up to ANSI/POSIX spec for
layout (instead of std.h)
- Raw text -