Segmentation fault on Debian with C libraries

[pedro-w]

When I attempt to zig build run this code:

const std = @import("std");
const s = @cImport({
    @cInclude("sqlite3.h");
});

pub fn main() anyerror!void {
    std.debug.warn("All your codebase are belong to {}.\n", .{s.sqlite3_libversion()});
}

I get

Segmentation fault at address 0x0
attempt to unwrap error: InvalidExe
Panicked during a panic. Aborting.

I would expect this to be OK (it doesn't seem to be specific to sqlite, I picked it as a library with a simple exported function to test)

LLDB is not very helpful

(lldb) target create "zig-cache/bin/sqlitetest"
Current executable set to 'zig-cache/bin/sqlitetest' (x86_64).
(lldb) run
Process 1619 launched: '/home/Projects/sqlitetest/zig-cache/bin/sqlitetest' (x86_64)
Process 1619 stopped
* thread #1, name = 'sqlitetest', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x0000000000000000
error: memory read failed for 0x0
(lldb) bt
* thread #1, name = 'sqlitetest', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x0000000000000000

I am using Debian x86_64

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

My build.zig is

const Builder = @import("std").build.Builder;

pub fn build(b: *Builder) void {
    // Standard target options allows the person running `zig build` to choose
    // what target to build for. Here we do not override the defaults, which
    // means any target is allowed, and the default is native. Other options
    // for restricting supported target set are available.
    const target = b.standardTargetOptions(.{});

    // Standard release options allow the person running `zig build` to select
    // between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall.
    const mode = b.standardReleaseOptions();

    const exe = b.addExecutable("sqlitetest", "src/main.zig");
    exe.linkSystemLibrary("sqlite3");
    exe.setTarget(target);
    exe.setBuildMode(mode);
    exe.install();

    const run_cmd = exe.run();
    run_cmd.step.dependOn(b.getInstallStep());

    const run_step = b.step("run", "Run the app");
    run_step.dependOn(&run_cmd.step);
}

and I am (I believe) using zig build's pkg-config support to link sqlite.

[LemonBoy]

You're missing exe.linkSystemLibrary("c").

[pedro-w]

Thanks, that fixed the seg fault...

... but now I get

Build Dependencies...lld: error: /usr/lib/x86_64-linux-gnu/libsqlite3.so: undefined reference to fcntl64

However this is a different problem and seems to be specific to sqlite3.

[LemonBoy]

That's weird as I've just tested the very same code you're using on the same Linux distribution.
What's your Zig version?

[pedro-w]

It's 0.6.0, specifically 0.6.0-1 installed by apt, using the instructions here. My sqlite is libsqlite3-dev, 3.27.2-3.

[LemonBoy]

I guess the problem has been fixed sometimes between the time 0.6.0 came out and, well, today. Can you check if the problem is gone with a compiler built from git?

[pedro-w]

Will do. I also just checked the one from the download page, zig-linux-x86_64-0.6.0+26140678a.tar.xz. This had the same linker error.

[pedro-w]

Confirmed I don't get that error if I build zig myself from git master (however, looking at the output from zig version it seems like it's the same source used to build zig-linux-x86_64-0.6.0+26140678a.tar.xz, which didn't work)

[pedro-w]

Not sure if this will help but I did zig build --verbose-link for 0.6.0 and for git master, and spread the output over several lines
Master has these directories

-L /usr/local/lib64
-L /usr/local/lib
-L /usr/lib/x86_64-linux-gnu
-L /lib64
-L /lib
-L /usr/lib64
-L /usr/lib
-L /lib/x86_64-linux-gnu

and 0.6.0 has these:

-L /usr/local/lib
-L /usr/local/lib64
-L /usr/lib/x86_64-linux-gnu
-L /lib
-L /lib64
-L /usr/lib
-L /usr/lib64
-L /lib/x86_64-linux-gnu

everything else is the same (apart from the generated dir names in the cache)
You can see the 64-bit ones come second in 0.6.0

[komuw]

the change in directory order is probably; 2148336

[pedro-w]

@komuw I agree, thanks for pointing that out.

Sorry to be labouring the point but I can't figure out why zig built by me worked, and the downloaded tarfile did not, even though both showed exactly the same zig version, ie. 0.6.0+26140678a (I assume that last part is a hash, implying they should have exactly the same source) Am I missing something?

edit: both zig built by me and the tarball have exactly the same ordering of -L flags in the linker command line

[aniljava]

Same problem in version 0.6.0+e60939bfa as well.

#5882

[faraazahmad]

GLFW C library working fine with zig 0.7.1 on Manjaro

[pedro-w]

@faraazahmad if you could test with sqlite, that would be useful as Manjaro is not based on Debian so might tell us something.
@andrewrk is this issue the same as #5882 actually, so we could close this in favour of that one?

[faraazahmad]

@pedro-w I just ran the exact code as in the top of this issue with sqlite and it ran fine

[pedro-w]

This now works on Debian 11 and Zig 0.10.0-dev.946+9dd839b7e
(test code changed slightly to reflect differences between 0.6 and 0.10)

const std = @import("std");
const s = @cImport({
    @cInclude("sqlite3.h");
});

pub fn main() anyerror!void {
    std.log.info("All your codebase are belong to {s}.", .{s.sqlite3_libversion()});
}

[pedro-w]

As far as I can see this can be closed because the issue is fixed / zig has moved on anyway.