Building toolsheld under Cygwin

[Allen Huffman]

Is it possible to build toolshed using Cygwin?

[Tormod Volden]

Yes, that should be straight forward. On Windows you can also build it with the MinGW / MSYS2 toolchain, which is more lightweight than a Cygwin install. See also the README.txt.

[Tormod Volden]

You can see that the Toolshed wiki refers to the NitrOS-9 wiki for how to build, since it has many details on MSYS and Cygwin, and building Toolshed as part of it:
https://sourceforge.net/p/nitros9/wiki/Building_NitrOS9/

[tim lindner]

I just tried building Toolshed with Cygwin (I'm trying out Windows for an extended test). And I got an error:

$ cc --version
cc (GCC) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

And I get many variations on this error:

In file included from ../../../libcoco/libcocoopen.c:8:
../../../libcoco/libcocoopen.c: In function ‘_coco_identify_image’:
../../../libcoco/libcocoopen.c:224:65: error: array subscript has type ‘char’ [-Werror=char-subscripts]
  224 |         if (path && (colon = strchr(path, ':')) && isdigit(colon[1]))
      |                                                            ~~~~~^~~
cc1: all warnings being treated as errors

I could fix this many ways. Does anyone have a preference?

[Tormod Volden]

I suppose this is due to GCC 11 and not specific to Cygwin.

Why the warning in this particular case? Is the "1" somehow turned into a char during expansion of isdigit() ?

[tim lindner]

I don't think it is the '1' that is causing the warning (promoted to an error). I think it is the 'colon' pointer. I added -Wno-char-subscripts to my CFLAGS and moved on with my life. :)

[Allen Huffman]

Since it is unbuildable for anyone else who tries and doesn't end up here, I still think some kind of fix is needed (or at least documentation somewhere about this). How does one set CFLAGS?

[Tormod Volden]

The default CFLAGS are set in build/unix/rules.mak

[Tormod Volden]

I haven't tried on GCC 11 yet, but it all builds fine as-is on GCC 12.1.0 (Linux).

To me the original code seems clear and clean, and I don't understand why there can be a warning. However, can you try this variation?

@@ -221,7 +221,7 @@ error_code _coco_identify_image(char *pa
        /* 2a. Check for a colon followed by number in path part */

        path = strtok(NULL, "");
-       if (path && (colon = strchr(path, ':')) && isdigit(colon[1]))
+       if (path && (colon = strchr(path, ':')) && isdigit(*++colon))
        {
                *type = DECB;

[Tormod Volden]

I just found this in the 'isdigit' man page:

NOTES
The standards require that the argument c for these functions is either EOF or a value that is representable in the type unsigned char. If the argument c is of type char, it
must be cast to unsigned char, as in the following example:

       char c;
       ...
       res = toupper((unsigned char) c);

   This is necessary because char may be the equivalent of signed char, in which case a byte where the top bit is set would be sign extended when converting to int, yielding a value
   that is outside the range of unsigned char.

[Allen Huffman]

Glad it's not just me.

I was trying to build everything on MinGW, but I ran in to errors there, as well. I think it was with LWTOOLS, complaining about "sys/wait.h".

I am trying to write up definitive step-by-step guides with screen shots for my website.

[Allen Huffman]

By applying some (unsigned char) casting (and a few extra parens in some spots, that got me closer.

I am getting an issue in makewave.c about digittoint() as well:

../../../makewav/makewav.c:444:34: error: implicit declaration of function ‘digittoint’ [-Werror=implicit-function-declaration]

I added a prototype, but had to do it outside here:

int digittoint(int c);

#if defined(__CYGWIN32__) || defined(__linux__) || defined(WIN32)
/* implemented based on OSX man page */

That gets me a good build. But I don't want to document these changes in my blog post :)

[Tormod Volden]

Well, if the standard says we should have the unsigned char casts, that's the way to go. Prototypes too. Can you attach your diff?

[Tormod Volden]

Are you building on Cygwin or are you building on MinGW? In either case one of the above macros should be defined and thus the function will be defined. Unless when building on macos, which seems to have a built-in "digittoint()".

[Tormod Volden]

If you are using MSYS2, you should have GCC 12.1 by now, from what I see here: https://packages.msys2.org/package/mingw-w64-x86_64-gcc

Is it the same problem with GCC 12.1 on MinGW?

[Tormod Volden]

OK, I see from https://cygwin.com/cgi-bin2/package-grep.cgi?grep=gcc&arch=x86_64 that Cygwin is still on GCC 11.3. I see it also has MinGW packages. You can therefore also build with MinGW inside Cygwin - the resulting binaries can then be run without the Cygwin environment. Do you get the same errors then? Build it like this (from README.txt):
NOTEST=1 make -C build/unix CC="x86_64-w64-mingw32-gcc -Wl,--force-exe-suffix"

[Tormod Volden]

To find out which macros are defined when building on Cygwin, can you please attach the output from this: echo | gcc -E -dM -

[Tormod Volden]

I fixed up the Cygwin detection in makewav.c - it should be __CYGWIN__ and not __CYGWIN32__ - so the digittoint() issue should be gone.

I am not able to reproduce the other warnings on MinGW (gcc 12) even if I add -Wchar-subscripts to CFLAGS.

Allen, can you please attach your diff with the (unsigned char) casts?

[Tormod Volden]

I added (unsigned char) to everywhere where it was needed. Let me know if it builds on Cygwin now.