GNOME Bugzilla – Bug 732359
task-build: allow setting architecture-specific cflags for a module
Last modified: 2021-06-05 16:29:25 UTC
In some cases, a module might need specific CFLAGS for an architecture (an example of this is that iPXE is always 32-bit, so passing in our generic x86_64 bit cflags breaks it.)
Created attachment 279438 [details] [review] task-build: allow setting architecture-specific cflags for a module
Review of attachment 279438 [details] [review]: What about supporting explicit architecture overrides, like "architecture": "i686" in the manifest?
So, I dug into this a bit more, and didn't really figure out anything satisfactory. It's actually grub that has the problem, not iPXE (iPXE just ignores CFLAGS set in the environment), and with grub, the situation is pretty confused: Grub builds in three environments - the build environment (build utils), host environment (grub utils), and the target environment (the bootloader). The documentation claims that CFLAGS is just host-specific cflags and TARGET_CFLAGS and BUILD_CFLAGS are separate, but as far as I can tell, this doesn't reflect reality - CFLAGS is pretty much always passed in when compiling, and there is a separate HOST_CFLAGS. Overriding the architecture and using the 32-bit cflags isn't going to work because we need the utilities to be built for 64-bit - we don't include a 32-bit C library in the x86_64 build. Possible fixes: * Have some option: 'no_cflags: true' that means don't pass CFLAGS and CXXFLAGS. Basically, we just need to assume that grub will respect setarch and do something reasonable - trying to micromanage it's cflags is a ton of work. * This patch - it behaves the same as the first option because grub actually overrides the standard default CFLAGS to '' instead of the normal '-g O2'. It's hackier than the first option in this application, but more flexible * Heavily patch (submit upstream) changes to grub's build system to try and make CFLAGS work as documented - I don't see this as appealing - it looks like it would require a ton of fighting automake. * Lightly patch in a non-upstream fashion grub's build system just enough to make it ignore CFLAGS passed in the environment - like: # We don't want -g -O2 by default in CFLAGS -: ${CFLAGS=""} +CFLAGS="" I'll vote for this patch, but could be convinced to do any of the above other than a major rework of grub's CFLAGS handleing.
Hmmm. Is this grub actually used in a real target system? Are you adding the BLS patch? With this rationale your patch is OK by me.
Review of attachment 279438 [details] [review]: Pushed as https://git.gnome.org/browse/gnome-continuous/commit/?id=e293d8865e24206719c0fd83592e36ab4bbcd1be
(In reply to comment #4) > Hmmm. Is this grub actually used in a real target system? Are you adding the > BLS patch? grub is used when booting a target system to test it. The operation I want is: Find a boot partition by label Boot the boot loader configuration stored on that partition syslinux can't do this for multiple reasons. (Can't read a kernel from a different partition than where syslinux is installed, etc.) Grub however can. I had some problems with the BLS patch - if I recall correctly it didn't handle selecting the right OS configuration to boot correctly - so instead I'm using the syslinux support in recent versions of grub to read the syslinux configuration that ostree writes.
gnome-continuous is not under active development anymore. Its codebase has been archived: https://gitlab.gnome.org/Archive/gnome-continuous Closing all its open tickets as part of housekeeping.