Unlinking Libraries?

Brainstorming
, ,
1

Part question, part idea. Apologies in advance if this is obviously silly, I’m not very familiar with linking in general.

I’ve been cross-compiling for Android lately, and I’ve had to manually modify a lot of build.zig files to not link libraries (or versions of libraries) that are unsupported on Android. I’m wondering:

  • A) If there’s an approach I’m missing
  • B) If it would be possible to add a simple way to unlink libraries to std.Build

It’s already fairly simple to add additional include directories and link additional libraries from the calling build.zig, so it seems possible?

I understand that adding support for a target is not necessarily this simple (for instance, many stdlib functions don’t work properly on Android) but something like this would simplify many cases.

2

I don’t think there is solution for this, currently.
Maybe a method for unlinking a library would not be the best approach. If the code is not using anything from the library, the linker would be happy, the problem is the build system, that doesn’t know what the linker will or won’t need. Perhaps the best solution would be for the build system to not complain if a library is missing until the linker actually requests it.

1 Like
3

There is target.result.abi.isAndroid()

E.g.

const target = b.standardTargetOptions(.{});

if (target.result.abi.isAndroid()) {
    //...
}
4

I got a similar request for sokol-zig, which we solved with a ‘dont_link_system_libraries’ build option, which can then be set by upstream projects if they want to define linker dependencies themselves:

As a general build system feature this could be a build step flag which prevents linker dependencies from propagating upward (e.g. you could block upward propagation in a specific place in the build tree from within the top-level build.zig).

4 Likes
5

For sure, but this has to be added to the build.zig of the upstream dependency in a lot of cases. I’m curious about my options as a consumer of a given library

6

I see. So the problem isn’t necessarily with, for instance, lld? That makes it seem like it would make it easier to change the build system API, not harder. Unless I’m misunderstanding.

7

When a library is not found, the build system aborts. It never gets to compilation and linking. It’s not necessarily the build system’s API that needs changing, it could be just it’s internal implementation.

1 Like
8

But isn’t that desired behaviour in most cases? If building for a relatively standard target, most people would prefer to get errors if they don’t have the right libraries available. I don’t doubt that you’d have to change internals, but you’d want the alternate behaviour to be triggered by a flag or function call.

9

I don’t know. You probably want library writers to link everything their code might need, to save downstream users from having to worry about that. But if the user is not actively using a certain deoendency, it would be best to not complain if such dependency is missing and let compilation move forward.

1 Like
10

For this I don’t agree. If the linker can’t find a library it should be a build error. But see my comment above about being able to stop propagation of link dependencies.

E.g. the fact that you can add link dependencies to libraries/modules which then propagate upward to the executable targets is a very nice convenience feature of the Zig build system, since users of library/module dependencies don’t need to worry about linker requirements of a library, but it can clash with exotic use cases. Simply being able to stop the propagation in specific places of the build tree from the top level build.zig would be a solution (it would be nice if this ability to override build tree settings in the top level build zig would be a general feature for all build step options).

2 Likes