zig native paths should include `/usr/lib/{linux triple}` by default on Linux

[mitchellh]

Zig Version

0.11.0

Steps to Reproduce and Observed Behavior

Depend on something like GTK: step.linkSystemLibrary("gtk4"). On Xubuntu, gtk4 from apt is installed in /usr/lib/aarch64-linux-gnu. I've noticed this on other distros as well such as the flatpak build environment.

Expected Behavior

Given this is a common path for default packages across distros, I think NativePaths should add it here:

https://github.com/ziglang/zig/blob/d0fd67cffe664ff70d9a70dd4d2d28aba5a378e8/lib/std/zig/system/NativePaths.zig#L129

We already add /lib/{linux triple}.

[arBmind]

@mitchellh It seems we already have /usr/lib/{triple} added as native path.

https://github.com/ziglang/zig/blob/d0fd67cffe664ff70d9a70dd4d2d28aba5a378e8/lib/std/zig/system/NativePaths.zig#L118

My totally speculative guess is, that the path is missing somewhere else.

[mitchellh]

Oh you're right... very strange. Maybe this isn't the right codepath. My minimal reproduction is a build.zig that just does step.linkSystemLibrary("gtk4") with an empty C file. If I manually add /usr/lib/{triple} it works.

[geefuoco]

I can confirm that it does check /usr/lib/{triple}. The error message contains all the searched paths for the .a or .so files. The issue must be happening elsewhere

testing$ ../bin/zig build
zig build-exe testing Debug native: error: error: unable to find Dynamic system library 'gtk4' using strategy 'paths_first'. searched paths:
  /usr/local/lib64/libgtk4.so
  /usr/local/lib64/libgtk4.a
  /usr/local/lib/libgtk4.so
  /usr/local/lib/libgtk4.a
  /usr/lib/x86_64-linux-gnu/libgtk4.so
  /usr/lib/x86_64-linux-gnu/libgtk4.a
  /lib64/libgtk4.so
  /lib64/libgtk4.a
  /lib/libgtk4.so
  /lib/libgtk4.a
  /usr/lib64/libgtk4.so
  /usr/lib64/libgtk4.a
  /usr/lib/libgtk4.so
  /usr/lib/libgtk4.a
  /lib/x86_64-linux-gnu/libgtk4.so
  /lib/x86_64-linux-gnu/libgtk4.a

[mitchellh]

For my exe, if I remove this, the build fails (Zig 0.11):

if (step.target.isLinux()) {
    const triple = try step.target.linuxTriple(b.allocator);
    step.addLibraryPath(.{ .path = b.fmt("/usr/lib/{s}", .{triple}) });
}

I'll eyeball my build a little closer to see if something weird is happening...

[Arnau478]

Take a look at #8103, the vendor may be the issue

[buzmeg]

I just bumped into this on Ubuntu 22.04.3 with zigraylib (https://github.com/SimonLSchlee/zigraylib) on current zig:

zigraylib$ zig version                                                                                                                                                                                                         
0.12.0-dev.1643+91329ce94

zigraylib$ zig build run                                                                                                                                                                                                       
raylib.zig build-lib raylib Debug native: error: error: unable to find Dynamic system library 'GL' using strategy 'paths_first'. searched paths:
  /usr/lib/libGL.so
  /usr/lib/libGL.a
error: unable to find Dynamic system library 'X11' using strategy 'paths_first'. searched paths:
  /usr/lib/libX11.so
  /usr/lib/libX11.a

Libraries exist at the expected triple. There is no cross-compiling going on.

lrwxrwxrwx 1 root root     10 Jan  4  2022 /usr/lib/x86_64-linux-gnu/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root     14 Jan  4  2022 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.7.0
-rw-r--r-- 1 root root 543056 Jan  4  2022 /usr/lib/x86_64-linux-gnu/libGL.so.1.7.0


zigraylib$ ls -al /usr/lib/x86_64-linux-gnu/libX11*                                                                                                                                                                            
lrwxrwxrwx 1 root root      19 Oct  2 14:13 /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 -> libX11-xcb.so.1.0.0
-rw-r--r-- 1 root root   14048 Oct  2 14:13 /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0
-rw-r--r-- 1 root root 2209016 Oct  2 14:13 /usr/lib/x86_64-linux-gnu/libX11.a
lrwxrwxrwx 1 root root      15 Oct  2 14:13 /usr/lib/x86_64-linux-gnu/libX11.so -> libX11.so.6.4.0
lrwxrwxrwx 1 root root      15 Oct  2 14:13 /usr/lib/x86_64-linux-gnu/libX11.so.6 -> libX11.so.6.4.0
-rw-r--r-- 1 root root 1306280 Oct  2 14:13 /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0

[peroksid]

On 22.04.1-Ubuntu I had the same issue. When I installed the packages "libgtk-4-dev" and "build-essential", the issue was gone.

[RossComputerGuy]

@peroksid Those are required on Ubuntu and Debian based systems as they use split packages for headers. On Arch Linux, you wouldn't need to install a -dev package as they're not split.

[manuelprinz]

(Disclaimer: This is my first comment/contribution to the project.)

I've been trying to reproduce the issue (because of the "contributor friendly" tag) on my Debian system and VMs of the OSes mentioned in the issue, with Zig versions between 0.11.0 and newer, but I am unable to find the issue using a similar test as mentioned in https://github.com/ziglang/zig/issues/16733#issuecomment-1668643364. It seems to me that the issue is based on the fact that Debian-based OSes have dev-packages, which also include the pkg-config configurations, which in some cases are required for proper linking, because of some conventions by Debian/Ubuntu.

In the case of GTK4, the package libgtk-4-1 (runtime library) provides /usr/lib/x86_64-linux-gnu/libgtk-4.so.1, which is not caught up when using step.linkSystemLibrary("gtk4"), due to the difference in name (missing dash). When installing libgtk-4-dev, as was mentioned in https://github.com/ziglang/zig/issues/16733#issuecomment-1861880282, both /usr/lib/x86_64-linux-gnu/libgtk-4.so and /usr/lib/x86_64-linux-gnu/pkgconfig/gtk4.pc will be installed. The pkg-config contains the correct linking options, which are used by Zig when building. It works for Zig 0.11.0 and newer. (Using step.linkSystemLibrary("gtk-4") also works, but that would be a Debian-specific hack which is not required, because of the .pc file.)

Once all required dev-packages are installed, zigraylib (see https://github.com/ziglang/zig/issues/16733#issuecomment-1818185713) builds fine with Zig 0.11.0 and newer versions.

I will try some more, but it seems like the missing dev-packages are at fault, and Zig works as expected. (I did not test cross-compilation yet.) If there is a concrete scenario on how to reproduce the issue, I would appreciate that for some further analysis. If the documentation needs to be improved with regards to Debian-based systems, I would appreciate a pointer to which documentation might be affected.

[manuelprinz]

It seems like it is only a cross-compilation issue. Steps to reproduce (e.g. on amd64):

1. Create a new project with zig init.
2. Add exe.linkSystemLibrary("X11"); to build.zig.
3. Run zig build -Dtarget=arm-linux-gnueabi (fails, expected).
4. Install missing dependencies: sudo dpkg --add-architecture armel && sudo apt update && sudo apt install libx11-dev:armel.
5. Run zig build -Dtarget=arm-linux-gnueabi again. Still fails.

The package provides the library and pkg-config file in /usr/lib/arm-linux-gnueabi/libX11.so and /usr/lib/arm-linux-gnueabi/pkgconfig/x11.pc, respectively. It seems to me that the pkg-config is not picked up, most likely also because of the triple.

P.S.: Updated the example to use arm. This seems to work (produces a binary), although the build fails. I could not get a working example out of mips64el (plain zig init example).