stephenrkell / libsystrap

Monitor, rewrite and/or otherwise trap system calls... on Linux/x86{,-64} only, for now.
GNU General Public License v3.0
59 stars 7 forks source link

Build errors on Ubuntu 22.04 #21

Open caizixian opened 9 months ago

caizixian commented 9 months ago

I was trying to build libsystrap as part of liballocs. I installed all the packages per liballocs README. However, I got some build errors, so I'm trying to isolate them one by one.

Steps:

git clone --recursive https://github.com/stephenrkell/libsystrap
cd libsystrap
make
make -C src
make[1]: Entering directory '/home/zixianc/libsystrap/src'
cc -MM -DIN_LIBRUNT_DSO -DASSERT_FAIL_LINE_SIGNED -DSYSTRAP_DEFINE_FILE -I/home/zixianc/libsystrap/src/../include -g -Wall -Wno-unused-label -Wno-comment -O2 -fPIC -ffreestanding -fno-omit-frame-pointer -DUSE_XED -DNDEBUG -nostdinc -I/home/zixianc/libsystrap/contrib/musl/arch/x86_64 -I/home/zixianc/libsystrap/contrib/musl/arch/generic -I/home/zixianc/libsystrap/contrib/musl/obj/include -I/home/zixianc/libsystrap/contrib/musl/include -I/home/zixianc/libsystrap/contrib/host-includes  -I/home/zixianc/libsystrap/contrib/libx86emulate/src -I/home/zixianc/libsystrap/contrib/librunt/include -std=c99 trap.c > ".trap.d" || rm -f ".trap.d"
trap.c:383:2: error: #error "NO SA_RESTORER set; are you including the asm signal.h?"
  383 | #error "NO SA_RESTORER set; are you including the asm signal.h?"
      |  ^~~~~
cc -DIN_LIBRUNT_DSO -DASSERT_FAIL_LINE_SIGNED -DSYSTRAP_DEFINE_FILE -I/home/zixianc/libsystrap/src/../include -g -Wall -Wno-unused-label -Wno-comment -O2 -fPIC -ffreestanding -fno-omit-frame-pointer -DUSE_XED -DNDEBUG -nostdinc -I/home/zixianc/libsystrap/contrib/musl/arch/x86_64 -I/home/zixianc/libsystrap/contrib/musl/arch/generic -I/home/zixianc/libsystrap/contrib/musl/obj/include -I/home/zixianc/libsystrap/contrib/musl/include -I/home/zixianc/libsystrap/contrib/host-includes  -I/home/zixianc/libsystrap/contrib/libx86emulate/src -I/home/zixianc/libsystrap/contrib/librunt/include -std=c99   -c -o do-syscall.o do-syscall.c
In file included from /home/zixianc/libsystrap/src/../include/raw-syscalls-impl.h:74,
                 from do-syscall.h:4,
                 from do-syscall.c:6:
/home/zixianc/libsystrap/contrib/musl/include/sys/types.h:57:10: fatal error: bits/alltypes.h: No such file or directory
   57 | #include <bits/alltypes.h>
      |          ^~~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [<builtin>: do-syscall.o] Error 1
make[1]: Leaving directory '/home/zixianc/libsystrap/src'
make: *** [Makefile:29: src] Error 2

It seems the problem is that libsystrap/contrib is never built.

Strangely, a fresh standalone clone of libsystrap builds just fine inside the Ubuntu 18.04 container.

caizixian commented 9 months ago

Ah ok, so the mbuild (for xed) is too old, and uses removed Python function (distro, distro_ver, distro_id) = platform.linux_distribution()

This causes make -C contrib to fail but still generates config.mk, so the src build continues when it shouldn't.

caizixian commented 9 months ago

I wonder whether https://github.com/stephenrkell/liballocs/issues/77 's author had this issue or not

caizixian commented 9 months ago

One possibility is that I have python-is-python3. In Python 2, platform.linux_distribution is only deprecated but not removed.

stephenrkell commented 9 months ago

Thanks Zixian. Well done on getting this far. Yes, mbuild breaking owing to Python churn is a very plausible problem that has occurred in the past also.

I think Octave (in #77) may have got past that, but runs into the problem that libdwarfpp is using an old libdwarf which can't grok certain newer features that Ubuntu 22.04 toolchains churn out. Unfortunately the newer libdwarf has some non-trivial API changes. The real solution is to port libdwarfpp to use instead libdw (from elfutils) which is a task I've started but haven't finished. It will make things much faster (libdwarf is old enough not to assume mmap and just goes downhill from there), but is quite a bit chunk of coding.

My workaround for now is to stick to older versions, but efforts are always welcome and I may get some resources on this in (erk) March-ish.