Date: Mon, 11 Apr 94 11:45:45 -0400 From: dj AT ctron DOT com (DJ Delorie) To: kunst AT prl DOT philips DOT nl Cc: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: Re: uploads to cygnus - dll, farptr, V2.0 src > (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 ) 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 or 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)