Closed jbruchon closed 9 years ago
The 64-bit fix was a shotgun approach; there are values that have to be interpreted as 32-bit but long on x86_64 is 64-bit. Including stdint.h was done to bring in int32_t. Is the Makefile element $(command) the GNU C construct you're referring to?
Yes the $(command ...) is non-posix http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html
I did test on various machines in the old HP testdrive thing, some of those were 64bit. I think all of dev86 was okay (but not perfect, some things have to be disabled) on machines with a 64bit INT.
I've done a quick recheck of the makeboot.c and as far as I can see the only "long == 32bit" dependency is bracketed with #ifdef MSDOS tokens and is an assembler interface. (ie: the requirement is long>=32bit always on non-MSDOS)
So what's the bug ?
Unfortunately, the bug either doesn't exist or I can no longer reproduce it. I made these changes while trying to fix some really broken stuff in ELKS and elkscmd; I pulled lkundrak/dev86 master and set it beside my elks/elkscmd/elksnet trees and everything seems to have built OK right out of the box. I'm going to close this pull and toss out my fork for now.
Problems: 1) That Makefile is supposed to be POSIX, no GNU C constructs allowed. A full clean needs a make clean then a make realclean (Your editor temp files are your problem not dev86's) a portable change would be nice.
2) as86_encap shouldn't be duplicated, either link to the one in "as" or get the Makefile to copy (and clean) it.,
3) fseek takes an off_t not an int32_t (nor a long). The C compiler I used for the MSDOS baseline is dos MSC version 5.1 it defines off_t in sys/types.h
And finally, what are you trying to fix with the 32bit thing, you've made so many extra changes I can't see where the actual bug is.