Building storm with Debian 11 fails

[Gapstare]

I try to build this with the more recent Debian 11. When compiling storm I get:

debug.c:594:5: error: converting a packed ‘debug_screen_type’ pointer (alignment 1) to a ‘uint16_t’ {aka ‘short unsigned int’} pointer (alignment 2) may result in an unaligned pointer value [-Werror=address-of-packed-member]
  594 |     memory_set_uint16_t((void *) screen, DEBUG_ATTRIBUTE_CRASH * 256 + ' ', dataarea.x_size * dataarea.y_size);
      |     ^~~~~~~~~~~~~~~~~~~
In file included from debug.c:10:
../include/storm/generic/debug.h:36:9: note: defined here
   36 | typedef struct```

[perlun]

Sorry for the delay on this one @Gapstare, nice to see your interest in the project. 🎉

Chaos is currently in very much of a "low-maintenance mode", or in practice "no-maintenance". According to the Vagrantfile, I've used Debian 9 the last time I was hacking on this.

I think you have basically two options:

1. Silence the warning, i.e. add something like -Wno-error=address-of-packed-member to the appropriate place. (Let me know if you can't find it, and I'll help dig it up in our build scripts)
2. Try to "fix the code" to not generate the warning in the first place. This may or may not be harder than the above.. maybe we can make gcc understand that debug_screen_type should also always have alignment 2. 🤔

Either way, you'll probably have to roll up the sleeves and try to understand this on your own, but I'm happy to give some feedback on the read (not necessarily very frequently though, but feel free to @perlun-me if you have specific questions). I'll probably have this in my email now also so if you write a comment here I'll be reminded about the existence of this issue. 🙂

[Gapstare]

Thank you @perlun 🙂 I read about chaos in the comment section on osnews.com and it seemed interesting since it was developed mostly by Swedish speaking users. My understanding of C is basic and kernel development is above my head. Your tip about -Wno-error=address-of-packed-member got me a bit on the way but then compilation crashes when modplay. The author seems to have made a fix for C 11 but updating the code doesn't help. I would like to disable building modplay for now but I can't figure out how to make rake skip this step. Any pointers?

[perlun]

Thank you @perlun 🙂 I read about chaos in the comment section on osnews.com and it seemed interesting since it was developed mostly by Swedish speaking users.

Yeah, we are indeed a bunch of mostly Swedish hackers who were involved in the project back then in fact. 🙂 ❤️

Your tip about -Wno-error=address-of-packed-member got me a bit on the way but then compilation crashes when modplay.

Hmm, that's too bad. 😒 What kind of error message do you get, could you paste it here?

The author seems to have made a fix for C 11 but updating the code doesn't help. I would like to disable building modplay for now but I can't figure out how to make rake skip this step. Any pointers?

Sure. 👍 This location in the build scripts determines what projects under the programs directory that get compiled:

chaos/programs/Rakefile

Lines 5 to 8 in b882f4a

	SUBFOLDERS = %w[
	cluido
	modplay
	].freeze

If you just remove modplay from that list, you should hopefully get a bit further. Will be interesting to hear how it goes now! 🙂

[Gapstare]

Thanks for the hints 🙂 When compiling modplay I get:

In function ‘memcopy’,
    inlined from ‘hxcmod_load’ at hxcmod.c:1484:5:
hxcmod.c:401:7: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
  401 |   d[i]=s[i];
      |   ~~~~^~~~~
In file included from hxcmod.c:55:
hxcmod.c: In function ‘hxcmod_load’:
hxcmod.h:97:10: note: at offset 0 to object ‘length’ with size 1 declared here
   97 |  muchar  length;
      |          ^~~~~~
In function ‘memcopy’,
    inlined from ‘hxcmod_load’ at hxcmod.c:1484:5:
hxcmod.c:401:7: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
  401 |   d[i]=s[i];
      |   ~~~~^~~~~

[Gapstare]

@perlun I feel that we can close this issue now since I with your help have a working build environment (sans modplay). I have pushed my changes to my fork but I use qemu and libvirt instead of Virtualbox, it was just to much trouble getting it to work with my Debian testing installation. If you want to I can open a pull request but perhaps it belongs in a separate branch or something? It would solve #174 .

[perlun]

@Gapstare Sorry for the silence from my end. 😬 Thanks for providing the modplay warnings, appreciated! It does seem like the way we've written the code there simply doesn't play well with the newer gcc version. It's probably not too hard to fix, but... I'd need to give it a closer look to say definitely.

I have pushed my changes to my fork but I use qemu and libvirt instead of Virtualbox, it was just to much trouble getting it to work with my Debian testing installation. If you want to I can open a pull request but perhaps it belongs in a separate branch or something? It would solve #174 .

If you have the energy, by all means feel free to submit a PR with your changes! 👍 I can't promise that it'll be merged before having seen it but I'll definitely make sure we consider it for inclusion.

[perlun]

(For reference, see #176 for the outcome of this)