Control the library name prefix

Trying to compile a C library, I don’t want the library name to be prefixed by “lib”.

This works, but I wanted the opinion of the forum:

    const output_name = b.fmt("zlib{s}", .{ lib.root_module.resolved_target.?.result.staticLibSuffix() });
    const install_step = b.addInstallArtifact(lib, .{
        .dest_dir = .{
            .override = .lib,
        },
        .dest_sub_path = output_name,
    });
    b.getInstallStep().dependOn(&install_step.step);

Is that idiomatic? Is there a better way?

I would just keep the platform default, do you have any good reason to pick a different name, instead of just personal preference?

You might create more problems for yourself and others, who later want to use the library and expect it to have the default name.

zlib is named this way. It will create way more problems if I try to change its name.

The library is called zlib but when I look at the library artefacts pacman -Ql zlib:

zlib /usr/lib/libz.a
zlib /usr/lib/libz.so
zlib /usr/lib/libz.so.1
zlib /usr/lib/libz.so.1.3.1

I guess under linux you could use “z” as name and have the libz as name as the result? But yes, would be annoying having to special case between linux and windows, which I assume should end up with zlib.dll?

Wait I am actually completely wrong. It produces libz.a.

Forget I asked. :slight_smile:

Yeah, on Unix systems (including Linux), when you link with ... -lfoo -lbar it actually searches for files named libfoo.a and libbar.a (or their shared counterparts).

Fun note: this is why this GNU library is called libiberty – not a typo! They wanted their link lines to look like ... -liberty. Talk about an excess of cuteness!

The question was in case a library does not generate the standard lib prefixed name. I thought that was the case of zlib and was wondering how to handle that idiomatically.

But as zlib actually works as any other lib, this becomes a moot question.