Neither way can build zig w/o SegFault #21941
Comments
lefsha
added
the
bug
|
|
After following https://github.com/ziglang/zig-bootstrap and then trying https://github.com/ziglang/zig/wiki/Building-Zig-From-Source#option-b-use-a-pre-built-zig-binary, I can confirm it is sefaulting on my system as well. Linux Pop OS 22.04 |
|
How does it related to Gentoo? I see zero relation whatsoever! I have used all possible ways to build zig. All of them Please, read the report again. I will not report this bug to Gentoo, because it is not their issue. How that is related to ANY CFLAGS in the system if Zig stage3 is built by.... ZIG stage2 with what ever ZIG flags used by developers? ZIG is a statically linked binary. No one can blame wrong system modules. The same issue persist with CFLAGS="" - empty string. It is not related at all. I was trying any CFLAGS and total absence of them. I was using tigerlake, alderlake and generic CPU - no difference. I was trying to search for bugs and added sanitize and debug built, but I have failed already at zig-wasm, which I have reported previously. Andrew mentioned it is by design. I am sorry I cannot use buggy language in production which has such primitive design issues and no one feels like being responsible, not even the creator. I hate C++, but I have literally no other choice.
Binary version downloaded from ziglang, which is the same available from dev-lang/zig-bin works fine. I have used 5x versions of LLVM:
I did everything and tried everything I ever could to build zig w/o success. The problem is always the same This report came after 2-3 months playing with zig. I am done. I cannot do that anymore. I remember I was able to build old 0.7 or 0.9 version, but not anymore.
zig env { zig build-exe --show-builtin const std = @import("std"); pub const output_mode = std.builtin.OutputMode.Exe; |
|
@lefsha i don't know if this would help you but after having some trouble building zig from source I eventually succeeded with the use of nix to pull in the build dependencies: https://github.com/mocompute/zig/tree/dev/nix |
"target": "x86_64-linux.6.6.58...6.6.58-musl",.glibc = .{
.major = 2,
.minor = 28,
.patch = 0,
},Can you please also:
|
That is own ZIG issue. IDK why it shows that information:
ldd /usr/bin/env qfile /usr/bin/env
./zig-libc-test
./zig-libc-test
./zig-libc-test |
Is
Yes, but this is supposed to be fixed in 0.13 and later versions: #19749 . And it works for me, no matter with or without $ zig targets | jq '.native.triple'
"x86_64-linux.6.11.5...6.11.5-gnu.2.39"
$ zig env | jq '.target'
"x86_64-linux.6.11.5...6.11.5-gnu.2.39"
$ zig build-exe --show-builtin
// ...
pub const abi = std.Target.Abi.gnu;
// ...
pub const os = std.Target.Os{
.tag = .linux,
.version_range = .{ .linux = .{
.range = .{
.min = .{
.major = 6,
.minor = 11,
.patch = 5,
},
.max = .{
.major = 6,
.minor = 11,
.patch = 5,
},
},
.glibc = .{
.major = 2,
.minor = 39,
.patch = 0,
},
.android = 14,
}},
};
pub const target: std.Target = .{
.cpu = cpu,
.os = os,
.abi = abi,
.ofmt = object_format,
.dynamic_linker = std.Target.DynamicLinker.init("/lib64/ld-linux-x86-64.so.2"),
};And we have same |
[binary R ] sys-apps/coreutils-9.5::gentoo USE="acl (-caps) -gmp -hostname -kill -multicall -nls openssl (-selinux) (split-usr) static (-test) -vanilla -verify-sig (-xattr)" 0 KiB It is not enabled. Likely zig-bin has been built against glibc 2.28, that is why it does report this. Still that must be a bug. If only one program generates SegFault, than it is guilty. Andrew seems not to care about Developers don't care to develop - users don't care to use. That is trivial and simple. On the same machine I can build RUST w/o any problem and it works using the same LLVM. Only once, when I transferred binaries from Tigerlake to Alderlake I had it, but that is only because Intel switched off avx512 at Alderlake despite being released later.
"x86_64-linux.6.6.58...6.6.58-gnu.2.39"
Now I have the same - 2.39 like above |
|
WOW! I have rebuilt coreutils w/ USE=-static and suddenly it starts working. No other package on the system had any sensitivity to that. It seems like zig is using coreutils in a special way I could not even imagine that this USE flag from another package would have such a influence. Thanks to BratishkaErik who made me thinking into that direction. Still I would consider that is ZIG bug. |
I think it's (missing) dynamic linker that causes segfault here and not program code itself. You could do same with
If you meant memory leaks in wasm2c, it does not causes your issue here, freed up by system anyway and insignificant compared to how many RAM
Yes, 2.28 was reported because it's default version when cross-compiling glibc (which is enabled cause it couldn't detect yours), and 2.39 is reported because of specifics of detecting $ readelf --string-dump='.dynstr' /lib64/libc.so.6 | grep --only-matching 'GLIBC_.*'
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_2.18
GLIBC_2.22
GLIBC_2.23
GLIBC_2.24
GLIBC_2.25
GLIBC_2.26
GLIBC_2.27
GLIBC_2.28
GLIBC_2.29
GLIBC_2.30
GLIBC_2.31
GLIBC_2.32
GLIBC_2.33
GLIBC_2.34
GLIBC_2.35
GLIBC_2.36
GLIBC_2.38
GLIBC_2.39
GLIBC_ABI_DT_RELR
GLIBC_PRIVATEAs you can see, on Glibc 2.40 we have symbols up to 2.39, on 2.39 up to 2.38 etc., that's why detection lags a bit behind. But it's not critical.
Good it works for you now :)
Yes, because it checks
I can:
|
we are not talking about ANY binary made by ZIG. We are talking about ZIG stage3 itself! Nothing prevents me to build zig against musl or glibc in the same system. The detection of whether glibc is the core c-lib or musl is unrelated to coreutils built statically. At least no other program or language like RUST has no such an issue.
Well, I just turned on all possible debug flags to track down the issue with stage3, but I was not able to get there, because it faulted earlier. So I have reported that.
Yes. And that is a WRONG assumption. One cannot assume system is running on musl because of statically linked binary, which is fully unrelated to glibc. I can build bash also statically linked, so what? I do personally prefer always statically linked binaries if I can make them. It doesn't mean I am not using glibc unfortunately.
Yes, you can and should add this dependency for dev-lang/zig package, but not for dev-lang/zig-bin - it is unaffected.
Not really. Bash can be statically linked - no problem. Why should anyone check if a program is statically linked or not? I do have both at my system... so what? |
zig-bin is affected at runtime, as you checked by yourself — when compiling https://github.com/BratishkaErik/zig-libc-test, there is a segmentation fault because dynamic interpeter and libc are added wrongly. So yes, it applies to every binary that is compiled with Zig and linked to libc, including LLVM-enabled Zig compiler itself.
It is not a statically linked binary in Gentoo ebuild, it's dynamically linked binary that uses at least libllvm and libclang, and C++ and C standard library. There is no static LLVM in gentoo repository.
In this case, I can suggest you to try to set target exactly, not letting Zig detect it wrongly, by using ZIG_TARGET="native-native-gnu.2.39"
# or musl if you want it and LLVM is using muslThen BTW, are you the "Alexey Ivanov" user who was writing in https://t.me/ziglang_en on August with similar problem? |
|
Are there any updates on this issue? I'd love to test my changes to add thin lto but I can't build due to segfaults :/ |
I think your problem is different, because it detects libc and other information correctly. What kind of segfault do you have? If its smth like "unsupported instruction" it can be a wrong detected CPU (it shows znver3 for you currently), in this case you can try to compile using older |
How do I tell it to do this? Looking at the build instructions here: https://github.com/ziglang/zig-bootstrap?tab=readme-ov-file#build-instructions Am I supposed to pass |
|
I tried building with this command: |
|
@BratishkaErik That got me past the segualts! :) Thank you! :) |
|
If one would really want to check some binary for being statically linked, shouldn't one instead use one actually being packaged with % qlist glibc | grep /usr/bin
/usr/bin/getconf
/usr/bin/ld.so (*)
/usr/bin/pldd
/usr/bin/sprof
/usr/bin/sotruss (*)
/usr/bin/ldd (*)
/usr/bin/makedb
/usr/bin/getent
/usr/bin/xtrace (*)
/usr/bin/pcprofiledump
/usr/bin/mtrace (*)
/usr/bin/gencat
/usr/bin/localedef
/usr/bin/locale
/usr/bin/iconv(those marked with (*) aren't recognized as shared linked by ldd, so wouldn't work) |
Zig Version
latest
Steps to Reproduce and Observed Behavior
using standard emerge zig at Gentoo produces:
/var/tmp/portage/dev-lang/zig-9999/temp/environment: line 3320: 12302 Segmentation fault "${BUILD_DIR}/stage3/bin/zig" env
with any zig version!
The problem arise at zig stage3, which ends up with generating Segmentation fault
generates:
==30791== Memcheck, a memory error detector
==30791== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==30791== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==30791== Command: ./zig
==30791==
==30791== Jump to the invalid address stated on the next line
==30791== at 0x0: ???
==30791== by 0x12A7B44: ??? (in /var/tmp/portage/dev-lang/zig-9999/work/zig-9999/build/stage3/bin/zig)
==30791== by 0x1FFEFFF027: ???
==30791== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==30791==
==30791==
==30791== Process terminating with default action of signal 11 (SIGSEGV)
==30791== Bad permissions for mapped region at address 0x0
==30791== at 0x0: ???
==30791== by 0x12A7B44: ??? (in /var/tmp/portage/dev-lang/zig-9999/work/zig-9999/build/stage3/bin/zig)
==30791== by 0x1FFEFFF027: ???
==30791==
==30791== HEAP SUMMARY:
==30791== in use at exit: 0 bytes in 0 blocks
==30791== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==30791==
==30791== All heap blocks were freed -- no leaks are possible
==30791==
==30791== For lists of detected and suppressed errors, rerun with: -s
==30791== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
The same happens if building zig manually by using git repos:
https://github.com/ziglang/zig
or
https://github.com/ziglang/zig-bootstrap
No other similar kind of issues are detected on my Gentoo system despite several thousands packages installed.
reproducible with 2x laptops with Tigerlake and Alderlake CPUs, 64Gb RAM each.
Expected Behavior
No SegFault
The text was updated successfully, but these errors were encountered: