-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
glibc 2.27 or older: fcntl64 not found, but zig's glibc headers refer it #9485
Comments
GCC Flag --target=x86_64-linux-gnu.2.27 See also ziglang/zig#9485
if https://patchwork.sourceware.org/project/glibc/patch/20220129023727.1496360-1-andrew@ziglang.org/ gets merged, I will attempt do to an equivalent thing for |
The solution provided in 5882 didn't fully work for me when building CPython. Therefore, I tried something similar to 39083c3: --- zig_linux_x86.orig/lib/libc/include/generic-glibc/fcntl.h 2022-02-15 03:47:43.000000000 +0100
+++ zig_linux_x86.custom/lib/libc/include/generic-glibc/fcntl.h 2022-06-22 12:50:07.530393034 +0200
@@ -173,7 +173,7 @@
This function is a cancellation point and therefore not marked with
__THROW. */
#ifndef __USE_TIME_BITS64
-# ifndef __USE_FILE_OFFSET64
+# if (__GLIBC__ == 2 && __GLIBC_MINOR__ < 28) || !defined(__USE_FILE_OFFSET64)
extern int fcntl (int __fd, int __cmd, ...);
# else
# ifdef __REDIRECT And the linking issue disappeared. However, the resulting binary behaves erratically (for instance, when the |
This issue not only impacts I would like to know if Glibc headers are included via automation or are hand tuned sometimes. Because the preprocessor conditionals may be the easiest way to solve this. In the case of |
Good point.
There is a precedent in 39083c3 ; but it's dangerous and it would be best to keep it at zero, since that will make glibc header updates error prone. I know @marler8997 started working on a proper solution to glibc headers, and this issue is high in our wishlist (but to my knowledge nobody in ZSF has prioritized it yet). |
While this issue is being considered. Is there a way to tell the Zig C driver to use the system's libc headers instead of the bundled ones? |
`res_search` became a proper symbol only in glibc 2.34. Until that it was re-defined in headers, hitting the (in-)famous ziglang/zig#9485 glibc 2.34+: resolv/resolv.h:int res_search (const char *, int, int, unsigned char *, int) Old glibc: resolv/resolv.h:#define res_search __res_search Also, remove the toplevel includes, as they should never be included in the first place: the headers are included explicitly when needed.
Yes. Just don't pass main.c #define _FILE_OFFSET_BITS 64
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
int main() {
printf("address to fcntl: %p\n", fcntl);
} Compile:
|
This workaround seems to "work-for-me": redirect_fnctl64_hack.zig: // work around glibc headers >= 2.28 no linking against older runtime library
// more info: https://microeducate.tech/how-to-force-linkage-to-older-libc-fcntl-instead-of-fcntl64/
extern fn fcntl() callconv(.Naked) i32;
pub export fn fcntl_zig_trampoline() callconv(.Naked) noreturn {
const builtin = @import("builtin");
if (builtin.target.isGnuLibC()) {
const ver = builtin.os.version_range.linux.glibc;
if (comptime ver.order(.{ .major = 2, .minor = 28, .patch = 0 }) == .lt) {
@export(fcntl_zig_trampoline, .{ .name = "fcntl64", .linkage = .Weak });
if (builtin.target.cpu.arch == .x86_64) {
asm volatile (
\\ jmp fcntl
);
} else {
@compileError("TODO");
}
}
}
unreachable;
} and add this to the build.zig script: const obj = b.addObject("fnctl64_hack", "redirect_fnctl64_hack.zig");
obj.setTarget(target);
obj.setBuildMode(.ReleaseFast);
exe.addObject(obj); (or I guess it's similarly possible with other build systems by using |
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see ziglang#9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now. Closes ziglang#9485 Related: 39083c3
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see ziglang#9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now. Closes ziglang#9485 Related: 39083c3
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see ziglang#9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now. Closes ziglang#9485 Related: 39083c3
I discussed this offline with @andrewrk and we agreed to do header ifdefs until universal-headers project is merged. #15101 adds header conditionals to fix |
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see ziglang#9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now. Closes ziglang#9485
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see ziglang#9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now. Closes ziglang#9485
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see #9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now.
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see #9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now.
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see #9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now.
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see #9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now.
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see #9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now.
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see #9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now.
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see ziglang#9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now.
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see ziglang#9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now.
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see ziglang#9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now.
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see ziglang#9485) - `res_{,n}{search,query,querydomain}` became "their own" symbols since glibc 2.34: they were prefixed with `__` before. This PR makes it possible to use `fcntl` with glibc 2.27 or older and the `res_*` functions with glibc 2.33 or older. These patches will become redundant with universal-headers and can be dropped. But we have to do with what we have now.
TLDR: zig is using "too new" glibc headers, which sometimes references undefined symbols. This fails compilation for at least sqlite and libuv when older glibc is selected, because it redefines
fcntl
tofcntl64
, which is present only in newer glibcs.main.c
This fails when target is glibc 2.27 or older:
And works with glibc 2.28+:
This task gives a small reproducible test case; the problem was well explained in #5882 (comment) , includes a workaround (for x86_64 only though). While the workaround works, it may be nicer if zig provided headers of the requested version, and make this problem go away?
The text was updated successfully, but these errors were encountered: