Skip to content
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

Feature request: libc header import without libc library import #7687

Closed
ityonemo opened this issue Jan 4, 2021 · 5 comments
Closed

Feature request: libc header import without libc library import #7687

ityonemo opened this issue Jan 4, 2021 · 5 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@ityonemo
Copy link
Contributor

ityonemo commented Jan 4, 2021

For FFIs which use C ABI as a least common denominator, but I'm sure also some header-only C libraries, may not use any stdlib externs, but might still need accoutrements of the C stdlib headers (e.g. types.h). It might be nice to provide a way to leverage zig's header resolution logic without doing linkSystemLibrary("c") which would unnecessarily bring in libc into the project.

@matu3ba
Copy link
Contributor

matu3ba commented Jan 5, 2021

Probably the documenation (#1596) should be finished first. Just curious: Is identifying manually the header files, which dont depend on libc, that difficult?

@ityonemo
Copy link
Contributor Author

ityonemo commented Jan 5, 2021

Yeah, it gets tricky (but not impossible) if you want cross-compilation to be possible.

@Vexu Vexu added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Jan 26, 2021
@Vexu Vexu added this to the 0.8.0 milestone Jan 26, 2021
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 May 19, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 23, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@iacore
Copy link
Contributor

iacore commented Jun 12, 2023

As a workaround, use musl.

@andrewrk andrewrk modified the milestones: 0.13.0, 0.12.0 Jul 9, 2023
@matklad
Copy link
Contributor

matklad commented Jun 26, 2024

Appaerntly, if you don't link to libc, but just have some -I entry, it works?

Here's my "C" library with a header file which doesn't really depend on libc at runtime:

λ bat mylib.h
#include <stdint.h>

int64_t get_number();

λ bat mylib.zig
export fn get_number() u64 {
    return 92;
}

λ zig build-lib mylib.zig

Here's the Zig code which imports the header

λ bat main.zig
const std = @import("std");
const c = @cImport(@cInclude("./mylib.h"));

pub fn main() void {
    std.debug.print("{}", .{c.get_number()});
}

If I just try to compile it, I get the error I expect to get given this issue:

λ zig build-exe main.zig libmylib.a.o
main.zig:2:11: error: C import failed
const c = @cImport(@cInclude("./mylib.h"));
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
main.zig:2:11: note: libc headers not available; compilation does not link against libc

That is: no cImport if you don't link libc!

But, if I add -I for my header, this somehow gets it to work!

λ zig build-exe main.zig libmylib.a.o -I. && ./main
92
λ ldd ./main
	not a dynamic executable

Notably, not only Zig is able to find my mylib.h, but internal clang is able to find <stdint.h>. looking at --verbose-cimport, it seems that it uses the correct stint.h:

λ bat /home/matklad/tmp/.zig-cache/o/e4d0a93094219ef8a9216d4c64d1b94a/cimport.h.d
cimport.o: \
  /home/matklad/tmp/.zig-cache/o/e4d0a93094219ef8a9216d4c64d1b94a/cimport.h \
  mylib.h /home/matklad/p/tb/work/zig/lib/include/stdint.h

So it looks like this might have been mostly fixed as of Zig 0.13, and only the error message needs to be adjusted: it's not about libc headers, it's about the parcitular header you try to cImport

EDIT: further investigation shows that <stdint.h> works, but <stdio.h> doesn't (it fails with libc headers not available). This seems precisely the behavior we want here, but I am very puzzled about how this could work, I thought that C headers don't make distinction between "this is a stand-alone headers" and "this requires a c runtime library"?

@andrewrk
Copy link
Member

Expected to be solved by #20630

@andrewrk andrewrk closed this as not planned Won't fix, can't repro, duplicate, stale Jul 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

6 participants