std.Build: add support for adding specific global search paths#22552
std.Build: add support for adding specific global search paths#22552BratishkaErik wants to merge 2 commits into
Conversation
ffd95f4 to
47c69de
Compare
|
aarch64-linux-debug failure seems to be a regular |
47c69de to
d759b1e
Compare
d759b1e to
836795d
Compare
|
I like where this is going overall; seems obviously useful to distro maintainers. @andrewrk should probably have a look too though. |
836795d to
ebd8dd0
Compare
alexrp
left a comment
There was a problem hiding this comment.
LGTM, but will let Andrew have a look also.
| includes: ?LazyPath = null, | ||
| }; | ||
|
|
||
| pub fn binaries(self: SearchMethod, b: *std.Build) ?LazyPath { |
There was a problem hiding this comment.
Maybe LazyPath is not the most suitable choice here? They are used by findProgram in configure phase, and so can't have generated LazyPath.
ebd8dd0 to
8d4457f
Compare
Signed-off-by: Eric Joldasov <bratishkaerik@landless-city.net>
This allows more granularity when adding search paths, complementing
`--search-prefix` for more specific use-cases.
## Multi-arch library layout
On systems with multilib support (e.g. Gentoo with 32-bit and 64-bit
libraries in `/usr/lib` and `/usr/lib64` respectively), using
`--search-prefix` option can cause incorrect library selected.
For example, if I want to link system `libcurl` library when building
Zig program for non-native or explicit native-compatible target,
I can try using `--search-prefix /usr`, which will automatically add:
* `/usr/bin` as search path for binaries (fine),
* `/usr/lib` as search path for libraries (incorrect),
* `/usr/include` as search path for includes (fine),
In my case it will find 32-bit libraries for 64-bit target, causing
linker errors:
```console
$ zig build -Dtarget=x86_64-linux-gnu.2.35 --search-prefix /usr
error: ld.lld: /usr/lib/libcurl.so is incompatible with elf_x86_64
```
New `--search-paths` option allows to add search paths explicitly,
using passed ZON file as a specification. You can repeat multiple
times to add many different search paths if needed.
```zig
.{
.binaries = "/usr/bin"
.libraries = "/usr/lib64",
.includes = "/usr/include",
}
```
## Other layouts (GCC or Android NDK etc.)
Another use-case is when binaries, libraries and includes are
distributed across different hierarchies. Suppose I want to correctly
find `gcc` binary and link `gccjit` library for my project:
```zig
.{
.binaries = "/usr/x86_64-pc-linux-gnu/gcc-bin/14/",
.libraries = "/usr/lib/gcc/x86_64-pc-linux-gnu/14",
.includes = "/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/",
}
```
Or use Android NDK:
```zig
.{
// you can omit fields or set `null` if you don't want to search them.
// .binaries = null,
.libraries = "/path_to_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/35",
.includes = "/path_to_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include",
}
```
```zig
.{
.libraries = "/path_to_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android",
}
```
Signed-off-by: Eric Joldasov <bratishkaerik@landless-city.net>
8d4457f to
508ae85
Compare
|
This will have to be resubmitted on Codeberg once https://codeberg.org/ziglang/zig/issues/31691 is done. (We currently have a moratorium on |
This allows more granularity when adding search paths, complementing
--search-prefixfor more specific use-cases.Multi-arch library layout
On systems with multilib support (e.g. Gentoo with 32-bit and 64-bit
libraries in
/usr/liband/usr/lib64respectively), using--search-prefixoption can cause incorrect library selected.For example, if I want to link system
libcurllibrary when buildingZig program for non-native or explicit native-compatible target,
I can try using
--search-prefix /usr, which will automatically add:/usr/binas search path for binaries (fine),/usr/libas search path for libraries (incorrect),/usr/includeas search path for includes (fine),In my case it will find 32-bit libraries for 64-bit target, causing
linker errors:
New
--search-pathsoption allows to add search paths explicitly,using passed ZON file as a specification. You can repeat multiple
times to add many different search paths if needed.
.{ .binaries = "/usr/bin" .libraries = "/usr/lib64", .includes = "/usr/include", }Other layouts (GCC or Android NDK etc.)
Another use-case is when binaries, libraries and includes are
distributed across different hierarchies. Suppose I want to correctly
find
gccbinary and linkgccjitlibrary for my project:.{ .binaries = "/usr/x86_64-pc-linux-gnu/gcc-bin/14/", .libraries = "/usr/lib/gcc/x86_64-pc-linux-gnu/14", .includes = "/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/", }Or use Android NDK:
.{ // you can omit fields or set `null` if you don't want to search them. // .binaries = null, .libraries = "/path_to_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/35", .includes = "/path_to_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include", }.{ .libraries = "/path_to_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android", }