I can actually reproduce this locally in a Bookworm container, if you give me a couple of minutes I should be able to conjure an exact reproducer.

I can actually reproduce this locally in a Bookworm container, if you give me a couple of minutes I should be able to conjure an exact reproducer.

Uh I tried and could not in a simple chroot - did you run it in lxc? I guess that's the only difference

I can actually reproduce this locally in a Bookworm container, if you give me a couple of minutes I should be able to conjure an exact reproducer.

Uh I tried and could not in a simple chroot - did you run it in lxc? I guess that's the only difference

No, it's a simple podman container. I just compared the compiler options from the CI job with my local build and it looks like the right constellation of build options to trigger that issue is:

# rm -rf build
# meson build --werror --buildtype=plain -Dc_args="-flto=auto -ffat-lto-objects -O2"
# ninja -C build
...
../src/boot/efi/stub.c: In function 'load_addons.constprop.0':
../src/boot/efi/stub.c:475:40: error: using a dangling pointer to 'p' [-Werror=dangling-pointer=]
  475 |                         dt_bases[n_dt] = xmemdup((uint8_t*)loaded_addon->ImageBase + addrs[UNIFIED_SECTION_DTB],
      |                         ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  476 |                                                  dt_sizes[n_dt]);
      |                                                  ~~~~~~~~~~~~~~~
In file included from ../src/boot/efi/stub.c:20:
../src/boot/efi/util.h:33:15: note: 'p' declared here
   33 |         void *p;
      |               ^
cc1: all warnings being treated as errors

That's weird, I disabled LTO in one build and it still failed with the same error

Looks like -flto=auto is not necessary at all, just -O2 -ffat-lto-objects seems to be enough.

Looks like -flto=auto is not necessary at all, just -O2 -ffat-lto-objects seems to be enough.

Hah, scratch that, just -O2 seems to be enough:

# rm -rf build; meson build --werror --buildtype=plain -Dc_args=" -O2"; ninja -C build
...
rc/boot/efi/stub.c
../src/boot/efi/stub.c: In function 'load_addons.constprop':
../src/boot/efi/stub.c:475:40: error: using a dangling pointer to 'p' [-Werror=dangling-pointer=]
  475 |                         dt_bases[n_dt] = xmemdup((uint8_t*)loaded_addon->ImageBase + addrs[UNIFIED_SECTION_DTB],
      |                         ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  476 |                                                  dt_sizes[n_dt]);
      |                                                  ~~~~~~~~~~~~~~~
In file included from ../src/boot/efi/stub.c:20:
../src/boot/efi/util.h:33:15: note: 'p' declared here
   33 |         void *p;
      |               ^
cc1: all warnings being treated as errors
[643/2428] Compiling C object src/udev/libudev-core.a.p/udev-rules.c.o
ninja: build stopped: subcommand failed.

That would explain why disabling LTO didn't work.

Looks like de-inlining and initializing the var does the trick, thanks for the quick repro

What's slightly worrying is that with this the Semaphore build seems to be ~10 minutes slower, and we're getting dangerously close to the 1h timeout, but I guess I can play with this later and disable LTO/optimizations when (if) needed.

What's slightly worrying is that with this the Semaphore build seems to be ~10 minutes slower, and we're getting dangerously close to the 1h timeout, but I guess I can play with this later and disable LTO/optimizations when (if) needed.

Yeah there's a bunch of things that can be done, like disabling debug symbols packages/stripping, disabling LTO, disabling compression

What's slightly worrying is that with this the Semaphore build seems to be ~10 minutes slower, and we're getting dangerously close to the 1h timeout, but I guess I can play with this later and disable LTO/optimizations when (if) needed.

I'm wondering, why those packaging changes would cause a 10min increase in runtime. That seems odd.