Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compiling on linux #72

Open
Neo-Desktop opened this issue Jun 21, 2023 · 11 comments
Open

compiling on linux #72

Neo-Desktop opened this issue Jun 21, 2023 · 11 comments

Comments

@Neo-Desktop
Copy link

Neo-Desktop commented Jun 21, 2023

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 watt32 available 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
Copy link
Author

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
Copy link
Owner

gvanem commented Jun 22, 2023

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
Copy link

sezero commented Jun 22, 2023

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
Copy link

jwt27 commented Jun 22, 2023

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
Copy link

jwt27 commented Jun 22, 2023

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
Copy link
Author

Neo-Desktop commented Jun 22, 2023

@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: openssl/openssl#21259 (comment)


@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
Copy link
Author

Neo-Desktop commented Jun 22, 2023

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
Copy link

jwt27 commented Jun 23, 2023

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:

Watt-32/util/errnos.c

Lines 358 to 359 in d99548f

#elif defined(WATT32_DJGPP_MINGW) /* Same as for HighC */
last_errno = sys_nerr - 1;

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
Copy link
Author

@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
Copy link

jwt27 commented Jun 25, 2023

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
Copy link

jwt27 commented Jun 30, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants