carldd has quit [Read error: Connection reset by peer]
hiljusti has quit [Ping timeout: 250 seconds]
arkurious has quit [Quit: Leaving]
demo has joined #zig
demo is now known as eyepatchOwl
v0idify has joined #zig
<v0idify>
hey, how do i output llvm ir or assembly with `zig build`?
<daurnimator>
v0idify: in the build.zig you need to specify it
<v0idify>
daurnimator: is there a quick hack for debugging?
<v0idify>
or, how do i do it in general? i have no clue
<g-w1>
-femit-llvm-ir
<v0idify>
I can't find how to set that on build.zig :/ sorry for being a pain
<g-w1>
exe.emit_llvm_ir = true;
<v0idify>
thanks!
<g-w1>
just `grep emit_llvm_ir lib/std/build.zig` :P
<eyepatchOwl>
How popular is gyro for zig package management?
hiljusti has joined #zig
hiljusti has quit [Ping timeout: 276 seconds]
ur5us has quit [Ping timeout: 250 seconds]
v0idify has quit [Remote host closed the connection]
earnestly has quit [Ping timeout: 240 seconds]
zenkuro has quit [Ping timeout: 252 seconds]
<jzelinskie>
i might be doing something wrong -- does `zig cc` not support the -E flag? I know it has limitations for the preprocessor.
<andrewrk>
jzelinskie, it is supposed to work but there may be a bug in zig's CLI parsing with regards to -E. what command are you trying to run?
<jzelinskie>
it's a little complicated... I wanted to see if I could use it for a more portable cgo cross compilation and making go binaries fully static is a bit of a mouthful
<jzelinskie>
`CGO_ENABLED=1 GOOS=linux GOARCH=amd64 CC="zig cc -target x86_64-linux" CXX="zig c++ -target x86_64-linux" go build --tags extended -o faq -v -ldflags '-s -w -X github.com/jzelinskie/faq/pkg/version.Version=0.0.8-dev -extldflags "-v -static"' -tags netgo github.com/jzelinskie/faq/cmd/faq` is the command I'm trying now... I just ripped it out of my Makefile and added the CC and CXX env vars + the `--tags extended`
<jzelinskie>
I'm also on macOS right now and not native linux
hiljusti has joined #zig
<andrewrk>
what version of go is that? I think until very recently you need a wrapper script otherwise go chops off the args to zig
ur5us has joined #zig
<jzelinskie>
ah shit, you're right i think i need a 1.17 pre-release
Kingreil has quit [Quit: Kingreil]
<andrewrk>
you can do it pre 1.17, you just have to make zigcc and zigc++ scripts and put the args in there (including the target unfortunately)
<jzelinskie>
here's a good error message, it just couldn't find the libjq headers
<jzelinskie>
that's likely just because I
<jzelinskie>
I'm linking against libjq which is in /usr/local/include
<jzelinskie>
ok, now it's only the linker that's confused, haha
<andrewrk>
what's the error message?
<jzelinskie>
`ld.lld: error: unable to find library -ljq`
<daurnimator>
jzelinskie: `-L /usr/local/lib` ?
<daurnimator>
or where is your libjq.so?
<jzelinskie>
based on the amount of time it's taking -- everything appears to be working
<andrewrk>
mmm so the annoying thing here is it looks like they use yacc and lex
<andrewrk>
so it's a bit more than a "drop these C files in your repo"
<andrewrk>
unless you wanna pre-build them :)
<andrewrk>
oh wait, it looks like they already do that
<jzelinskie>
oh, do they not check in the results of yacc and lex?
<andrewrk>
never mind, it looks like they do check them in
<jzelinskie>
I'm pretty inexperienced at reverse engineering C projects' build systems just from looking at their files
<jzelinskie>
stuff like autotools makes my head want to explode
<andrewrk>
the good news is in most cases it really is as simple as starting with the linker errors you have there, and then just adding .c files one by one until they go away
<jzelinskie>
I wonder if I should just be doing this on linux, so that CI can re-use what I make more easily
<andrewrk>
in theory with zig it's the same no matter which OS you dev on :)
<jzelinskie>
I'm hoping to use zig to cross compile fully static binaries for a bunch of platforms/archs
<jzelinskie>
fair point, i guess I'll have to build it myself if I want to do what I just described
<andrewrk>
I definitely think you can do this. in the future someone will have made a libjq zig package and it would be even more straightforward to do this. until then you'd have to be the one to figure out the minimal set of C files that faq depends on
<jzelinskie>
I'm not opposed to working on an libjq zig packages to get my feet wet
<jzelinskie>
no one is screaming for faq to build more portably (besides maybe some linux ARM people), so there's no rush
<jzelinskie>
🤔 do people accept build.zig files upstream? I guess if they've already taken in every other c build system
<andrewrk>
mmm I don't recommend it yet. I think they would rightfully find it annoying at this stage of zig's maturity
<andrewrk>
but as we stabilize, part of the goal is to make zig attractive as a build system
<jzelinskie>
i mean, it already is clearly enough of one that I'm trying to use it for cgo 🤣
<andrewrk>
I know video is a bit of an annoying format to try to learn something but there's a 3-part series that shows the process of doing this build system stuff with Redis: https://vimeo.com/519725401
<jzelinskie>
i actually don't find video so bad as long as the player supports x2 speed
<andrewrk>
^^ this is probably very close to what you need for libjq
<jzelinskie>
yep, i found that cross compilation
<andrewrk>
good news though, jakub recently got aarch64-macos and x86_64-macos linking working, so that's 2 more targets you could have your CI create builds for :)
<andrewrk>
afaik that's a feature unique to zig at the moment. lld does not support these targets
<jzelinskie>
nice!
<jzelinskie>
semi-related I have another project that I cross compile that uses cgo and it's in a worse spot than faq
<jzelinskie>
which links against system keychain libraries
<jzelinskie>
there is no platform that is going to have gnome keychain and macOS keychain headers/so
<jzelinskie>
I really wish there was some kind of global registry of ABIs
<andrewrk>
interesting, how would that work?
<jzelinskie>
I guess since the goal is to call into some dynamic library that isn't actually there, it'd work a little like how Go does syscalls on macOS
<jzelinskie>
(which I'm now trying to google for to find a good description)
<jzelinskie>
I guess I want just enough information to dynamic link against something a library that isn't on my machine. You can't really static link on macOS, so that's not a problem
<jzelinskie>
something (e.g. a library)
<daurnimator>
jzelinskie: you can static link on macOS; just not against system frameworks
<jzelinskie>
yeah, that's what I meant by "really" -- I articulated it poorly
<daurnimator>
jzelinskie: and "just enough information" is the headers; which we try and ship with zig :)
<jzelinskie>
zig targets ship the system headers?
<daurnimator>
yes; zig ships system headers for each target it supports where possible
<jzelinskie>
turns out i honestly have no idea what restrictions the apple license has
<daurnimator>
jzelinskie: APSL is pretty liberal IIRC
<daurnimator>
andrewrk: what are your thoughts on including headers for Apple frameworks? is it just missing someone to do the work?
<jzelinskie>
I'd literally use zig for cgo at work if ya'll start shipping them
<andrewrk>
not sure. frameworks might be out of scope
<andrewrk>
might be able to support the --libc arg telling about framework directories, so you would be able to set that up
<daurnimator>
andrewrk: I guess its similar to the windows question of how much do we support? at the moment we ship all of mingw right? which is like shipping every system framework for OSX
<andrewrk>
windows is a lot more stable than macos
<jzelinskie>
it's true every major version of macOS breaks tons of system frameworks
<daurnimator>
andrewrk: why did I suddenly feel the ears of hundreds of OSX fanbois start burning? :P
<andrewrk>
I mean that's just a fact, as a deploy target
<jzelinskie>
I'm not sure the apple fanboys would defend the system frameworks 🤣
<jzelinskie>
You'd probably have to make targets for each major version of macOS
<jzelinskie>
`x86_64-macos11-gnu`
<andrewrk>
zig supports that already
<andrewrk>
I mean it supports target OS version range (min/max)
<andrewrk>
but right now we don't have different headers/libs for different versions
<jzelinskie>
yeah, maybe I'll find some concrete data on how often they actually break things. I've used one of the beta OS releases a few years ago and they made breaking changes and moved the paths on the filesystem 3 times during the beta
<jzelinskie>
obviously that was during a beta, but still
<daurnimator>
jzelinskie: in any case, zig really cares about cross-compilation
<jzelinskie>
do you think it makes sense to have some kind of third party repo for frameworks that integrates into zig's targets?
<daurnimator>
yes; and also no
<andrewrk>
I do want to explore how much we can offload support for cross compilation for many different targets from the main repo, to packages
<andrewrk>
but there is no package manager yet. that is blocking on finishing a faster and more memory efficient compiler, that can handle dealing with the more lines of code that will come with packages
<jzelinskie>
is there a compromise that could exist in the meantime? even if it's just "clone this repository into this subdirectory"
<jzelinskie>
i honestly feel like I'm asking for it all -- zig already does so much for cross compilation
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
for frameworks?
<andrewrk>
I don't know how to make it with status quo zig, but a near term solution would be to have the framework headers on disk and be able to use them for cross compiling
<andrewrk>
there are a few things needed before even this will work. I don't think Jakub has framework support yet in the macho linker code
<jzelinskie>
yeah, I might just be able to rip them out of the apple open source website and just duct tape everything together
<semarie>
andrewrk: I am unsure if someone answer you about 'c++ -E -Wp,-v -xc++ /dev/null' on OpenBSD : https://clbin.com/7iVbv
<andrewrk>
semarie, thanks!
<semarie>
please note it is -current , so more pre-7.0 than 6.9 , notabily regarding llvm version. it is still llvm10 in 6.9 if it matters
<andrewrk>
semarie, can you try one more thing for me? `c++ -print-file-name=libstdc++.a` and `c++ -print-file-name=libc++.a` and `c++ -print-file-name=libc++abi.a`
<semarie>
but OpenBSD still uses libstdc++.a on some archs :)
<semarie>
(like sparc64 for commun one)
<andrewrk>
semarie, thanks! that confirms my hope that libc++.a and libc++abi.a are in the same dir
sord937 has joined #zig
ur5us has quit [Ping timeout: 276 seconds]
cole-h has quit [Ping timeout: 265 seconds]
km_ has joined #zig
novakane has joined #zig
GreaseMonkey has quit [Remote host closed the connection]
nathanael has joined #zig
leon-p has joined #zig
hiljusti has joined #zig
TheLemonMan has joined #zig
<TheLemonMan>
for some reason zig c++ stopped working as it can't find asm/errno.h
<TheLemonMan>
this used to work a few moons ago, I wonder if the native libc switch has something to do with it
txdv has joined #zig
<andrewrk>
providing our own libc sure did have some simplifying properties :-/
<andrewrk>
I suppose we still have the option to rely on our own libc provision when there are no system-provided libraries to be linked against
<TheLemonMan>
I think this is just another problem with the include path order
<andrewrk>
I'm down to just 6 stage2 test failures left in #8554
<andrewrk>
when this branch is merged we can start trying to get behavior tests passing in stage2 one by one
<andrewrk>
there are still some tricky bits to debug in the compiler but with the logging system and the `zig astgen` command / clean separation of ZIR from the rest of the compiler, it's definitely an improvement in ability to troubleshoot and confidently fix problems
<txdv>
6 sounds like a small number, are those tests easy to get green?
<andrewrk>
yes they will be easy tomorrow morning; less so now that it is after midnight for me :)
<txdv>
omg, what a soldier :)
<txdv>
its morning here in europe
knebulae has quit [Read error: Connection reset by peer]
<andrewrk>
one thing that would be a big step up in debugging stage2 would be if there was a way to make gdb print custom textual representations of our types
<andrewrk>
Decl, Namespace, Value, Type, etc. gdb does not understand zig's namespacing, so it's not trivial to set up
<andrewrk>
idk what is all involved to make this happen. I think it is its own project
<andrewrk>
would be pretty slick if we could define "gdbPrint" methods on types and have that compile to GDB Python and Just Work
<txdv>
would help you in your current efforts significantly or is it a general nice to have?
<andrewrk>
both
<andrewrk>
it would speed up the development iterations; I'm having to recompile more often than if the debugger could understand more semantically
<TheLemonMan>
LLVM defines a dump method on several types you may want to print during a debugging session
<andrewrk>
yeah those are handy. I would love to have something like that for zig code
<andrewrk>
maybe we need to tell gdb that zig is c++ and tell it about namespaces? idk
<andrewrk>
recompiling stage2 with stage1 takes 40 seconds on my laptop
<TheLemonMan>
gdb (and lldb) don't like our loong names with dots in between
<xackus__>
last time i tried lldb i couldn't set a single breakpoint
<andrewrk>
28 seconds with a release mode stage1
<andrewrk>
anyway I've been working way too long today. good night all
<TheLemonMan>
gn
marler8997 has quit [Read error: Connection reset by peer]
wilsonk_ has joined #zig
wilsonk has quit [Ping timeout: 240 seconds]
<txdv>
is the astgen command only present in that branch?
nathanael has quit [Remote host closed the connection]
<cepheus>
you can instead do `addOneAssumeCapacity` and mutate the returned value if you know that you have sufficient capacity to append without reallocating though
<ifreund>
or appendAssumeCapacity()
<kiedtl>
Hm, I guess I'll look into using a linked list or something then
Akuli has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
cole-h has joined #zig
<ifreund>
kiedtl: yep, if you want pointer stability a linked list is the simplest option
<kiedtl>
But no automatic allocation :V
<kiedtl>
idk, I'll probably just write my own linked list
tefter has joined #zig
eyepatchOwl_ has quit [Quit: Connection closed for inactivity]
TheLemonMan has joined #zig
tefter has quit [Quit: WeeChat 3.1]
novakane has quit [Quit: WeeChat 3.1]
novakane has joined #zig
v0idify has joined #zig
<v0idify>
hey, i stumbled upon a weird possibly-bug of zig and i can't make a minimal example :/
<v0idify>
basically, calling a function directly with a pointer works fine but when calling the same function through a function pointer inside a struct the pointer passed gets mangled/is wrong
dyeplexer has quit [Remote host closed the connection]
<v0idify>
okay, forcibly calling it as an async function makes it work. I edited the bin with the code I did to do that; I believe this is a compiler bug (it's calling as a normal function when it should be calling as an async one)
<andrewrk>
"Neat issue visualization from https://9-volt.github.io/bug-life/?repo=ziglang/zig. Colors match label colors - red = bug (yellow = stage 1), blue = std lib, cyan = proposal, bright green = accepted. Unfortunately it counts issues with multiple labels multiple times, which is why the total is so much larger than the number of issues we have."
<andrewrk>
ok but specifically this part:
<TheLemonMan>
I can't unsee the chopped labels on the axis hah