Skip to content

compiling on linux #72

Open
Open

Description

@Neo-Desktop

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

Activity

  1. Neo-Desktop commented on Jun 22, 2023

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

  2. gvanem commented on Jun 22, 2023

    @gvanem
    Owner

    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?

  3. sezero commented on Jun 22, 2023

    @sezero

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

  4. jwt27 commented on Jun 22, 2023

    @jwt27

    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
    
  5. jwt27 commented on Jun 22, 2023

    @jwt27

    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.

  6. Neo-Desktop commented on Jun 22, 2023

    @Neo-Desktop
    Author

    @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

  7. Neo-Desktop commented on Jun 22, 2023

    @Neo-Desktop
    Author

    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

  8. jwt27 commented on Jun 23, 2023

    @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

    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.

  9. Neo-Desktop commented on Jun 25, 2023

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

  10. jwt27 commented on Jun 25, 2023

    @jwt27

    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

  11. jwt27 commented on Jun 30, 2023

    @jwt27

    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.

  12. beebix1980 commented on Jun 8, 2026

    @beebix1980

    stumbled upon the same problem and fixed it by writing a custom standalone makefile.

    makefile.djgpp.txt

  13. gvanem commented on Jun 10, 2026

    @gvanem
    Owner

    and fixed it by writing a custom standalone makefile.

    With this fix:

    echo 'char *sys_errlist[] = { "Success", "Unknown error" };' >> $(OBJDIR)/syserr.c;

    Does it really make sense with 2 entries?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions