addStaticLibrary results in 8-byte .a/.lib file

[green crater]

These result in basically an empty static (or even dynamic with addSharedLibrary) file when its supposed to generate one with the exported inc_many function. Would like to know if i'm missing something in the build.zig or if it's an actual bug to make an issue for.

build.zig:

const std = @import("std");

pub fn build(b: *std.Build) void {
    const optimize = b.standardOptimizeOption(.{});
    const target = b.standardTargetOptions(.{});

    const lib = b.addStaticLibrary(.{
        .name = "adder",
        .target = target,
        .optimize = optimize,
    });

    const dep = b.addStaticLibrary(.{
        .name = "add",
        .target = target,
        .optimize = optimize,
    });

    dep.addCSourceFile(.{ .file = .{ .path = "./add.cpp" }, .flags = &.{} });

    dep.linkLibCpp();
    lib.linkLibrary(dep);
    b.installArtifact(lib);
}

add.cpp:

#include <cstdint>
#include <cstddef>

extern "C" {
    // Something vectorizable to have a large binary output on -O3
    void inc_many(uint32_t* array, size_t len) {
        if (len == 0 || len % 8 != 0) return;
        for (size_t i = 0; i < len; i++)
            array[i] += 1;
    }
}

cc @hollow pelican

[gleaming herald]

Wouldn't you need to force extern "C" on C++ stuff?

[green crater]

good point. lemme add it to the example. The issue still persists though

[hollow pelican]

@green crater thanks for @ me. Hopefully there is a fix

[gleaming herald]

Isn't this the case of symbol gc?

[slate wagon]

yeah you either have to change the visibility of that symbol or the default visibility, specifically when creating libraries

[green crater]

Tried __attribute__((visibility(default)) should it be something else?

Or is there a way to disable GC symbols?

[slate wagon]

where did you put it?

[green crater]

__attribute__((visibility(default)) 
void inc_many(uint32_t* array, size_t len) {
 ...
}

[carmine temple]

uhmm wouldn't you normally have a file in lib that uses some of the stuff exposed by dep? in this example lib doesn't even have any file in it at all

[green crater]

yea, although trying to use the static lib as an archive/linker, with the deps being separate to compile in parallel. Should it all be under the same lib?

seems like linkLibrary() symbols are GC'd if they arent used by the top-level library? (it works if you have all source files compile into top-level)

[carmine temple]

far from being an expert but that makes sense to me, like you wouldn't want symbols from a dependency of a dependency to randomly (and most probably erroneously) satisfy a symbol requirement two levels above

[green crater]

is a linker-esque build graph not a supported feature of zig build?

also, @hollow pelican ^ fix is removing the intermediary addStaticLibrary, linkLibCpp, linkLibrary and do addCSourceFiles on lib itself

[carmine temple]

I think you can get that by adding dep as a sibling to whatever other dependency you're adding, instead of putting it as a dependency of a dependency

like if you're creating an executable that depends on lib1 lib2 and lib3, you just add them all to the final exe step and this way it gets access to all their symbols

[green crater]

the end goal is an archive / library rather than an exe (this is what the duckdb cmake build generates)

[hollow pelican]

Yes. The official duckdb releases shared library but id like to have a static library

[hollow pelican]

Did you update your build.zig? If not I'll update mine and test

[green crater]

Update the one in ur branch, so that itll include the fix