zig_target_toolchain example and other things

[ntorresalberto]

Hi,
First of all, I wanted to say thanks for this great project!
I was quite surprised with how simple it's been to find most of the things I needed.
After playing around with it, I encountered a few minor issues that I'm not even sure are originated by rules_zig or upstream dependencies.
I intend to keep using bazel/zig so I'd like to help improve it in the long term and so I thought I might as well open a discussion and see where it goes.
I'll do my best to keep it short:

Integration with shared libs from cmake rules_foreign_cc

This might possible unrelated to rules_zig.
I couldn't find any example using foreign_cc as I was trying to include SDL3 in my project and I compiled it using the rules_foreign_cc.cmake rule. I'd be happy to contribute one for e2e if you think it might be useful.
However, I faced some problems with SDL3 because it outputs 2 shared libraries: libSDL3.so, libSDL3.so.0. They're equivalent, mind you. However, I couldn't find a proper config for cmake's out_shared_libs parameter:

option 1

cmake(
    name = "sdl3_shared",
   (.... code ...)
   
    out_shared_libs =  ["libSDL3.so.0"],  # or ["libSDL3.so", "libSDL3.so.0"]
  error: unable to find dynamic system library 'SDL3.so' using strategy 'paths_first'. searched paths:
  bazel-out/k8-fastbuild/bin/_solib_k8/_U_A_A+_Urepo_Urules+com_Ugithub_Usdl_S_S_Csdl3_Ushared___Uexternal_S+_Urepo_Urules+com_Ugithub_Usdl_Ssdl3_Ushared_Slib/libSDL3.so.so
  bazel-out/k8-fastbuild/bin/_solib_k8/_U_A_A+_Urepo_Urules+com_Ugithub_Usdl_S_S_Csdl3_Ushared___Uexternal_S+_Urepo_Urules+com_Ugithub_Usdl_Ssdl3_Ushared_Slib/libSDL3.so.a

option 2

    out_shared_libs =  ["libSDL3.so"],                            # <- libSDL3.so.0: cannot open shared object file: No such file or directory

so it seems that it insists on using libSDL3.so.0 in all cases, even i not mentioned in out_shared_libs. This might be an issue upstream or from how rules_zig uses the cmake target. I also tested using LD_LIBRARY_PATH to run the binary and that makes option 2 work.
Let me know if you can think of how to find out.

Regarding libc version & Toolchain

It took me some time to figure out the linking error below was caused by libSDL3 being compiled with a more recent version of libc while rules_zig is pinned to 2.17: #300.
So I figured that maybe there was a way to use the toolchain options: https://github.com/aherrmann/rules_zig/blob/main/docs/toolchains.md
to set -target "x86_64-linux-gnu.2.39". I wasn't able to find a way to do it.
I was able to verify that either removing the -target argument completely or using 2.39 solves my problem though.
If you could guide me a litle with what I'd need, I could make a simple case to add to e2e as an example.

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
error: undefined symbol: __isoc23_fscanf
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_cpuinfo.c.o):.text
error: undefined symbol: __isoc23_sscanf
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_hidapi.c.o):.text
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_hidapi.c.o):.text
error: undefined symbol: __isoc23_strtol
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_hidapi.c.o):.text
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_hidapi.c.o):.text
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
error: undefined symbol: __isoc23_vsscanf
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
error: undefined symbol: wcslcpy
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
error: undefined symbol: wcslcat
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
error: undefined symbol: __isoc23_wcstol
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
error: undefined symbol: strlcpy
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
error: undefined symbol: strlcat
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
error: undefined symbol: __isoc23_strtoul
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
error: undefined symbol: __isoc23_strtoll
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
error: undefined symbol: __isoc23_strtoull
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_string.c.o):.text
error: undefined symbol: posix_spawn_file_actions_addchdir_np
    note: referenced by bazel-out/k8-fastbuild/bin/external/+_repo_rules+com_github_sdl/sdl3_static/lib/libSDL3.a(SDL_posixprocess.c.o/):.text
Target //:chase-bin failed to build

General

As general feedback, I know I didn't pick the easiest project being a bit new to Bazel and Zig but it goes to show that this package is so well thought out that I was able to get something working, so kudos to that!
My first instinct was to add a new project as a new dir in e2e and try to make it work by modifying rules_zig (I don't know how developing for Bazel is supposed to go) but I couldn't execute my targets because of some --deleted_packages error.
I tried taking a look at https://github.com/aherrmann/rules_zig/blob/main/CONTRIBUTING.md, and specifically the override step was what finally enabled me to debug more deeply and find the glibc issue. However this approach is not compatible with adding a demo project at e2e (it says there's some conflict with the override).

[aherrmann]

Hi @ntorresalberto, thank you for opening the discussion, for the kind words, and for sticking through with the issues you encountered!

Regarding libc version & Toolchain

An e2e example to change glibc version and more broadly addressing #300 would certainly be welcome. To give some pointers:
The tests include an example of how to configure a musl libc, the platform is defined here, the constraint is defined here, and the target toolchain is defined here. To select a specific glibc version you can follow the same pattern: In your own project/example, define a new constraint value, e.g. glibc-2.39; define a target toolchain with that constraint and target flag, register the target toolchain (e.g. --extra_toolchains flag or register_toolchains in your MODULE.bazel), define a platform that includes the constraint, and configure that as the target platform for your Bazel build, e.g. using the --platforms flag. You can use --toolchain_resolution_debug=.*zig.* to see what toolchain Bazel is selecting.

Integration with shared libs from cmake rules_foreign_cc

An example of using rules_foreign_cc would indeed be welcome. I haven't tried this myself yet with rules_zig. In principle rules_foreign_cc outputs should behave mostly like regular C library targets and those are supported by rules_zig, so hopefully not too much is needed to make this work. Here's an example of shared library dependencies.

The issue you're describing about it insisting on libSDL3.so.0 may be due to one of the files being a symlink or due to the libraries SONAME field: During the build the linker will look at the provided .so file, read the SONAME field and mark that as the NEEDED dependency in the resulting dynamic binary. When it then runs, the loader will try to find a shared object with that file name. Usually both files .so and .so.0 are needed in these cases.

Something that stands out to me in the searched paths error message is the double file extension in libSDL3.so.so. It's possible that some part of the pipeline is adding a .so extension itself and it being provided in the input somewhere is redundant.

[aherrmann]

Regarding libc version & Toolchain

Side note, just for future reference, this proposal (recently added) is relevant.