Open Neo-Desktop opened 1 year ago
Ended up just going the cross compilation route for the errno
files and running the resulting executable in dosbox-x
that being said if anyone needs a copy of djgpp.err
and syserr.c
for djgpp-gcc1220
the following gist has a rendered copy:
https://gist.github.com/Neo-Desktop/ad26e888d64b22a59c743ab4e21ac186
Hi there - how do I compile on linux?
I've no idea (I've not used Linux in many years). The src/configur.sh
script was made by Ozkan Sezer.
it just occurred to me that the main reason why I'm even going down this path is because the latest binary version of watt32 > available on the website is 2.2 from 2018
It's terribly outdated. Better pull from Github.
- cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN",
+ cflags => "-I$ENV{'WATT_ROOT'}/inc -DTERMIOS -DL_ENDIAN",
This seems correct for Linux (no djgpp FSextensions there). Maybe you could contribute that to OpenSSL?
Hi there - how do I compile on linux?
I've no idea (I've not used Linux in many years). The
src/configur.sh
script was made by Ozkan Sezer.
My old 2.2.11-sezero branch has several improvements to configure.sh and makefile.all: https://github.com/sezero/watt32/commits/2.2.11-sezero https://github.com/sezero/watt32/blob/2.2.11-sezero/src/configur.sh https://github.com/sezero/watt32/blob/2.2.11-sezero/src/makefile.all Follow their histories -- possibly along with the branch's history. (The changes will need forward-porting to master branch though.)
that being said if anyone needs a copy of
djgpp.err
andsyserr.c
fordjgpp-gcc1220
the following gist has a rendered copy: https://gist.github.com/Neo-Desktop/ad26e888d64b22a59c743ab4e21ac186
I think something went wrong there:
#define EILSEQ 41
#define EWOULDBLOCK 41
A better solution for cross-compiling, would be to run something like:
echo | i386-pc-msdosdjgpp-gcc -x c -E -dM --include errno.h - | grep 'define E'
And then parsing the output from that in a native program/script. But I don't know if all supported compilers have "dump macro" option like this.
@gvanem
It's terribly outdated. Better pull from Github.
I have indeed done that at this point
This seems correct for Linux (no djgpp FSextensions there). Maybe you could contribute that to OpenSSL?
I have opened a ticket here: https://github.com/openssl/openssl/issues/21259#issue-1768658701
@sezero
My old 2.2.11-sezero branch has several improvements to configure.sh and makefile.all: https://github.com/sezero/watt32/commits/2.2.11-sezero https://github.com/sezero/watt32/blob/2.2.11-sezero/src/configur.sh https://github.com/sezero/watt32/blob/2.2.11-sezero/src/makefile.all Follow their histories -- possibly along with the branch's history. (The changes will need forward-porting to master branch though.)
Thank you so much for these links - I'll look into them later
@jwt27
I think something went wrong there:
#define EILSEQ 41 #define EWOULDBLOCK 41
fascinatingly enough:
according to: https://man7.org/linux/man-pages/man3/errno.3.html
All the error names specified by POSIX.1 must have distinct values, with the exception of EAGAIN and EWOULDBLOCK, which may be the same. On Linux, these two have the same value on all architectures.
EWOULDBLOCK
should have the same ID as EAGAIN
but it seems to have been pushed to 41
?
Which is interesting since EWOULDBLOCK
should be considered a "vendor" errno
A better solution for cross-compiling, would be to run something like:
echo | i386-pc-msdosdjgpp-gcc -x c -E -dM --include errno.h - | grep 'define E'
And then parsing the output from that in a native program/script. But I don't know if all supported compilers have "dump macro" option like this.
this is a brilliant solution for my use case, but you're right in that it's very likely only supported by gcc
I think something went wrong there:
#define EILSEQ 41 #define EWOULDBLOCK 41
fascinatingly enough:
according to: https://man7.org/linux/man-pages/man3/errno.3.html
All the error names specified by POSIX.1 must have distinct values, with the exception of EAGAIN and EWOULDBLOCK, which may be the same. On Linux, these two have the same value on all architectures.
EWOULDBLOCK
should have the same ID asEAGAIN
but it seems to have been pushed to41
? Which is interesting sinceEWOULDBLOCK
should be considered a "vendor"errno
I don't think it's intentional, and it seems this is what causes it:
https://github.com/gvanem/Watt-32/blob/d99548f9966c2653a787b7b54281c2cf756c04dd/util/errnos.c#L358-L359
That macro is defined for win32/dj_err.exe
- which is built via mingw32. But
you say you ran it in DOSBox-X... I'm curious how you managed that :)
Anyway, I'm wondering now why dj_err.exe
is even included in this repo at
all. It seems rather pointless to include target-specific binaries that always
produce the exact same output, You might as well just include the output
directly.
@jwt27
That macro is defined for
win32/dj_err.exe
- which is built via mingw32. But you say you ran it in DOSBox-X... I'm curious how you managed that :)
Ah, good point - I should've documented that - I don't believe I specified any MinGW flags - that might be why
I more or less cobbled something together from the makefile for dj_error
and I recall taking a cursory look into the code as well, but I don't recall what I defined specifically.
I should definitely specify WATT32_DJGPP_MINGW
and retry compilation
No, that macro shouldn't be defined, but somehow it is. From the util
directory, if you run:
$ make -f dj-errno.mak dj_err.exe BIN_PREFIX=i386-pc-msdosdjgpp-
That should do the right thing. Or alternatively, you can use these:
https://github.com/jwt27/build-gcc/blob/master/patch/watt32-djgpp-cvs/djgpp.err https://github.com/jwt27/build-gcc/blob/master/patch/watt32-djgpp-cvs/syserr.c
Just a thought - do all supported compilers at least have a "preprocess only" option?
If so, you could pre-process part of errnos.c
(VendorName()
, VendorVersion()
, process()
) with the cross-compiler, and then compile that to a native program. You just won't be able to use strings from libc's sys_errlist
that way.
Hi there - how do I compile on linux?
./configur.sh
doesn't seem to generate the*.err
files as noted in the the header ofconfigur
Is this only something that can be built on windows?
edit:
it just occurred to me that the main reason why I'm even going down this path is because the latest binary version of
watt32
available on the website is2.2
from2018
I'm trying to compile
OpenSSL (3.x)
for use withdjgpp
and it seems to be missing a definition forSHUT_RD
whichsys/socket.h
on master in this repository.I should be able to compile
OpenSSL
correctly if given a new binary version.n.b.: the artifacts that were available on appveyor are not available currently as they are over one month old