adding docker developer build with bazel

[vsoch]

It is nice for a project to provide a means to develop that is quick and does not require install of a lot of dependencies on the host! I tested this container first but I think there was an older version of Ubuntu because I hit a building error - installing per the suggested method on ubuntu 22.04 did the trick!

Signed-off-by: vsoch vsoch@users.noreply.github.com

[vsoch]

I'd also be interested to chat about what experiments you have in mind? This seems like a filter tool - e.g., "direct the library to load this specific version" and (at least based on my naive understanding of things) we don't even have good metadata about the choices the linker makes on its own (without this guidance). Is the interesting context with dlopen? E.g., use LD_AUDIT to figure out where those calls happen? Or add different strategies and see which is best in different contexts? One thing I thought might be interesting when I was trying out LD_AUDIT is to print an output file (yaml but could be anything) of what is seen: https://github.com/buildsi/ldaudit-yaml?

[fzakaria]

Thank you for the contribution.
I'll accept the Docker file but as a Nix-enthusiast, I will migrate it to Nix and have instructions on building the image via Nix.
(More hermetic) 😸

The goal that me and @trws spoke about is to explore additional linking strategies.
At the moment this tool can do something akin to Shrinkwrap (https://github.com/fzakaria/shrinkwrap) but has the possibility to find and discover more dependencies through it's audit mechanism. It also emits a self-consumable config at process end which right now is in a TOML format.

I think performance for binaries that consume a lot of dependencies via dlopen is a good experiment.
I wanted to ask @trws of applications that make use of plugins heavily. There is the opportunity here to have a better distinction for look-up paths for plugins vs. immediate dependencies by controlling the inheritance of the lookup-paths.

[fzakaria]

what's this?

[vsoch]

This is one of the linked executables that appeared during the build from bazel - it's on my host because I tested binding the PWD to /code (and it generated). Here is the (now dead) symlink in root's home (in the container):

 ls -l bazel-code 
lrwxrwxrwx 1 root root 81 Jul  5 12:04 bazel-code -> /root/.cache/bazel/_bazel_root/933c2f549343e099e3a6911b282cb71c/execroot/__main__

here are the whole set:

lrwxrwxrwx 1 root root 108 Jul  5 12:04 bazel-bin -> /root/.cache/bazel/_bazel_root/933c2f549343e099e3a6911b282cb71c/execroot/__main__/bazel-out/k8-fastbuild/bin
lrwxrwxrwx 1 root root  81 Jul  5 12:04 bazel-code -> /root/.cache/bazel/_bazel_root/933c2f549343e099e3a6911b282cb71c/execroot/__main__
lrwxrwxrwx 1 root root  91 Jul  5 12:04 bazel-out -> /root/.cache/bazel/_bazel_root/933c2f549343e099e3a6911b282cb71c/execroot/__main__/bazel-out
lrwxrwxrwx 1 root root 113 Jul  5 12:04 bazel-testlogs -> /root/.cache/bazel/_bazel_root/933c2f549343e099e3a6911b282cb71c/execroot/__main__/bazel-out/k8-fastbuild/testlogs

Was this possibly added in a newer release? If you build the container and bind to /code and then build you should see the same pop up!

[fzakaria]

should this be bazel-code?

[vsoch]

No indeed not - the code is bound to /code in the container (a terrible convention I've had for as long as containers have been around!)