stephenrkell
Build failures when building on Debian Trixie
So far:
- A requirement for multilib support (i.e building and installing 32-bit packages/binaries on 64-bit Debian-based distributions) should be emphasised, since multilib support does not appear to be enabled by default anymore.
-
libunwindappears to be a necessary dependency, but I do not recall seeing this in either the README, CircleCI files, or Dockerfiles. - Newer versions of OCaml have immutable strings, which is at odds with the version of cil used by this projects (mutable methods are still present in the codebase)
It sounds like you have solved these issues? If so, a pull request updating the README would be welcome -- the multilib thing is quite new.
The libunwind packages are definitely installed in the CircleCI config.
Trying to - I keep finding more issues as I try to get a full build to work! Currently trying to get a version of OCaml 4.02 to compille: implicit declarations are not supported by newer versions of GCC.
That's definitely not necessary... I am using 4.11.1 successfully. The immutable string issues should be warnings not errors, I think?
Oh, riiiiight. I presume that the fork of CIL that you use works with 4.11.1?
File "src/cilint.mli", line 6, characters 36-51:
6 | type cilint = Small of int | Big of Big_int.big_int
^^^^^^^^^^^^^^^
Error: Unbound module Big_int
It appears that num is now a separate library that must be installed!
Yes, I think you're right that recent versions/packagings have changed this... one more for a README update.
Strongly considering a port to meson, if only for the sanity of future contributors. Will post more updates.
It sounds like you have solved these issues? If so, a pull request updating the README would be welcome -- the multilib thing is quite new.
The multilib thing has been around for a while. I really ought to make a PR with my guides...
Strongly considering a port to meson, if only for the sanity of future contributors. Will post more updates.
I think #121 is a much better solution for the CIL problems. The team over there is actively maintaining it, and it is up-to-date with the latest OCaml. It would be great to try to gather a list of things needed by liballocs that Goblint-CIL doesn't have, and port them over to a fork of Goblint-CIL. Hopefully, it can be upstreamed from then on.
That makes sense long-term (so possibly later this week), but I still haven't managed to figure out how to get liballocs to build and run tests yet!
turns out that liballocs's fork of CIL requires some symlinks in order to successfully compile for me:
aleth@liballocs-demo:~/liballocs-clean
cd contrib/cil/lib/cil
ln -sf ../../_build/src/cil.cmxa cil.cmxa
ln -sf ../../_build/src/cil.a cil.a
No, this should be handled by make making a copy of those files automatically. I think it failed somewhere else, and you are trying to resurrect a post-crash build residue here
libunwind appears to be a necessary dependency, but I do not recall seeing this in either the README, CircleCI files, or Dockerfiles.
See https://github.com/stephenrkell/liballocs/blob/41a1cfd8649b818cf9a419c5ede79a528e37228a/.circleci/config.yml#L19
The Dockerfiles in the buildtest folder are quite outdated, I suggest disregarding those
No, this should be handled by make making a copy of those files automatically. I think it failed somewhere else, and you are trying to resurrect a post-crash build residue here
that would make sense, but I'm not sure if I have the sanity to try clean builds from scratch, unless github Build Actions are particularly speedy here...
FWIW, doing a symlink caused the contrib build to succeed. I'm now trying to deal with allocsld not building.
Good luck! Fyi, things are buildable on Ubuntu 25.04, gcc 14, ocaml 4.11.1 as they are in the repo. It is, however, quite a tricky task!
Yeah ... think it's probably worth making it more reproducible/distro-agnostic!
Currently trying to set export CC_DRIVER=/usr/bin/gcc to get past an example not building
If you can supply me the exact error message and context, I can probably help with that one.
A segment of it is preserved (I frequently clear my console):
/home/aleth/liballocs-clean/contrib/toolsub/wrapper/example/constructor-priority-checker/wrapper: line 14: [rosetta]: command not found
make[3]: *** [<builtin>: systrap.o] Error 1
make[3]: Leaving directory '/home/aleth/liballocs-clean/build/opt'
make[2]: *** [Makefile:42: all] Error 2
make[2]: Leaving directory '/home/aleth/liballocs-clean/src'
make[1]: *** [Makefile:1837: all-recursive] Error 1
make[1]: Leaving directory '/home/aleth/liballocs-clean'
Note that setting that variable seems to have done the trick with regards to the build. now for the tests!
Good luck! Fyi, things are buildable on Ubuntu 25.04, gcc 14, ocaml 4.11.1 as they are in the repo. It is, however, quite a tricky task!
going to try this now, if only to then have a working baseline upon which i can then do fearless refactoring...
Odd. stuck when building contrib:
configure: creating ./config.status
config.status: creating Makefile
config.status: creating liballocstool.pc
config.status: creating config.mk
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing libtool commands
config.status: executing depfiles commands
The string [rosetta] makes me wonder: are you running in some kind of emulated environment?
For the hang (assuming that is what is happening), that is really odd... I would try to use ps and strace to figure out which process is hanging.
Yes: x86 VM on Apple silicon.
It's slightly confusing, because there are 3 zombie gcc processes that are listed as descendants of make, and 3 duplicates that are direct children from /sbin/init !
Might try doing this on a pure x86 vm and report back....
Even curioser, the duplicates come back, even when the main processes in question have been killed.
Not sure which order is correct: 1 (readme):
./autogen.sh && \
. contrib/env.sh && \
./configure && \
2(circleci)
. contrib/env.sh
./autogen.sh
./configure
/usr/bin/ld: cannot find -lallocstool: No such file or directory
hmm... I thought I did compile this. must have missed a step somewhere.
will come back to this tomorrow, at which point I will run a make clean (of both contrib and the root dir) and see what files are still present. I suspect the makefile is not cleaning up artifacts properly.
Not sure which order is correct: 1 (readme):
./autogen.sh && \ . contrib/env.sh && \ ./configure && \2(circleci)
. contrib/env.sh ./autogen.sh ./configure
Only configure needs the env variables set by the 'env.sh' so both are correct here.
About the missing lallocstool: this is due to an incorrect 'env.sh', build contrib again and hopefully it will fix it!
About the missing lallocstool: this is due to an incorrect 'env.sh', build contrib again and hopefully it will fix it!
So reproducibility does actually have benefits in practice!
/usr/bin/ld: cannot find -lallocstool: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:1307: tools/pervasive-types] Error 1
builder@liballocs-builder:~/liballocs$ ls /home/builder/liballocs/contrib/liballocstool/lib
liballocstool.a Makefile
builder@liballocs-builder:~/liballocs$ ls /home/builder/liballocs/contrib/liballocstool/include
allocmeta-defs.h allocsites-info.hpp frame-element.hpp stickyroot.hpp uniqtype-defs.h uniqtype.h uniqtypes.hpp
Unsure what is going on. Would the choice of linker be affecting this? Am I supposed to be using bfd or gold here?
Contents of relevant env.sh files (including previous line for history context):
builder@liballocs-builder:~/liballocs$ ls /home/builder/liballocs/contrib/liballocstool/include
allocmeta-defs.h allocsites-info.hpp frame-element.hpp stickyroot.hpp uniqtype-defs.h uniqtype.h uniqtypes.hpp
builder@liballocs-builder:~/liballocs$ cat contrib/env.sh
. /home/builder/liballocs/contrib/libsystrap/contrib/env.sh
. /home/builder/liballocs/contrib/liballocstool/contrib/env.sh
export LIBSYSTRAP_DIR="/home/builder/liballocs/contrib/libsystrap"
export LIBRUNT_DIR="/home/builder/liballocs/contrib/libsystrap/contrib/librunt"
export LIBALLOCSTOOL_CXXFLAGS="-I/home/builder/liballocs/contrib/liballocstool/include "
export LIBALLOCSTOOL_LIBS="-L/home/builder/liballocs/contrib/liballocstool/lib -lallocstool "
export LIBDLBIND="/home/builder/liballocs/contrib/libdlbind"
export CIL_INSTALL="/home/builder/liballocs/contrib/cil/lib"
export TOOLSUB="/home/builder/liballocs/contrib/toolsub"
export ELFTIN="/home/builder/liballocs/contrib/elftin"
export LIBMALLOCHOOKS="/home/builder/liballocs/contrib/libmallochooks"
export DONALD="/home/builder/liballocs/contrib/donald"
builder@liballocs-builder:~/liballocs$ cat /home/builder/liballocs/contrib/liballocstool/contrib/env.sh
. /home/builder/liballocs/contrib/liballocstool/contrib/dwarfidl/contrib/env.sh
export DWARFIDL_CXXFLAGS="-I/home/builder/liballocs/contrib/liballocstool/contrib/dwarfidl/include -I/home/builder/liballocs/contrib/liballocstool/contrib/dwarfidl/include -I/home/builder/liballocs/contrib/liballocstool/contrib/dwarfidl/include "
export DWARFIDL_LIBS="-L/home/builder/liballocs/contrib/liballocstool/contrib/dwarfidl/lib -Wl,-rpath,/home/builder/liballocs/contrib/liballocstool/contrib/dwarfidl/lib -ldwarfidl -L/home/builder/liballocs/contrib/liballocstool/contrib/dwarfidl/lib -Wl,-rpath,/home/builder/liballocs/contrib/liballocstool/contrib/dwarfidl/lib -ldwarfidl -L/home/builder/liballocs/contrib/liballocstool/contrib/dwarfidl/lib -Wl,-rpath,/home/builder/liballocs/contrib/liballocstool/contrib/dwarfidl/lib -ldwarfidl"
Can you show the actual command that fails, not just the message it prints?
Although your later snippets show that there is a liballocstool.a that could be picked up, only the -L options to the link command can show whether the linker is looking in the right place.
It should not matter here whether your /usr/bin/ld is BFD or gold or something else, as long as it is nothing too wacky. Saying that, I have never tested this stuff with lld or mold so I am just guessing that they are not too wacky.