tribals
commented
6 months ago Guix exports LIBRARY_PATH especially for that purpose:
$ ./pre-inst-env guix shell -D zig@0.11 --search-paths | grep LIBRARY
export LIBRARY_PATH="/gnu/store/dy0hhdbz7z2gzy57m0jz9zdl6543dymm-profile/lib${LIBRARY_PATH:+:}$LIBRARY_PATH"Tried to solve it this kind of "way" (only to be sure this action actually solves anything):
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 92be8fbfe..d3794f189 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -863,6 +863,15 @@ endif()
# -Dno-autodocs is currently hardcoded because the C backend generates a miscompilation
# that prevents it from working.
# To obtain these two forms of documentation, run zig build against stage3 rather than stage2.
+string(REPLACE ":" ";" LIBRARY_PATH "$ENV{LIBRARY_PATH}")
+set(SEARCH_PATHS "")
+
+foreach(PATH ${LIBRARY_PATH})
+ list(APPEND SEARCH_PATHS "--search-prefix ${PATH}")
+endforeach()
+
+list(JOIN SEARCH_PATHS " " SEARCH_PREFIXES)
+
set(ZIG_BUILD_ARGS
--zig-lib-dir "${CMAKE_SOURCE_DIR}/lib"
"-Dconfig_h=${ZIG_CONFIG_H_OUT}"
@@ -877,6 +886,7 @@ set(ZIG_BUILD_ARGS
"-Dtarget=${ZIG_TARGET_TRIPLE}"
"-Dcpu=${ZIG_TARGET_MCPU}"
"-Dversion-string=${RESOLVED_ZIG_VERSION}"
+ ${SEARCH_PREFIXES}
)
add_custom_target(stage3 ALLBut stuck with the way cmake's set handles its "arguments" (I'm completely newbie to cmake, but its declarative nature makes it not so hard):
zilti
Zig Version
Steps to Reproduce and Observed Behavior
I'm trying to package Zig 0.11 on Guix: currently, there is only 0.10 available, and I believe 0.11 is major step forward. To what, indeed?
I've already tried to package zig when there was only 0.9 (and I was trying 0.10). That time I failed, and now, with 0.11 release out - with it comes new self-hosting compiler.
Compilers! Especially self-hosting! What would be even more interesting?
I've really enjoyed reading a blog post explaining approach Zig has been taken with self-hosting problem. (If you didn't mind, self-hosted compilers usually become a major obstacle for distro maintainers & packagers. They also create funny chain of dependency on it's "previous self", which is also major impact to problem surface packagers tries to solve.)
I also really appreciate how Zig Build System tries to integrate with the world. And, finally, building a compiler with it's build system with just one command is really pleasurable.
So, what is the bug, and how to reproduce it? Here is a Guix Package definition, which one can use to reproduce this bug:
Save it to any location, and then use with
guix buildcommand's--fileoption (notezig-0.11variable at the end of such a file):Build process will be finished successfully, but
checkphase will fail because ofzig3improperly linked with system libraries (command used to buildzig3just for convenience):Why so?
It is dynamically linked executable, as expected (and supposed by) Guix build process.
It is not only linked against system-wide libraries, but also missing one completely (that one is from
ZIG_CLANG_LIBRARIESlist).The problem is that, whenever
zig2get's built with "system compiler" - all the dependencies properly resolved thanks to cmake. But whenzig buildkicks in - this integration get's lost. Although I read carefully Zig Build System documentation, and there is--search-prefixoption tozig build, I didn't find any way to propose those search prefix(es) from cmake part, which is actually used to build compiler: it has a bunch of options which one can set withcmake -DZIG_SHARED_LLVM=ONetc, but cmake has no any attempt to propagate discovered libraries tozig build, IIUC (from readingbuild.zigof0.11.0tag, and sporadicstd.buildchunks).Although I managed to pass those
--search-prefixes to./zig2 build ...while debugging, it seems like that has no effect at this particular problem:zig3get's linked against system libraries no matter what I pass to--search-prefix.I did some search of similar issues before opening this one, here some examples:
All they relate in some way to proper discovery of libraries (and headers) when one do choose to build from source, but mostly system-specific: there is no problem with libraries discovery when
zig2get's built with system compiler whenever one's system compiler is able to properly discover shared libraries. There is no such problem on Guix:The problem is that there is no way to communicate desired choices of libraries to
./zig2 buildusingcmake.Also, note there was attempts (in Guix) to patch
std.buildto properly handle library discovery, using mechanism known as "search paths" (meaning that there was attempt to make zig respect some C-related well-defined search paths).I think, this again touches the same pain point. What do you think?
I opening this bug here, in Zig upstream because I believe this is a Zig problem - not eg. Guix. Also, from the packager point, there is no room to "fix" this using Guix build process: all one can do is to resort to patching of cmake's generated build files, which I think is no-option in Guix upstream.
Expected Behavior
Zig 0.11.0 get's built with provided Guix Package definition, with
zig3's executable dynamically linked against Guix shared libraries (package inputs).