Oh, I didn't expect this to cause so many rebuilds. Whomever gets to it, feel free to merge into staging instead, I guess?

Cc: @andrew-d (if you're interested!)

👍 yeah, I remember seeing this myself at some point, though I think I ended up disabling something more specific? I'm not near my XU4 to check right now, but I might have just disabled CONFIG_MALI_GATOR_SUPPORT to get everything to build? I can test tomorrow evening and report back.

Oh, cool. I have zero idea what Gator does or how this build works, so apparently I went for a larger hammer :)

I'll also give your idea a try if I get to it by then.

Thanks!

Well, adding MALI_GATOR_SUPPORT n to the extraConfig didn't do it. The failure is:

../drivers/gator/gator_events_mali_midgard.c:25:10: fatal error: linux/mali_linux_trace.h: No such file or directory
 #include "linux/mali_linux_trace.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

which seems like a problem with gator, not with gator support in mali.

Is there a GATOR_MALI_SUPPORT option instead?

Okay, so, I did some digging and I think I figured out the issue.

• The error is happening here because the header file isn't found
• That file is included in the Makefile here if the CONFIG_GATOR_MALI_MIDGARD flag is set to y.
• The odroidxu4_defconfig file sets it to y here.

So, you should be able to set GATOR_MALI_MIDGARD n to solve the problem, I think? There's some question of what happens with this block of the Makefile, but I'd try out the GATOR_MALI_MIDGARD n first.

Just tried GATOR_MALI_MIDGARD n. Same error :(

How important do you feel this is?

Gah, that's annoying. Honestly, I think GATOR n is okay for this PR.

Separately, do you think it's worth opening an issue at https://github.com/hardkernel/linux/ to report this upstream?

It can't hurt! I have been guessing they would say they don't have the resources to chase this, since it clearly works for them and the failure is somewhat NixOS-specific.

This page implies to me that it's really a problem with the makefile in the upstream kernel. Another page I found (but can't find again) suggested it only goes wrong when you set source and destination directories for the kernel build as different, which does sound like something NixOS would do.

Maybe Hardkernel would be interested in escalating... I'll file a bug with them, maybe later today, if you don't get to it first :)

I think, to anyone who has the power/desire to merge this: please go ahead. This works ok as it is.

I'll follow up with HK about fixing the build problem properly, and we can remove the kludge in this package at that time.