gvanem / Watt-32

Watt-32 TCP/IP library and samples.
https://www.watt-32.net/
18 stars 8 forks source link

compiling on linux #72

Open Neo-Desktop opened 1 year ago

Neo-Desktop commented 1 year ago

Hi there - how do I compile on linux?

./configur.sh doesn't seem to generate the *.err files as noted in the the header of configur

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 watt32available on the website is 2.2 from 2018

I'm trying to compile OpenSSL (3.x) for use with djgpp and it seems to be missing a definition for SHUT_RD which

  1. does not appear to be defined in the binary version on the website
  2. appears to be defined in sys/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

Neo-Desktop commented 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

gvanem commented 1 year ago

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?

sezero commented 1 year ago

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.)

jwt27 commented 1 year ago

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

I think something went wrong there:

#define EILSEQ            41
#define EWOULDBLOCK       41
jwt27 commented 1 year ago

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.

Neo-Desktop commented 1 year ago

@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

Neo-Desktop commented 1 year ago

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

jwt27 commented 1 year ago

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

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.

Neo-Desktop commented 1 year ago

@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

jwt27 commented 1 year ago

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

jwt27 commented 1 year ago

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.