building sometimes fails with missing asm_offset.c.s

[michaelolbrich]

Describe the bug
When building with -DUSE_GAS=OFF it sometimes fails because asm_offset.c.s is missing:

1/20] Building C object loader/CMakeFiles/asm_offset.dir/asm_offset.c.o
[2/20] Linking C executable loader/asm_offset
FAILED: loader/asm_offset loader/gen_defines.asm
.../vulkan-loader-1.3.250.0-build/loader/gen_defines.asm
: && gcc -O3 -DNDEBUG loader/CMakeFiles/asm_offset.dir/asm_offset.c.o -o loader/asm_offset /usr/lib/libxcb.so && cd .../vulkan-loader-1.3.250.0-build/loader && /usr/bin/python3 .../vulkan-loader-1.3.250.0/scripts/parse_asm_values.py .../vulkan-loader-1.3.250.0-build/loader/gen_defines.asm .../vulkan-loader-1.3.250.0-build/loader/CMakeFiles/asm_offset.dir/ asm_offset.c.s GAS GNU x86_64
Could not open assembler file:
.../build-target/vulkan-loader-1.3.250.0-build/loader/CMakeFiles/asm_offset.dir/asm_offset.c.s
ninja: build stopped: subcommand failed.

Environment (please complete the following information):

• OS: Debian

To Reproduce
Steps to reproduce the behavior:

1. Nothing special, just try a clean build many times. It seems racy. I thinks it's a missing dependency.

[charles-lunarg]

USE_GAS=OFF enables the c fallback code which is likely to break because it relies on the compiler optimizations. I have a desire to remove the fallback code entirely and just disable support for unknown functions since it’s not reliable. It appears you are doing a cross platform build which makes things trickier.

That failure mode looks like the crosscompiling cmake code didn’t take into account the c-fallback path. I don’t have a machine to test it in front of me but that’s what appears to be the issue. It might be as simple as ‘add_dependency’ in cmake buy I can’t say for certain.

[michaelolbrich]

Ah, sorry I meant USE_GAS=ON, I switched from OFF to ON and started getting the errors.

[charles-lunarg]

Ah thanks for the correction! That flag changes a lot of things. In the interest of being clear about the build environment, is this a cross compilation build? The log indicates that but I do appreciate being sure.

[michaelolbrich]

Yes, it's a cross compilation build.

[charles-lunarg]

I'm trying to reproduce the error here, and am not having any success. The way I am trying to reproduce it is to comment out the if (NOT CMAKE_CROSSCOMPILING) branch in loader/CMakeLists.txt:234-236, then run ninja clean; ninja many times in a row.

Could you list which cmake & ninja version you are using, to root out if it is an issue with either tool?

I ran with ninja 1.11.0 & both CMake 3.16.2 & 3.26.4 with no issue. Then I tried with CMake 3.26.4 with ninja 1.11.1 and 1.10.2 with no difference.

[michaelolbrich]

So, it turns out this is a problem on my side. I was looking at the dependencies and couldn't see how asm_offset.c.s was supposed to be created before it's used. So I opened this issue.

But the dependency is there: The dependency is on asm_offset.c.o and asm_offset.c.s is created as intermediate with -save-temps=obj.
I was using icecc (a distributed compiler) and the version I have does not detect this correctly and the intermediate may be created on a different host and not available later. I thought I disabled this to verify that the error was still there without it but it seems I did not. I'm really sorry about that.

[charles-lunarg]

No worries, glad you were able to figure the issue out eventually.

[whitslack]

The same failure occurs when using distcc. It would be nice if the build would produce asm_offset.c.s with an explicit command rather than relying on -save-temps=obj, but thankfully Vulkan-Loader is a small enough library that I can just disable distcc for it and still build it pretty quickly.

[charles-lunarg]

@whitslack So the need to execute code in order to get the offsets isn't strictly necessary. Putting them in global symbols makes them available to the assembly, albeit with some extra work to load the offsets.
This should resolve the issue with distcc.
#1786

[whitslack]

@charles-lunarg: Compiling binaries to execute on the build machine is fine (so long as they're compiled using BUILD_CC or CC_FOR_BUILD rather than CC). That doesn't cause a problem for Distcc. The issue in this case is strictly a limitation of Distcc: it doesn't understand that the -save-temps=obj option causes an additional build artifact to be produced. That extra artifact does not get shipped back from the worker machine to the driver machine, so it can't be found later when needed.

[charles-lunarg]

I see, seems my understanding of the problem was wrong. Still, I created the above PR out of a desire to remove technical debt. Having an added benefit of being easier for people to compile is a nice bonus.