Fails to build: internal_error

[Matěj Cepl]

When building [the yt package](https://github.com/yt-project/yt)
as part of the packaging yt for openSUSE, the build often fails
(not always, something between 50 % and 80 %) with an error like
this:

[ 338s] gcc -Wno-unused-result -Wsign-compare -DNDEBUG -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=r
eturn-type -g -DOPENSSL_LOAD_CONF -fwrapv -fno-semantic-interposition -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protecti
on -Werror=return-type -g -IVendor/ -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -IVendor
/ -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -freport-bug -fPIC -Iyt/utilities/
lib/ -Iyt/utilities/lib -I./yt/utilities/lib -I/usr/include/python3.10 -I/usr/lib64/python3.10/site-packages/numpy/core/include -c yt/utilities/lib/marching_cubes.cpp -o build/temp.linux-x86_64-cpython-310/yt/u
tilities/lib/marching_cubes.o
[ 338s] lto1: internal compiler error: resolution sub id 0xadc1906a211a636c not in object file
[ 338s] 0x102f76b internal_error(char const*, ...)
[ 338s] ???:0
[ 338s] 0x15cfb50 lto_main()
[ 338s] ???:0
[ 338s] Please submit a full bug report, with preprocessed source.
[ 338s] Please include the complete backtrace with any bug report.
[ 338s] See <https://bugs.opensuse.org/> for instructions.
[ 338s] lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit status
[ 338s] compilation terminated.
[ 338s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: error: lto-wrapper failed
[ 338s] collect2: error: ld returned 1 exit status

I have filed it as https://github.com/yt-project/yt/issues/4278 and one of SUSE gcc people claimed this (marxin at 2023-01-03T09:27:00+01:00):

> Well, the build runs in 2 steps, the first one compiles .c files into
> object files (.o). And later, these objects are linked into shared
> libraries (.so). And what happens is that due to a missing dependency
> in between a .so file and one of its dependencies (.o file), such
> object file is provided to the linker. But it happens before it's
> actually finished. That's why we speak about broken dependencies. It
> has nothing to do with compiler race conditions. Does it make sense?

That looks like a Cython problem, doesn’t it? Is it a known bug?

Best and Happy New Year!

Matěj
--
https://matej.ceplovi.cz/blog/, @mc...@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8

Perfection is finally attained not when there is no longer
anything to add, but when there is no longer anything to take
away.
-- Antoine de Saint-Exupery

[D Woods]

I'll post this on the issue as well: assuming the race-condition theory is correct (if I understand correctly, it's trying to an .o file that it's in the process of generating) then it's probably a distutils/setuptools problem. Cython's job is to translate a .pyx file to a .c file, and the compilation of the .c file is handled by something else (which is usually distutils or setuptools, but could be make, or something else).

Cython does do a small amount of monkey-patching to these packages though, so it's possible the problem is on our end. But probably unlikely.

I'm aware this sounds like trying to pass the buck furter ;).