IRC channel logs
2023-02-20.log
back to list of logs
<zamfofex>Hello, everyone! I’m (once again) trying to update the Hurd packages for Guix. I have made a lot of progress, I feel (or so I hope), but now it seems it’s failing to cross‐build Mach with a failure on ‘kern/strings.c’, saying that ‘NULL’ is not declared, and hinting that including ‘<stddef.h>’ might fix it. (Using glibc 2.35.) Is this an oversight on Mach’s part, or could I be doing something wrong? <zamfofex>Ah, for the sake of completeness, I’m using Mach commit 1b8d96d72b6978b6d2b0f734f1307d6c054e1a0d. <youpi>zamfofex: normally the inclusion of string.h pulls sys/types.h in, which defines NULL <youpi>how do you configure it exactly? <zamfofex>Note that, in the logs, it does mention that ‘./include/sys/types.h’ was included indirectly from ‘./include/string.h’ (from ‘kern/strings.c’, of course) in a warning regarding ‘__always_inline’ being redefined. So at least it seems that it *is* being included properly. <zamfofex>But looking into ‘./include/sys/types.h’, it seems the definition of ‘NULL’ is conditional, so maybe the ‘_POSIX_SOURCE’ macro gets defined somehow. <youpi>that's why I'm asking for the details <youpi>you can also use #error lines to make sure what is happening <zamfofex>I suppose so! Guix builds the packages in its own build environment, so it’s not always trivial to just edit the sources and tell it to build again. I have to apply a patch in the package definition, and if it has any dependencies, it’ll rebuild those automatically in turn. (But I guess it might not be a problem in this case, since I’m trying to build Mach itself, rather than something that depends on it.) <zamfofex>youpi: I tried adding some ‘#error’ directives through a patch, and it seems to have indicated that ‘_POSIX_SOURCE’ is set. <youpi>zamfofex: you need to find out what defines that, it makes no sense to define it... <zamfofex>It seems like it is defined somewhere in glibc, given that I can compile a program that uses it as long as I include a standard header such as ‘<stdio.h>’. 🤔 Are glibc headers not meant to be included when building Mach? Because ‘./mach/machine/vm_types.h’ seems to include ‘<stdint.h>’ from glibc in my build. <youpi>no, glibc doesn't define that <youpi>it's *applications* which are supposed to define it <youpi>and glibc is not meant to be included when building mach, we use -ffreestanding, so it's gcc's stdint.h / stdint-gcc.h that gets included <zamfofex>It seems like it *is* defined when I try to compile a file with GCC unless I use a ‘-std=cXX’ flag. I can easily verify this by writing ‘printf("%d\n", _POSIX_SOURCE);’ within ‘main’ in a simple C program in my home directory and compiling it. It prints ‘1’. Using e.g. ‘-std=c99’, it will fail to compile and tell me that ‘_POSIX_SOURCE’ is not declared. <zamfofex>But if glibc is not meant to be included, then there clearly is something wrong, because it explicitly tells me the included file is ‘/gnu/store/hbz8b4l2n0gapla9fy6s893abvpyvidd-glibc-2.35/include/stdint.h’ <youpi>you could use #define _POSIX_SOURCE foobar in your test program to check with what definition that conflicts <youpi>whatever defines it should really understand the -ffreestanding option, to avoid #defining _POSIX_SOURCE <youpi>and find out why it's glibc's stdint.h that gets included, -ffreestanding is really supposed to avoid including that <youpi>possibly check how the linux package is getting built, it'll have the same issues after all <zamfofex>It seems the package definition in Guix invokes ‘make’ with ‘CFLAGS=-fcommon’, I think that might be why. <youpi>CFLAGS="$CFLAGS -ffreestanding -nostdlib" <youpi>so an external CFLAGS shouldn't be harming <zamfofex>Doesn’t specifying variables as an argument to ‘make’ prevent the makefile from attributing to that variable? (As opposed to specifying them as environment variables, which allows for the makefile to modify them, I mean.) If I run ‘make CFLAGS=foo’, I don’t think the makefile can set the value of ‘CFLAGS’ using ‘=’, ‘:=’ nor any other such things. <youpi>ah, it's specified on the *make* command ? <youpi>I don't see how that's not posing problems to other packages... <zamfofex>This is specific to the ‘gnumach’ package. <zamfofex>I don’t know, I wasn’t the one who put it there! 😅 Note that the Hurd packages on Guix are quite old, so maybe it was necessary at some point.