<stratact>
Hey folks, I'm interested in getting started with Zig and I think I found a great use for it. My question is, how does the "C-binding" functionality work? I'm interested in tapping into the xlib library on my FreeBSD system to get some X11 windowing data using Zig for a special use case.
<stratact>
I used to use Rust for a long time and I dropped it for various reasons, so I think Zig's syntax will come naturally to me.
bastienleonard has quit [Ping timeout: 252 seconds]
<curtisf>
Does anyone else use Zig on Windows? It looks like colors in output have become broken somewhere between 6ab8b2a and 57b90d2. Just started bisecting, but compiling takes a long time
<curtisf>
That's a good guess andrew. I'm double checking the commits before/after that PR.
<curtisf>
Relatedly, I noticed the `--color off` option also changes the format of the output, it doesn't just remove color. Should there be an option to just remove color but keep the snippet structure the same?
<andrewrk>
if that messed up colors, then we should probably just revert it, because the actual thing it did is planned to get reverted anyway
<andrewrk>
no offense to emekoi
<curtisf>
I haven't really looked into the structure of how zig is compiled, but what exactly takes so long to compile in it? It doesn't look like there's that much code for zig itself. Is it because of building using LLVM or another dependency?
<andrewrk>
LLD
<andrewrk>
until a few days ago we carried a bug fix patch in a fork. But after LLVM 10 (not llvm 9 which is coming out in a couple weeks) then we won't need a fork
<curtisf>
ah, so there's a fork of LLD in zig right now?
<curtisf>
that's exciting that this will improve
<daurnimator>
andrewrk: oh that patch isn't making it into LLVM 9? :(
<andrewrk>
it was a bit late
<meowray>
the patch (if D62185) can be a candidate for 9.0.1
<andrewrk>
nice
<meowray>
tell me if you run lld 9-linked zig executables on risc-v
<andrewrk>
ok :)
<andrewrk>
you can cross compile C executables with lld 9 with the llvm9 branch of zig
<andrewrk>
zig build-exe --c-source hello.c --library c -target riscv64-linux-musl
<meowray>
in my Dev/llvm-9.0.0rc2/Release/lib/cmake/llvm/LLVMConfig.cmake, LLVM_INCLUDE_DIRS includes both llvm-9.0.0rc2/include and llvm-9.0.0rc2/Release/include, but zig/cmake/Findllvm.cmake overwrites LLVM_INCLUDE_DIRS with llvm-config --includedir output
<andrewrk>
that looks like an unsupported way to build zig
<andrewrk>
the supported way mirrors how system package managers will build zig
<meowray>
can it use find_package(Clang REQUIRES)? that command justs reads LLVMConfig.cmake and ClangConfig.cmake
rohlem has left #zig [#zig]
<meowray>
just use *_INCLUDE_DIRS *_LIBS in LLVMConfig.cmake and ClangConfig.cmake, not output read from llvm-config, or FIND_AND_ADD_CLANG_LIB
<meowray>
there can be multiple versions of clang and llvm installed on a system, so you need to find a way to use the required LLVMConfig.cmake and ClangConfig.cmake
<meowray>
(-DCMAKE_PREFIX_PATH may do the trick.. though i know cmake too little to understand how things work
<andrewrk>
I recommend -DCMAKE_PREFIX_PATH. that's the way that works with all build systems, not just cmake
<andrewrk>
and in fact that's the only supported way
<andrewrk>
which means, do whatever you want, of course, but I'm not going to help troubleshoot building in a way other than the documented supported way
<meowray>
i was not asking for help. i was suggesting a simpler way that also also makes it easy for an llvm developer
curtisf has quit [Remote host closed the connection]
<meowray>
i still have to figure out why commenting out execute_process...LLVM_INCLUDE_DIRS does not work
alexander92 has quit [Ping timeout: 245 seconds]
<daurnimator>
andrewrk: have you thought about including BFLOAT16 support in zig?
<meowray>
daurnimator: "cmake: allow user to select static vs dynamic LLVM" what's the rationale behind this commit?
<meowray>
do you have an llvm install with both .a and .so ?
<daurnimator>
meowray: yes, and I wanted a way to force dynamic linking
<meowray>
how do you build both libLLVMCore.so and libLLVMCore.a?
<daurnimator>
meowray: .so was provided by distro (which I wanted to use) and .a via some other mechanism, I can't recall now
<meowray>
ok, so they are not from the same source. then i think this option should not be added
<daurnimator>
meowray: I'm not super familiar with cmake. If you don't think its correct then please send a patch for others to review
<meowray>
it is very rare that a distro provides .so but not .a
<daurnimator>
meowray: archlinux provides .so and not .a
<daurnimator>
(well; sort of)
<daurnimator>
To quote https://github.com/ziglang/zig/issues/2340 > Arch Linux has both static (libLLVM[[:alpha:]]+.a) and shared (libLLVM-8.so) libLLVM* libraries for LLVM. But it has only shared libclang[[:alpha:]]+.so libraries with the full C++ API for CLANG
<meowray>
daurnimator: on archlinux, extra/llvm provides libLLVM*.a, extra/llvm-libs provides the unified libLLVM.so (LLVM_LINKLLVM_DYLIB).
<meowray>
extra/clang provides libclang*.so that depend on libLLVM.so . it is broken if a project links in libLLVM*.a and libclang*.so
<meowray>
if you somehow linked in system libLLVM*.a with ZIG_STATIC_LLVM, you can run into various ODR issues because both libLLVM.so and libLLVM*.a are in the runtime image
<daurnimator>
meowray: see description of issue in issue 2340 linked above
<meowray>
i rememember the nick name https://github.com/winksaville, because he made a request on reviews.llvm.org and someone added a similar CLANG_BUILD_CLANG_DYLIB
<meowray>
daurnimator: i'm very clear about the matters and i'm working on a patch to simplify the cmake. i noticed the strange ZIG_STATIC_LLVM and you hapened to reply.. so i asked you
<daurnimator>
meowray: are you saying that archlinux should drop libLLVM*.a ?
<meowray>
no. i mean you cannot link in both libLLVM*.a and libclang*.so. libLLVM.so+libclang*.so can work if libclang*.so depend on libLLVM.so
<meowray>
ZIG_STATIC_LLVM on Arch Linux with extra/clang doesn't work
<daurnimator>
meowray: okay; but the issue was that the old cmake code would try and link llvm statically if `NOT(CMAKE_BUILD_TYPE STREQUAL "Debug")`
<daurnimator>
i.e. doing a "release" build would link against libLLVM*.a and libclang*.so; and hence fail
<daurnimator>
so I introduced `ZIG_STATIC_LLVM` as a way to say "never even try to statically link libLLVM"
<meowray>
llvm-config --libs --link-static with libLLVM*.so => error: missing .../libLLVM*.a ; llvm-config --libs --link-shared with libLLVM*.a => error: missing .../libLLVM*.so
<daurnimator>
meowray: okay I've done some more reading. looks like archlinux is waiting for the clang 9 release so they can start using CLANG_LINK_CLANG_DYLIB.
<meowray>
daurnimator: yes.. i'm preparing a patch to clean Find{llvm,clang}.cmake and add CLANG_LINK_CLANG_DYLIB
<daurnimator>
2019-07-12 03:19:46 andrewrk zig will never mangle the assembly code, it will either keep it or delete it (and it may not delete it if it has side effects)
<daurnimator>
meowray: I see you removed the ZIG_STATIC path: that requires static everything else
<daurnimator>
s/path/piece of code that forces static LLVM when static zig/
laaron has joined #zig
<meowray>
you cannot force static if your llvm does not provide libLLVM*.a
<daurnimator>
meowray: right; in which case we want the build to error
<daurnimator>
meowray: -DZIG_STATIC is meant to build a fully-static zig
<meowray>
you can use -static to achieve that..
<meowray>
it will error
<stratact>
daurnimator: thanks for the build.zig suggestion, that helped.
<meowray>
the option ZIG_STATIC_LLVM does not make lots of sense
<daurnimator>
meowray: yeah I understand about ZIG_STATIC_LLVM. I'm just not sure with your PR how ZIG_STATIC gets propagated through to pass -static
<meowray>
actually -DBUILD_SHARED_LIBS=on is reserved for developers. it is arch linux that is weird
<meowray>
on every other distro you get libLLVM*.a libclang*.a
<daurnimator>
meowray: correct. however arch has said they can't fix it until CLANG_LINK_CLANG_DYLIB is supported via release of clang 9 (which will be this month; so not long to wait!)
<meowray>
CLANG_LINK_CLANG_DYLIB cannot be used for ig now because embedded_lld.a is broken
<daurnimator>
meowray: is that not fixed upstream? (or in llvm9 branch?)
<meowray>
maybe you can do -DCMAKE_EXE_LINKER_FLAGS=-static to get an error? i don't know what's the idiomatic cmake approach
<meowray>
daurnimator: no. it's zig embedded_lld.a that is brken
<meowray>
i'm still investigating how you do embedded_lld.a ...
<daurnimator>
meowray: sorry I'm lost/maybe not paying enough attention.... what is the embedded_lld.a issue?
<meowray>
daurnimator: in any case... i don't think ZIG_STATIC_LLVM is the only problem. there are more serious ones: embedded_lld_lib is built with -fno-rtti
<meowray>
this does not work if some GCC versions if the system llvm/clang are built with -fno-rtti
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<Snektron>
andrewrk: I noticed std/os/linux.zig has setegid and seteuid, calling respectively SYS_setegid and SYS_setuid, yet no such syscall exists. According to the manpage of seteuid this is implemented as a call to setregid and setreuid.
masse_ has joined #zig
masse_ has quit [Remote host closed the connection]
mgld has joined #zig
wootehfoot has joined #zig
<stratact>
How do I convert a '[2]u8' to a '[*c]const u8'?
<daurnimator>
stratact: you don't convert it. but you can do & on it and it will get implicitly casted
<stratact>
ah fantastic
<stratact>
Sadly, that didn't work: error: expected type '[*c]const u8', found '*[2]u8'
<stratact>
I solved it, I had to add the & pointer, like you said, and do @ptrCast(*const u8, &":0") to cast the pointer to another pointer
<daurnimator>
stratact: hmm. what about `yourarray[0..].ptr` instead?
redj has quit [Read error: Connection reset by peer]
redj has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<shritesh>
So I think I've understood async await: The async keyword returns a frame to a function after executing it to the first suspension point and await is like suspend followed by an assignment with the return value (bad analogy).
<shritesh>
Is there a way to extract the return value from a frame?
laaron has quit [Remote host closed the connection]
<daurnimator>
shritesh: only by awaiting it
laaron has joined #zig
<shritesh>
That makes sense. I'm still trying to figure out why I can't await from main but can resume a frame to completion
<daurnimator>
shritesh: I think because await also is an implicit suspend: and you can't suspend in main.
Tetralux has joined #zig
Tetralux_ has quit [Ping timeout: 245 seconds]
<shritesh>
That's the part I don't understand. Why can't I extract the return values from the frame without suspending
<Snektron>
Zig's inline assembly is much nicer than gcc's
laaron has quit [Remote host closed the connection]
Ichorio has quit [Ping timeout: 264 seconds]
<Tetralux>
shritesh: Because it may not be done.
<Tetralux>
Though there have been suggestions that you should be able to ask for whether the result is still in flight or not.
<andrewrk>
shritesh, yep sounds like you got it
<shritesh>
What's the internal structure of a Frame? Is it like a container?
<andrewrk>
it's literally a struct with the parameters, return value, local variables, and a few other internal bookkeeping fields
<shritesh>
So technically, it should be possible to access the return value without await creating a suspension point?
<andrewrk>
shritesh, @asyncCall gives you a bit more power - you can specify a different address for the return value, and then observe it independently when you're guaranteed that it's done
<shritesh>
That's exactly what I was looking for.
<andrewrk>
also one other tidbit - you actually can `await` without suspending, if 2 conditions are true: (1) awaiting a @Frame(func) directly and not a anyframe->T and (2) func does not suspend
<shritesh>
(not that I'll use it, but it just made the mental model of how everything works clearer)
<Snektron>
Is a Frame in zig literally a stack frame structure?
<Sahnvour>
is it possible to specify the aligment of a struct at its definition ?
<daurnimator>
Sahnvour: the alignment of a struct is that of its highest alignment field
<daurnimator>
Sahnvour: so I wonder if you can include a highly aligned `void` field to set the struct alignment...
<daurnimator>
nope. looks like 0 size fields are not consulted for their alignment
<daurnimator>
andrewrk: ^ how would you feel if we changed that (so that you could do `_alignment: void align(64) = {},`)
<Snektron>
andrewrk: I've noticed a problem with lseek. In std/c.zig, this function is defined as `lseek(fd: fd_t, offset: isize, whence: c_int) isize`, but offset is only isize on x86_64.
<Snektron>
Its u64 with glibc with __USE_FILE_OFFSET64 on a 32-bit system, and it's always u64 with musl
<daurnimator>
Snektron: I think we'd take a PR that changes all the relevant ones to `off_t` and then sets off_t appropriately?
<Tetralux>
shritesh: You _are_ meant to be able to 'var x: S align(N) = undefined;'
wootehfoot has quit [Read error: Connection reset by peer]
<Snektron>
daurnimator: I think its a more effective solution to force 64-bit off_t everywhere
<daurnimator>
Snektron: if we're compiling against an old system that doesn't have 64 bit off_t then we can't do much about it
<Snektron>
so the appropriate solution would be to not declare lseek but instead declare lseek64
cgag has joined #zig
<Snektron>
then define lseek to call lseek64
TheLemonMan has joined #zig
<mikdusan>
and off64_t
<TheLemonMan>
Snektron, you probably want to define all the 64-bit IO ops and use them on 32-bit systems
<TheLemonMan>
including fstat & friends
<TheLemonMan>
and I see you had some questions about the EABI thread-pointer hook, I'd define it as mcr for every arch > v6 and use __kuser_get_tls otherwise
<TheLemonMan>
iirc you can't go below v6 without implementing some fallback mechanism for the atomic ops (and that's booooring)
<Snektron>
i've left that part open for now since i don't exactly know how to do that, and i cant verify it if i implement it
<mikdusan>
(fyi lseek64 appeared in glibc 2.1 around 20 years ago)
<Snektron>
I've made a check for HWCAPS_TLS and an @panic with some pointers for the next person
<Snektron>
Furthermore TheLemonMan: that's what i'm trying to suggest
<Snektron>
There are a few more of these issues, for example Zig's std defines llseek and lseek as seperate functions, but they would be better suited as a single one
<Snektron>
Which is doable
<Snektron>
But they return usize now, and if i change that to u64 i will get a problem with getErrno
<TheLemonMan>
yeah, this busywork is what made me drop the ball on arm32
<Snektron>
I would say it's more elegant to move the checks of the return values up to the functions declared in std/os/linux.zig, though thats a lot of work
<Snektron>
Not every syscall can be implemented naively of course (like the 32-bit versions of getuid and friends) so you can't really write a generator either
<TheLemonMan>
are you sure? ;) I've explored that in #2490
<Snektron>
i guess you can just define a list of exceptions and special cases
<TheLemonMan>
but, again, it's yaks all the way down
<Snektron>
interesting
<Snektron>
Have you made any progress on it?
<Snektron>
i was suggesting a similar thing but with function types a few days ago
<TheLemonMan>
not really, iirc the generator included in #2490 is working with a few (many) quirks
<TheLemonMan>
andrewrk, glad to see the lld patch got in after ~3 months of radio silence
Tetralux has quit [Ping timeout: 258 seconds]
avoidr has quit [Quit: leaving]
Tetralux_ has joined #zig
shritesh has quit [Ping timeout: 264 seconds]
<scientes>
TheLemonMan, yes armv5t needs the 8-byte atomics. Also ARM doesn't sell armv5 chips anymore
<TheLemonMan>
but my junk drawer is full of old-ish ARM chips
<stratact>
daurnimator: I solved my earlier problem and it wasn't a bug that needed reporting. ;) I ignorantly used `exe.linkSystemLibrary("/usr/local/include/X11/Xlib.h")` in build.zig, but I was suppose to do `exe.lilnkSysteLibrary("X11")`, due to how the linker works on Linux/BSD.
<stratact>
*exe.linkSystemLibrary("X11")
<Snektron>
TheLemonMan: The bionic thing is a little different of course, it seems like that is just adding type info to syscall constants and generating code out of that
<Snektron>
which is nice
<Snektron>
But the purpose of std/os/linux.zig is also to provide an abstraction of some of the quirks of linux
<Snektron>
(or so the comment at the top of the file says)
<TheLemonMan>
yeah, the plan was to generate per-arch stubs and then wire them together in linux.zig as needed
<TheLemonMan>
a huge time sink
<Snektron>
I think its too much to do that with all syscalls, but a handfull (like the ones that are declared now) should be doable
kristoff_it has joined #zig
<Snektron>
but anyway, thats more part of the linux os stuff. The original question was about the functions declared in c.zig
Akuli has joined #zig
<Snektron>
i think those should use *64 variants where applicable, or force glibc to use _USE_FILE_OFFSET64
<TheLemonMan>
the former is the sensible thing to do, you never know how the user libc is configured
kristoff_it has quit [Ping timeout: 244 seconds]
<Snektron>
thats what i was thinking
<Snektron>
that should also make it more compatible with other libc's
<TheLemonMan>
well glibc is the only one (that I know of) that carries this historical baggage
Ichorio has joined #zig
curtisf has joined #zig
bastienleonard has joined #zig
uranther has quit [Ping timeout: 250 seconds]
uranther has joined #zig
eddyb has quit [Ping timeout: 250 seconds]
eddyb has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
shritesh has joined #zig
shritesh has quit [Client Quit]
<andrewrk>
Hey TheLemonMan welcome back
<andrewrk>
I managed to get your glibc and musl stuff fixed in a clean way
Tetralux__ has joined #zig
Tetralux_ has quit [Ping timeout: 244 seconds]
<Snektron>
andrewrk: what do you think about using *64 versions of libc functions (in c.zig) instead of the normal ones?
<andrewrk>
Snektron: yes
<andrewrk>
Do you want to start upstreaming your work? I get the impression you have a massive branch that is going to be hard to merge
<Snektron>
theres not a lot of stuff added really
<Snektron>
Its more a few small things - namely the added constants and a few small changes to the wrappers in linux.zig
<Snektron>
but i can make a pr for that if you want
shritesh has joined #zig
Akuli has quit [Quit: Leaving]
rjtobin has joined #zig
bastienleonard has quit [Ping timeout: 252 seconds]
<Tetralux>
The interesting thing I found is that by compiling to asm and then making an exe from that asm, zig cc, aka clang, produces an executable that is 17KB - and that's -static and -g.
<Tetralux>
But if you don't go via asm, its 828KB.
<mikdusan>
is it? when you go from .asm -> exe i don't see -g options
<Tetralux>
I didn't provide -g in the asm->exe step.
<Tetralux>
Only in the source->asm step.
shritesh has joined #zig
<Snektron>
oh
<Tetralux>
Unfortunately my gdb is broken so I can't verify that it actually has debug symbols.
<Snektron>
i just noticed glibc doesnt export *64 versions of functions like musl does (of course), and also doesnt export llseek if some 64-bit define isn't met
<Snektron>
what a nuisance
<Tetralux>
It does seem to though: `Reading symbols from hello...
<Tetralux>
`
<Snektron>
oh yes it does, but they're defines
<Tetralux>
And I just figured out that it _does_ have symbols.
daurnimator has quit [Ping timeout: 252 seconds]
rappet has quit [Quit: No Ping reply in 180 seconds.]
daurnimator has joined #zig
bastienleonard has quit [Ping timeout: 252 seconds]
tobbez has quit [Remote host closed the connection]
rappet has joined #zig
rappet has quit [Remote host closed the connection]
tobbez has joined #zig
rappet has joined #zig
rappet has quit [Quit: No Ping reply in 180 seconds.]
cgag has quit [Quit: WeeChat 2.4]
rappet has joined #zig
<Snektron>
Made a PR with the arm stuff i have and an issue regarding the libc misery
rappet has quit [Client Quit]
rappet has joined #zig
Ichorio has quit [Ping timeout: 264 seconds]
curtisf has quit [Remote host closed the connection]