<freemint>
Why would clang being able to build Linux matter? Zig cc came to my attention bc it was mentioned as a drop in replacement for GCC.
<freemint>
GCC can built Linux
<mikdusan>
clang has high compatibility with gcc; and until relatively recently, clang couldn't compile linux kernel. I haven't tracked it really closely, but apparently there has been success as of llvm/clang 9.x
<freemint>
So Zig uses LLVM internally?
daex has quit [Ping timeout: 250 seconds]
<mikdusan>
yes, zig embeds llvm+clang+lld
<freemint>
So if you are trying to bootstrap Linux/cross compile Linux on a new architecture using zig cc has no real benefits?
<fengb>
zig cc doesn't do anything you couldn't already do. It just makes cross compiling a lot easier to get started
<freemint>
Other than fancy caching and (maybe?) less pre-compilation for years.
<freemint>
*headers
<freemint>
Thanks
<freemint>
if i wanted to add a new CPU arch to zig i would first need to add it to LLVM, what would be the next steps?
<mikdusan>
`zig targets` has a .json dump of known targets so if LLVM gets a new target, zig would need to learn it and some .cpp and .zig code needs to be updated, so that Zig can drive llvm codegen and tell it the correct new target to use. that's a minimum, and I'm not the subject matter expert on that, so take with grain of salt
<freemint>
Thanks that clarifies stuff.
<freemint>
Goof Night
<mikdusan>
cheers
freemint has quit [Remote host closed the connection]
<watzon>
My poor computer is slowly chugging along
daex has joined #zig
_whitelogger has joined #zig
<scientes>
oh wait, you are talking about which libraries it uses...
<watzon>
When installing zig from a tarball is there an environment variable I have to set or something?
<watzon>
When running `zig targets` it's telling me it can't find the zig lib directory
<watzon>
Or maybe I just need to drop that in /usr/local/?
<mikdusan>
it locates lib/ from the executable position
<mikdusan>
you can symlink, but hardlinks will not work
<watzon>
Got it, thanks :)
<watzon>
Is there a way to get a more condensed target list? Lol
adamkowalski has quit [Quit: Lost terminal]
daex_ has joined #zig
daex has quit [Ping timeout: 246 seconds]
<wilsonk>
Surprising, clang-10 compiles itself about 9 percent faster than clang-9.0.1 (take that with a grain of salt as the server had one VM running during those compilations...but I was only using 55 out of 64 cores, and no disk activity by the VM, so probably pretty accurate).
squeek502 has quit [Read error: Connection reset by peer]
squeek502 has joined #zig
FSX has joined #zig
<FSX>
I downloaded the master binary, tried to run it and got 'Unable to find zig lib directory: FileNotFound.'
<FSX>
I can't find anything docs about this.
ur5us has joined #zig
afontain_ has joined #zig
<afontain_>
hi. I know some C and C++, and I am trying to get used to Zig. I was wondering if there is an equivalent to C++'s vector.push_back() in Zig or if you have to try to find an upperbound and splice it afterwards
<wilsonk>
FSX: which OS?
<FSX>
Arch Linux, x86_64,
<afontain_>
I was quite hopeful about slices, given that "the slice's length is known at runtime" according to the language reference, but I've only seen splices of arrays there (so compile-time size)
<afontain_>
I've also looked at the standard librairy reference, but I didn't find something that looked very useful
<wilsonk>
FSX: darnit I don't run Arch. Weird that the issue seems closed but there isn't a real solution cited. The binary on the website would certainly have been rebuilt since 20 days ago
<traviss>
afontain_, look for ArrayList append()
<wilsonk>
afontain_: I think Array_List with .append is what you are looking for...maybe? (lib/std/array_list.zig)
<scientes>
my god, I had no idea there was so much to know about mtime and ctime
<afontain_>
I've downloaded the source tarball to allow grepping the files
<traviss>
if you have a local copy: grep "pub fn" zig-master/lib/std/array_list.zig | sort
<traviss>
actually may be better not to use sort so you can see the type defining functions aren't indented
<wilsonk>
FSX: any chance to build from source?
<wilsonk>
of course llvm-10 will take quite a while :(
<FSX>
Yes, I can do that. I'm working now, I'll start a build when I got time. I'll report back later. :)
<wilsonk>
Sounds good
<daurnimator>
scientes: and atime? :)
<wilsonk>
One note for anyone else here: if you have previously built llvm/clang/lld as dynamic libraries and then attempt to build zig without building llvm-10/clang/lld dynamically also, then you will get linking errors. It seems like there is a preference for picking up the old dynamic libs instead of using the llvm-10 static libs
<daurnimator>
wilsonk: oo, interesting; I was about to try and build against 10 now
<wilsonk>
daurnimator: that was on my linux server...just waiting for my MacOS vm to finish up building llvm-10 and then I will see if it builds cleanly (no previous dynamic libs). Then I will do the WIn10 vm builds and my personal linux machine and report back if there are any issues
<afontain_>
ArrayList.init asks for an allocator. In the language ref, the only mention of an allocator is std.heap.page_allocator. I guess it will allocate on the heap and avoid creating issue during normal use, like regular malloc, right?
<afontain_>
(regular C malloc)
<afontain_>
(and assuming there is free memory left)
<mq32>
afontain_: there are some allocators in Zig atm
<mq32>
page allocator is slow, as it calls mmap() for every alloc() and munmap() for ever free()
FireFox317 has joined #zig
<afontain_>
ok, it totally wasn't the only mention in the doc, silly me
<traviss>
if you want to use std.heap.c_allocator you'll need to pass -lc when you build
<traviss>
c_allocator is a thin wrapper around malloc/free
<afontain_>
I'm wondering if -target linux-something-musl counts as "linking with libc"
tankf33der has left #zig [#zig]
<daurnimator>
afontain_: no.
<daurnimator>
afontain_: that's the *target*
<daurnimator>
afontain_: the -musl there is the ABI: musl dictates certain things: e.g. size of c_int, default calling convention, etc.
<daurnimator>
afontain_: you need -lc to link libc
<afontain_>
don't you have to choose one of musl or glibc?
<daurnimator>
afontain_: yep: you have to choose which ABI you want
<daurnimator>
which implies which libc zig should use...
<afontain_>
isn't the ABI a kernel matter?
<afontain_>
(on Linux, at least)
<daurnimator>
nope
<daurnimator>
the kernel only dictates which syscalls are available and the kernel structs
<afontain_>
so it's just that glibc is compatible with musl binaries?
<daurnimator>
no. and it's not :)
<afontain_>
so -target …-musl binairies are statically linked with the libc, but are not linked to the libc?
<daurnimator>
no. you only link against libc if you pass -lc
<afontain_>
hmm, okay
marijnfs has joined #zig
traviss has quit [Remote host closed the connection]
traviss has joined #zig
daex has quit [Ping timeout: 256 seconds]
daex has joined #zig
<wilsonk>
yep, ran into the same errors building zig on my personal linux machine, where I had a mix of dynamic and static llvm libs. Only lld had dynamic libs but they still got picked up before/instead of the static libs when building zig. (I assume there is a way to tell cmake not to allow this but I just uninstalled llvm-9 and went from there)
<traviss>
i'm trying to figure this out myself as building zig now fails with: Could NOT find LLD (missing: LLD_LIBRARIES LLD_INCLUDE_DIRS)
<traviss>
i tried cmake .. -DLLD_INCLUDE_DIRS=/usr/lib/llvm-10/include -DLLD_LIBRARIES=/usr/lib/llvm-10/bin/ld.lld
<traviss>
but then make -j8 results in: zig/src/zig_llvm.cpp:55:10: fatal error: lld/Common/Driver.h: No such file or directory
<traviss>
#include <lld/Common/Driver.h>
<wilsonk>
traviss: did you build llvm from source? I always install to /usr/local and haven't had any need for LLD_INCLUDE_DIRS
suppi has joined #zig
<FireFox317>
traviss, you can't just use `cmake .. -DCMAKE_PREFIX_PATH=/usr` ?
<traviss>
i installed llvm-10 with apt on debian
<traviss>
FireFox317, i'll try
<traviss>
no that gives the same error
<FireFox317>
so you did install liblld-10-dev?
dwdv has joined #zig
<afontain_>
traviss, wilsonk: ArrayList works for me, thanks
<wilsonk>
afontain_: cool
<traviss>
thank you FireFox317 it works now after installing liblld-10-dev :)
<FireFox317>
traviss, nice :)
<afontain_>
I've settled for the arena allocator
marijnfs has quit [Ping timeout: 264 seconds]
<traviss>
oops i missed a linking error: /usr/bin/ld: /usr/lib/llvm-10/lib/libclangCodeGen.a(BackendUtil.cpp.o): in function `(anonymous namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager
<traviss>
undefined reference to `getPollyPluginInfo()'
<traviss>
right after [ 99%] Linking CXX executable zig0
<traviss>
that worked too. thanks again FireFox317
<traviss>
zig version: 0.5.0+778dbc17a :)
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
rappet has quit [Quit: -]
rappet has joined #zig
_Vi has joined #zig
kenaryn has joined #zig
<kenaryn>
Hello computer guys. Please what does it mean in a few words a "drop-in" compiler? (related to `zig cc` as a drop-in C compiler).
<scientes>
kenaryn, in place of
<traviss>
make CC="zig cc"
<mq32>
i think it was "drop-in replacement"
<mq32>
if you have used gcc/clang until now, you can just replace it with "zig cc"
<mq32>
without further work needed
<scientes>
"en lugar de"
ur5us has quit [Ping timeout: 260 seconds]
<kenaryn>
is there a discrepancy with 'out-of-the-box' concept?
<daurnimator>
kenaryn: "out of the box" means you don't have to bring along your own.... anything. it just works as-is
<daurnimator>
kenaryn: "drop-in replacement" means you can swap out an existing utilities
<kenaryn>
Allright! Thank you scientes, traviss, mq32 and daurnimator
<kenaryn>
Do you know why llvm's team did suggest c++14 instead of c++17 for llvm10 6 months ago? (I saw the commit message in the graph commit log's zig). Do the core contributors think are a too few people using c++17's coding convention to maintain the code base?
Snetry has quit [Ping timeout: 258 seconds]
Snetry has joined #zig
<kenaryn>
ce56ae8af: Wed Oct 2 13:05:10 2019 -0400 - we have to use c++14 now for llvm10
<FireFox317>
kenaryn, because apparently now the llvm 10 source code is using c++ features that require the use of c++14?
mahmudov has quit [Ping timeout: 264 seconds]
kristoff_it has joined #zig
mforney has quit [Quit: quit]
mforney has joined #zig
<kenaryn>
Obviously, but I still don't know why c++20 isn't adopted in the project, or at least c++17 for better maintenability, not only features's requirements.
<kenaryn>
It was Andrew who committed the message in git log, saw may be he'll explain briefly during the day.
<mq32>
i would not use c++20 for any project yet
<mq32>
it's not established in any way and even c++17 is hard-to-use
redfast00 has joined #zig
mahmudov has joined #zig
<kenaryn>
Why it is harder than c++14? I do not understand.
<mq32>
it has nothing to do with language spec
<mq32>
but compiler and platform support
<mq32>
afaik no compiler has a c++20 compliant lib right now
<redfast00>
I just read the post on hackernews about `zig cc` and wanted to try it out for myself. Unfortunately, when running `zig cc -o hello hello.c -target riscv64-linux-musl`, I get `/usr/bin/ld: unrecognised emulation mode: elf64lriscv`. This is kinda expected, since Arch's ld is only for x86-64. I installed risv64-binutils, but zig does not seem to use
<redfast00>
that linker. Is there a way to force it to use the correct ld?
<mq32>
c++17 is not available on a lot of systems
lunamn has quit [Remote host closed the connection]
lunamn has joined #zig
<scientes>
redfast00, ahh that is a problem. we use to build lld internally to avoid those type of problems
<scientes>
if you download the tarball you avoid that
<scientes>
except...../usr/bin/ld.....zig uses liblld directly so i'm confused
<scientes>
so I guess I don't know the answer to your question
<redfast00>
scientes: should I install zig-static then?
<scientes>
you should try it
<FireFox317>
redfast00, zig should not run the system lld. How did you build/install zig?
<redfast00>
FireFox317: pacman -S zig
<scientes>
FireFox317, it does use the system liblld and lld-dev now
<scientes>
since 0.6.0
<kenaryn>
Thanks mq32, I switch back to zig's subject :)
<FireFox317>
redfast00, i'm pretty sure that pacman has zig 0.5.0, for this feature to work you need master at least. You can download binaries from ziglang.org
<traviss>
would passing this flag help? --dynamic-linker [path] set the path to ld.so
<redfast00>
I now installed zig-static, this seems to give a different error "/usr/include/stdio.h:33:10: fatal error: 'stddef.h' file not found"
<redfast00>
so I guess it's linking now, but cannot find needed libraries
<FireFox317>
redfast00, zig-static is not master build either. can you run `zig --version`?
kenaryn has left #zig ["WeeChat 2.3"]
<redfast00>
`zig version` gives 0.5.0, so I guess that's not master either
<FireFox317>
redfast00, fortunately it is really easy to use master zig. Just download the x86_64 linux binary from https://ziglang.org/download/. Unpack it and then you can run the latest zig.
ifreund has joined #zig
<FireFox317>
scientes, there is no 0.6.0 yet :)
ifreund has quit [Client Quit]
<redfast00>
FireFox317: that works, thanks!
daurnimator has quit [Read error: Connection reset by peer]
dottedmag has joined #zig
redfast00 has quit [Remote host closed the connection]
daurnimator has joined #zig
marijnfs has quit [Ping timeout: 246 seconds]
marijnfs has joined #zig
zfoo has joined #zig
swills has quit [Quit: No Ping reply in 180 seconds.]
swills has joined #zig
<wilsonk>
Ok, an issue that may come up for OSX users. If someone is building on MacOS Catalina (might be the same for Mojave with an updated Xcode) and they had CC and/or CXX set to /usr/local/bin/clang because they built from source...then they may end up with errors related to a missing cmath or other c++ header. I fixed this by updating Xcode and then 'unset CC; unset CXX' and delete the build directory, rerun 'cmake ..' and then things should
<Snektron>
<kenaryn "Obviously, but I still don't kno"> Clang 10 implements many features of c++20, it would be weird make a compiler which can only be built using its own latest version
<Snektron>
I would guess they use c++14 because many people are still using an older system, or a distro which is quite slow in distributing updates
<Snektron>
Personally, i just use the latest c++ version and tell people to download a more recent compiler, but my projects are quite limited in scope compared to clang
FireFox317 has quit [Quit: Leaving]
ifreund has joined #zig
<wilsonk>
Zig built perfectly fine for me on Win10 using the instructions on the wiki. Just so people know. I have working versions of zig with llvm-10 on Ubuntu 16.04, Ubuntu 18.04, MacOS Catalina and WIn10 so far. There were a couple issues that I noted above, but that was not really zig's fault as I had dynamic libs lying around and had updated from Mojave to Catalina today (and updated Xcode).
dddddd has joined #zig
<jaredmm>
wilsonk: Any chance you managed to get a debug build working on Win10?
<wilsonk>
jaredmm: haven't gotten around to doing those as it takes an hour or more to build llvm per target here. I should be able to get to it on linux tomorrow (I will probably only build debug on my server as I have 128GB and 64 cores to speed the process along). I can let you know if I get it running
<wilsonk>
sorry the hour per target is on the non-server machine or VM's
<wilsonk>
I can spin up a Debian buster vm tomorrow and test that also (though I wouldn't anticipate any problems)...can also try some other OS's if someone wants. Perhaps FreeBSD/NetBSD.
mahmudov has quit [Remote host closed the connection]
<swills>
hmm, i'm running ./install/bin/zig build test -Dskip-release -Dskip-non-native
<swills>
is that building c++ code?
<swills>
"It also serves the use case of using zig as a build system and package manager for C/C++ projects." -- that IS the use case that i'm very much interested in... :)
<andrewrk>
yeah c++ support libraries are not available yet, but planned
<andrewrk>
this works with llvm,clang,lld built from source. apparently not using the system packages
<andrewrk>
if you just want to get unblocked, you could download the same freebsd tarball the CI server uses and link against that. or you can try to submit a patch upstream to fix the build using the freebsd packages
<swills>
i built my llvm10 from source, created a package for it, and installed the package
<andrewrk>
hmm ok
<swills>
i'm running FreeBSD CURRENT
<swills>
r359255
<andrewrk>
when zig0 gets linked, this unwind dependency is satisfied. the build.zig code is trying to satisfy the dependency in the same way
<andrewrk>
cmake is driving the linking of zig0, and it's working for you. build.zig / zig compiler is driving the linking of the pastebin you sent. our goal is to figure out what is the difference between former and latter, and fix the latter
<dottedmag>
andrewrk: I saw you use NixOS. Does it make it easier to work with the zoo of compilers?
<andrewrk>
dottedmag, yes, nixos generally makes everything easier to work with any zoo of dependencies
<andrewrk>
mostly because you can have your base system be minimal with almost nothing available, not even `make`
<andrewrk>
and then when you want to build something you can explicitly choose exactly what set of things and what versions are available, per terminal window
* dottedmag
adds tasks "try nixos for realz" and "invent a better syntax for nix language"
<waleee-cl>
dottedmag: there's guix, but then you have parenthesis overflow & only libre-stuff as the default
<companion_cube>
plz make it typed
<dottedmag>
waleee-cl: last time I tried half of the stuff was 5 years of date
<dottedmag>
companion_cube: I can't, if it's just a different syntax.
<dottedmag>
But that's definitely an offtopic here.
<adamkowalski>
could I download the latest zig binary?
<adamkowalski>
and use zig cc
<andrewrk>
yes
<adamkowalski>
thats clearly the only acceptable solution
<TheLemonMan>
andrewrk, yo, what's up with the failures on drone?
<adamkowalski>
that should be the recommended way to build zig. how many languages can say that
<andrewrk>
TheLemonMan, I spent a couple hours looking into it yesterday. I was able to reproduce it in an aarch64 alpine docker image, but not on an aarch64 debian system
<andrewrk>
it's frustrating because gdb does not work inside the docker image, and it's slow as fuck
<andrewrk>
I don't know what the problem is yet, but it's happening inside LLVM when we call TargetMachineEmitToFile
<adamkowalski>
andrewrk: do you have any good resources you can recommend for parsing into an ast? specifically dealing with precedence of things like operators, function calls, conditionals, etc
<TheLemonMan>
hmm, that's bad... can you pull out of the VM a statically-linked zig? qemu-user should be able to run it and you can attach gdb to it
<andrewrk>
TheLemonMan, oh, scaleway lets me start an aarch64 alpine linux image. I'm going to try that
<andrewrk>
that's a nice idea, I will try that
<andrewrk>
adamkowalski, imo just write some code and try it. you'll learn quickly
<adamkowalski>
yeah thats what I figured haha
<adamkowalski>
I think my first pass approach is to just follow PEMDAS
<adamkowalski>
and just try to parse things in that order, and if it can't then fall back to the next one down
<fengb>
adamkowalski: just use sexprs. Easy peasy parsing
<adamkowalski>
I would if it was for my own language, I love lisp
<adamkowalski>
but I need to build this out for a client and it needs to follow a very specific syntax they decided on
<fengb>
Oh poop >_>
<Snektron>
In theorey, `zig cc` should accept `-T` right?
<adamkowalski>
my simplest approach just used the shunting yard which worked
<adamkowalski>
but now I need to think about function calls, conditionals, etc
<andrewrk>
spoke too soon. not true: "oh, scaleway lets me start an aarch64 alpine linux image. I'm going to try that"
<andrewrk>
Snektron, yes, all the linker related commands need to have detection added
<Snektron>
thanks, andrewrk. I didn't set up an LLVM10 build yet so i'll have to wait
<Snektron>
in the mean time, does anyone happen to know how i can disable extensions on clang?
<andrewrk>
unfortunately you'll have to wait until I troubleshoot this aarch64 failure too
<Snektron>
It also happens with zig cc: if i pass in -target i386-freestanding-none, all x86 extensions get enabled
<adamkowalski>
andrewrk: so building from source seems to be the best way forward if I don't want to be blocked until brew has a update?
<swills>
andrewrk: backing up, i am not sure now about this:
<swills>
[11:22:43 am] <andrewrk> can you confirm that you used the same compiler to build llvm/clang/lld and zig?
<swills>
[11:22:51 am] <andrewrk> the c++ ABI requires this
<swills>
[11:23:13 am] <andrewrk> also that the libc++ matches
<swills>
are you saying llvm10 has to be used to build llvm10?
<fengb>
No but both need to be compiled with the same compiler
<swills>
both of what?
<swills>
both llvm10 and zig?
<swills>
zig only builds with llvm10
<swills>
so that is basically saying the same thing, llvm10 has to be build with llvm10
<fengb>
Whatever built your LLVM10 has to be used to build Zig as well
<swills>
zig only builds with llvm10, right?
<Snektron>
ah, i had to pass in -march=i486
<fengb>
No, Zig has to be linked with LLVM10, but it can be built with whatver spec compliant compiler you want
<andrewrk>
swills, check the readme and tell me how to word it more precisely
<swills>
oh!
<andrewrk>
Snektron, ok hang on let me add -march support to zig cc real quick :)
<andrewrk>
most c flags work without any support needing to be added, but some things like cpu features need detection, otherwise zig starts doing its own thing
<swills>
so i have llvm 9 in base, but it lacks llvm-config
<swills>
it's what build llvm10 and libc++
<swills>
btw, i got my build config down to cmake -DLLVM_CONFIG_EXE=/usr/local/bin/llvm-config10 -DCMAKE_PREFIX_PATH=/usr/local/llvm10 -DCMAKE_INSTALL_PREFIX="/usr/home/swills/Documents/git/zig/install" -GNinja ..
<andrewrk>
llvm-config 9 would be incorrect; llvm-config corresponds to the libraries you link against
<swills>
ok, then what i have there should be using the base llvm 9 to build and llvm10 to link
<andrewrk>
I think you're over complicating this whole thing
<swills>
-- Check for working C compiler: /usr/bin/cc -- works
<swills>
-- Check for working CXX compiler: /usr/bin/c++ -- works
<Snektron>
andrewrk, if you're at it anyway i noticed in order to build for the target i386-freestanding-none i need to pass in -nostdlib
<Snektron>
Otherwise i receive "Zig is unable to provide a libc for the chosen target"
<swills>
maybe
<swills>
i'm trying to do it the simplest way i can, i dunno
<andrewrk>
Snektron, ah right, I can adjust the logic to not try to add -lc on freestanding
<Snektron>
Great!
<swills>
oh, i'm mistaken, base is 10 now
<swills>
llvm10 that is
<swills>
but it lacks llvm-config
adamkowalski has quit [Quit: Lost terminal]
<swills>
oh, my llvm10 is out of date, that could be part of the problem...
<swills>
rc2 from march 9, i've updated the base system since then
<swills>
llvm10 from ports/packages out of date that is
<andrewrk>
again my suggestion is simply to compile llvm 10 from source if you wish to contribute to zig
<andrewrk>
you'd have it up and running by now if you just followed the directions instead of trying to go down a different path
<andrewrk>
we don't need any Robert Frost poems in here, just take the road well traveled
<TheLemonMan>
then we should just use C, no?
<fengb>
Or use the nightly download like the rest of us plebs :P
<swills>
andrewrk: i hear you :)
<swills>
building and testing packages is kinda my main focus tho
<andrewrk>
mikdusan, hmm I'm not sure what to make of that. do you?
<TheLemonMan>
jesus, building stuff on a 30 core ARM server is a hell of a experience
<andrewrk>
yeah, lol
<TheLemonMan>
that's the future I've been dreaming of
<andrewrk>
just wait though, linking takes ages
<andrewrk>
zahary, yes I'm happy to coordinate / collaborate with the nim community if you want to experiment with the use case of using `zig cc` as a backend for nim
<zahary>
is "zig cc" an alternative front-end btw or just a statically linked version of clang into Zig?
<andrewrk>
it's a tiny layer on top of zig to support parsing clang's command line options
chivay has joined #zig
<zahary>
The integration so far seems quite straigh-forward, but the interesting possibility will be extending Nim with some support for compiling and linking Zig progragms
<andrewrk>
yes there is a statically linked version of clang in zig
<andrewrk>
ooh that would be interesting indeed
<andrewrk>
right because the zig binary that you would be using for `zig cc` is fully capable of compiling zig as well
adamkowalski has joined #zig
<andrewrk>
(and in fact is doing exactly that, for example, to build compiler-rt from source)
<fengb>
Oh Zig is inserting itself into zig cc now? :P
<andrewrk>
hm?
<andrewrk>
`zig cc` adds nothing except clang command line parsing
<andrewrk>
everything else was already there, for example with `zig build-exe --c-source foo.c`
<zahary>
well, you can leave a short comment in the issue. I think there will be interest in the Nim community for this interop
<fengb>
I thought before it was invoking clang and nothing else
<mikdusan>
andrewrk: ok red herring. that is a very new warning cmake 3.17 and up. but it does tell us the drone ci is using latest of latest
mahmudov has quit [Ping timeout: 258 seconds]
mahmudov has joined #zig
<andrewrk>
zahary, done, let me know if there's anything else I can do
<zahary>
thanks, I'll try to advocate for this :)
<adamkowalski>
andrewrk: std.testing.LeakCountAllocator is awesome
<andrewrk>
you can thank fengb for that
<adamkowalski>
fengb: thanks! I can't belive I can write unit tests that verify I'm not leaking
alva has joined #zig
<fengb>
I’m glad it’s useful :)
<fengb>
And hopefully one day it can be replaced by the debug allocator >_>
<shakesoda>
i started using it, too
<adamkowalski>
can you go into more details about that?
<shakesoda>
very convenient
<adamkowalski>
I would love to help with the debug allocator if I can
<adamkowalski>
If we can actually watch which memory addresses are being freed, and if the same address is freed twice then error out
<adamkowalski>
not sure if it's possible to catch use after free in the allocator itself, but I've been trying to force that error condition and find it otherwise in my tests
<andrewrk>
adamkowalski, go for it, the debug allocator is open source
<shakesoda>
if free wipes the memory to something obvious you can at least identify use after free easily
<adamkowalski>
yeah thats not a bad idea, because that means whatever you do next in your tests should clearly fail
<shakesoda>
and in general you can do a lot by shoving some metadata before the pointer you return
<adamkowalski>
hmm
<adamkowalski>
can you track the number of times a certain region was read/written to and actually find the line numbers/file names
<shakesoda>
AFAIK most allocators end up doing some tricks like this, slightly lie about the memory they actually got for the sake of some bookkeeping
<adamkowalski>
I think it could really interesting to combine the work rust is doing with lifetimes with the allocator model of zig
<shakesoda>
I don't know about that, but you could record the origin of an allocation and spit that out if leak check fails or you get a double free
<shakesoda>
i think writing in dummy data is the best you can do for use after free
<adamkowalski>
allocators calling alloc create a new lifetime which is then tracked by the compiler until you call free
<adamkowalski>
you still enforce the strict single owner model and allow non mutable borrows to several others at once
<fengb>
The debug allocator will actively unmap on free to force a segfault
<adamkowalski>
fengb perfect!
<shakesoda>
sounds good to me
<shakesoda>
the regular ones should probably do that if safety stuff is enabled :)
<adamkowalski>
shakesoda: i'm not sure. I still want good performance in debug mode
<fengb>
That’s much harder because freeing 4bytes probably shouldn’t incur a syscall
<shakesoda>
this shouldn't hurt performance that badly?
<adamkowalski>
if I want to track that, it's not hard to wrap an existing allocator with the debug
<shakesoda>
unless you're doing a *ton* of frees
<shakesoda>
I tend to agree though
<andrewrk>
the primary technique of the debug allocator is (1) when mapping memory, provide an address hint that is always marching forward in address space (not reusing pages) and (2) unmap pages as soon as possible
<fengb>
Linked list allocations would end up being close to useless
<shakesoda>
if you're using an allocation for tiny bits of memory you're already losing the performance game
<shakesoda>
not that you should be made to lose it more than needed
<fengb>
Not true at all in Zig
<fengb>
Just use an allocator that does small memory well
<shakesoda>
anyway, I was thinking about the page allocator, really
<adamkowalski>
shakesoda: I think zig programs tend to utilize arenas more frequently so idk if it's a huge issue
<fengb>
I’d like to see object pools to be converted to Zig allocators
<adamkowalski>
sounds pretty easy, just have an array of objects and mark them alive/dead
MrMobius has joined #zig
<adamkowalski>
then if you ask for a new object and there are dead objects reuse them
<shakesoda>
I've got a few var typed things which are pretty well defined, but var doesn't express that.
<adamkowalski>
pmwhite: that works for simple types
<andrewrk>
FireFox317, you could start with getting the behavior tests passing with --test-evented-io
<adamkowalski>
it doens't scale when you have many things that are generic
<shakesoda>
so you could try passing in an int or something and you get some cryptic message
<companion_cube>
ok, that makes more sense than gaining runtime reflection
<shakesoda>
building everything to be generic is itself a code smell and a path toward pain
<mq32>
adamkowalski: same goes for C++ as well. Compile time gets horrible
<fengb>
shakesoda: there’s a proposal for function based constraints by returning a boolean
<mq32>
and that stuff is already optimized!
<adamkowalski>
companion_cube: D takes it one step further and is something I'm missing in Zig
<adamkowalski>
we want to be able to generate new types at compile time
<andrewrk>
FireFox317, if you want a really simple one, start with "hello world" with `pub const io_mode = .evented;` and then start doing some basic file system stuff
<shakesoda>
not that there aren't always the edge cases
<companion_cube>
yeah D has some good ideas
<adamkowalski>
or generate branches of a switch statement given an enum
<adamkowalski>
no macros required, just a static foreach
<companion_cube>
I think it's quite intersting to have foo!(…)(…) where the first set is comptime and the second one runtime
<shakesoda>
that sounds far deeper into magic than I want anything to do with.
<adamkowalski>
i prefer zig approach
<adamkowalski>
I like having first class types
<shakesoda>
there's no way in hell that'll be easy on the brain
<adamkowalski>
you can pass types around, store them as variables, and put them in data structures
<adamkowalski>
in D you end up having two sets of libraries
<fengb>
Yeah I do want to generate switches
<adamkowalski>
one that work on the type level, and one that work on the value level
sammich has left #zig ["Kicked by @appservice-irc:matrix.org : issued !quit command"]
sammich has joined #zig
<nephele>
Oki, thanks
<swills>
All 129 tests passed.
<swills>
1323 passed; 17 skipped.
<swills>
amazing
<TheLemonMan>
andrewrk, the problem seems to be in the debug info we generate in the LLVM IR, the build succeeds if you pass --strip
<swills>
something up with the llvm10 build i was using
<andrewrk>
TheLemonMan, ah, that's a great clue
<andrewrk>
TheLemonMan, so it must be something to do with the debug info that ended up being generated for __divtf3, right?
<TheLemonMan>
let me see if I can get a minimal reproducer
<TheLemonMan>
building llvm10 took something like 10mins
<TheLemonMan>
what a wonderful beast
<mikdusan>
avg 7 .o per second
<TheLemonMan>
mikdusan, do you still have that netbsd vm?
<mikdusan>
aye
<TheLemonMan>
can you check if selfExePath returns an absolute path there?
<TheLemonMan>
your ticket about OpenBSD made me realize that it may not be the case there
<mikdusan>
os_self_exe_path has a #ifdef section for netbsd but ok
<TheLemonMan>
oh I mean in the stdlib
<mikdusan>
resolveZigLibDir or somesuch?
<mikdusan>
oh nm i see. one sec.
<TheLemonMan>
std.fs.selfExePath
<mikdusan>
yup std.fs.selfExePath() is returning a nice long zig-cache path on netbsd @ f313ab18aecea1ade0b6a90d671352a641ad351a
<TheLemonMan>
did you compile llvm10 yourself?
marijnfs has quit [Ping timeout: 264 seconds]
<mikdusan>
yes
<mikdusan>
i have llvm10 suitable for zig for freebsd121,netbsd90,openbsd66,dragonfly580
<TheLemonMan>
can you upload it somewhere? I'd love to give netbsd+llvm10 a spin in this VM
knebulae has joined #zig
<mikdusan>
yup
ky0ko has joined #zig
ky0ko has quit [Quit: authenticating]
ky0ko has joined #zig
<swills>
i made a shell wrapper called zcc which just calls zig cc "$@", but i find that if i have HOME set, it calls itself and forkbombs. i guess this is a silly thing to do, what am i misunderstanding?
<fengb>
That's gotta be the weirdest forkbomb I've heard of
<nephele>
without seeing the script that will be difficult to answer
<swills>
#!/bin/sh
<swills>
exec /usr/home/swills/Documents/git/zig/install/bin/zig cc "$@"
<mikdusan>
TheLemonMan: https://github.com/mikdusan/zig.llvm10 -- see gdrive link in readme. currently only have netbsd uploaded. let me know if you are able to download
<nephele>
swills, oh, you might want to prepend a shift maybe? $0 is the executable path of the called thing
<swills>
no
<swills>
tried, same
<nephele>
oh, seems $@ doesn't include $0, dunno then :)
<swills>
and doing make CC="/usr/home/swills/Documents/git/zig/install/bin/zig cc" results in: Unable to link against libc: Unable to find libc installation: unable to spawn system C compiler
<ifreund>
why are you using exec?
<swills>
just something to try, i didn't have it there when the problem started
<swills>
removing it doesn't change anything
<swills>
seems having CC="zig cc" should work, but something else is off
<nephele>
sh seems so overkill to just redirect a command .-.
<fengb>
exec prevents an extra fork but shouldn't do anything else
<fengb>
My guess is that CC="zig cc" looks for the binary named "zig cc"
<swills>
i would say you probably don't want to ship a libc
<swills>
use the system one, it changes, a lot
<andrewrk>
well we want to do the same thing as glibc
<andrewrk>
ship the start files & headers only and then dynamic link
<nephele>
FreeBSD has a compatibility layer for libc changes between releases
<swills>
even the start files and headers change a lot more than glibc
<andrewrk>
ok yeah this is a problem. zig should probably now detect when it is being used as the system c compiler. because for systems that don't have the ability to cross compile for, we interact with the system c compiler
<nephele>
i think it checks the ELF file to see what release it is for
ur5us has joined #zig
<andrewrk>
I'm glad to discover this issue, a fork bomb is a pretty nasty user experience
<andrewrk>
I estimate #2876 to be about 1 day of work for someone who knows what they're doing
<andrewrk>
swills, there's a limit to how much freebsd would change the start files because it would potentially break existing binaries
<andrewrk>
the static bits of dynamically linked libraries are by nature stable
<swills>
right, we support running binaries way way back... like 4.x i think
<swills>
(well, 1.x if you try hard...)
<andrewrk>
yeah, so zig will stay on top of it with each freebsd release, but also there should be no problem producing binaries with older start files
<swills>
true
<swills>
but you can also rely on the source files existing in /usr/src/
FireFox317 has quit [Ping timeout: 240 seconds]
<andrewrk>
not when cross compiling
<swills>
oh, from another OS? ok, sure
<nephele>
swills, why can you rely on that? isn't that an install option?
<swills>
nephele: well, from a certain perspective, you can't rely on anything (even the sun coming up...) *but* from my perspective, which is building ports/packages, it's always there
<nephele>
Does portage even allow you to see that far? :)
<nephele>
err poudriere
<swills>
sorry?
<nephele>
I thought it builds in jails, why should /usr/src from the host be available?
<swills>
it's not from the host
<swills>
it's from the build jail
<swills>
(well, it can be from the host, if you want, but that's another issue...)
<traviss>
anyone know if there is already an issue for switching on multiple values? match in rust supports this and i've found it really nice at times. i couldn't find an issue.
<traviss>
i.e. switch (a, b) { 1, 2 => ..., else => ...}
<andrewrk>
that looks useful and it's unlikely to get added to zig
<andrewrk>
you are welcome to open a proposal and make a case for it
<traviss>
ok i'll give it some thought. i thought it might be possible with tuples but that doesn't seem to work.
<traviss>
i'm guess switch only supports primitive types. makes sense.
<traviss>
*guessing
kenaryn has joined #zig
<andrewrk>
hmmmmmmmmmmmmm. libc++ is basically all stuff we already have in std, but in C++ instead of Zig. Is anyone thinking what I'm thinking?
<andrewrk>
here are some example filenames: filessytem/directory_iterator.cpp mutex.cpp chrono.cpp random.cpp
<companion_cube>
translate-cxx?
hessammehr has joined #zig
<kenaryn>
I can't manage to make zig working again since the latest pre-built tarball. Do I have to use `chmod +x` after downloading the .tar.xz archive?
<andrewrk>
kenaryn, with more details I'm sure we can figure it out
<kenaryn>
you are right, i have a 'no permission' error
<kenaryn>
Agreed, but i did type `tar -xvJf <tarball>`
<TheLemonMan>
ah, you're adding that to PATH later
<TheLemonMan>
you need `chmod +x ~/.local/bin/zig/zig`
<kenaryn>
ah? I'll try in a few seconds
<sammich>
How would i go about converting a c voidpointer and the length of its elements into a zig arraylist or something?
<TheLemonMan>
cast to [*]T and slice it
<ifreund>
kenaryn: it looks to me that you extracted it, then renamed the tarball to zig, put the renamed tarball in your path, then tried to run it
hemulen has joined #zig
hemulen has quit [Client Quit]
nia has joined #zig
<sammich>
TheLemonMan: Thank you!
<nia>
hey, i'm trying to build zig unprivileged on NetBSD. it fails making libuserland on this command https://netbsd.moe/zig.txt but the same command succeeds when run as root. i'm... somewhat scared.
<nia>
i'd like to trace which paths it's trying to access. ktrace doesn't seem useful for this. any advice?
<TheLemonMan>
nia, are you using the version from git?
<TheLemonMan>
truss is your friend
<nia>
TheLemonMan: no, my local tree is 0.5.0 with your recent fixes backported. I can share the patches if you'd like
<TheLemonMan>
oh well, 0.6.0 is around the corner
<jwh>
isn't it /usr/pkg?
<TheLemonMan>
do you experience any problem using `master` ?
<jwh>
(just judging from the --prefix arg)
<nia>
how around the corner? we're branching pkgsrc-2020Q1 this weekend
<nia>
i'd like to get working zig into it ;)
<ifreund>
april 13th is the target date for zig 0.6.0 i believe
<nia>
in the case that it's trying to touch --prefix, it should be working within DESTDIR
<kenaryn>
TheLemonMan I did move the extracted directory (instead of the renammed tarball) to '~/.local/bin' and `chmod +x ~/.local/bin/zig/zig` but I have still '/home/aurele/.local/bin/zig: Permission denied.' when I type `zig --version`
<TheLemonMan>
`/home/aurele/.local/bin/zig:` <- your shell is trying to execute the folder
<TheLemonMan>
andrewrk, that LLVM problem is so nasty, I couldn't get llc to crash... Tomorrow I'll try again with a debug copy of llvm/clang/lld
<andrewrk>
nia, llvm 10 came out just yesterday- it might be wise to wait to branch pkgsrc for a couple weeks to let programs and libraries test with the new version and update
<jwh>
speaking of, is support for 10 in master now?
<andrewrk>
zig is basically in release crunch now; just need to do some bug fixes and polishes now that llvm 10 branch is merged
<andrewrk>
yes
<jwh>
ah cool
<andrewrk>
TheLemonMan, damn. I'll look into it too. I agree it's quite a nasty problem
<nia>
right, true, we won't be able to get llvm 10 in, so it'll have to be 0.5.0
<andrewrk>
ah that's a bummer
kenaryn has left #zig ["WeeChat 2.3"]
<TheLemonMan>
andrewrk, reverting the __divtf3 patch didn't help tho, that's even weirder
<andrewrk>
oh!
<andrewrk>
damn
<TheLemonMan>
I have the faulty zig binary here, I forgot to take the ld.so with me tho
<andrewrk>
hmmmm
<andrewrk>
maybe mikdusan's clue is useful after all
<andrewrk>
why would the cmake thing be different?
<andrewrk>
maybe we can use alpine:stable or something instead of alpine:edge
<TheLemonMan>
hmm, the plot thickens, running zig0 under valgrind (on my x86 box) shows a few warnings in some seemingly related code paths
kenaryn has joined #zig
<TheLemonMan>
maybe it's just a false flag, maybe it's the key to this mistery
<kenaryn>
yes you were right, thanks TheLemonMan and ifreund :)
<andrewrk>
we need scooby doo and nancy drew
<TheLemonMan>
or better, a cocaine-fueled 72h bug hunt
<kenaryn>
Have fun and keep going.
kenaryn has left #zig [#zig]
kevsmith has joined #zig
<TheLemonMan>
nia, check out lib/std/build.zig:797
<TheLemonMan>
it seems that something goes wrong there and some path becomes '/something'
<TheLemonMan>
that would explain the access denied error
ky0ko_ has joined #zig
kenaryn has joined #zig
<kenaryn>
is `target` compilation's option in 0.5.0+39589cffe broken? `zig targets` returns 'Unable to find zig lib directory: FileNotFound.'
<kenaryn>
Reinstall Zig or use --zig-install-prefix.
<kenaryn>
unable to find zig installation directory: ZigLibDirNotFound
<kenaryn>
Sorry, I mean is `targets` command broken?
<TheLemonMan>
mikdusan, fixed that in #4811 just a few minutes ago
Akuli has quit [Quit: Leaving]
<kenaryn>
My apologies.
<TheLemonMan>
no need to apologize :)
<kenaryn>
Is there a way to make bug-related issues graphically or semantically relevant or prioritary (I mean more obvious) in git or even github?
<kenaryn>
I mean, there're 256 open bug and I don't want to spam again in the future.
frmdstryr has quit [Ping timeout: 265 seconds]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<nia>
ah yeah, it's trying to touch the install prefix during build
<nia>
that won't work
<nia>
i can hack around it, possibly
<nia>
providing nothing passed to --prefix gets embedded anywhere
<kenaryn>
This is it. Good night from France :)
kenaryn has left #zig ["WeeChat 2.3"]
FireFox317 has joined #zig
<wilsonk>
adamkowalski: did you get zig building on MacOS?
poga has quit [Ping timeout: 250 seconds]
<fengb>
Silly aside: can we rename "undefined behavior" to "nasal demons"?
<wilsonk>
adamkowalski: I was running into similar issues when I had CC and CXX set to a different clang that the system clang (ie. CC was set to the non-system /usr/local/bin/clang like I see in your cmake output). Try to unset both of those, delete your zig build dir, rerun cmake and hopefully that will work. It worked for me with MacOS Catalina and an updated Xcode from yesterday. You should see that the Apple-11.0... compiler is being picked u
marijnfs1 has quit [Quit: Lost terminal]
marijnfs has joined #zig
marijnfs has quit [Read error: Connection reset by peer]
<mikdusan>
PSA for Apple Xcode users: in light of regular Xcode update, NUKE the following file to force zig to re-populate with latest correct paths:
<andrewrk>
hmm. it was not my original intention to globally cache that file with no redetection
<andrewrk>
why did we move it from local to global again?
<andrewrk>
uh oh mikdusan, I'm seeing some Use-After-Free when running the behavior tests of zig. this appears to be a regression introduced a while back, even before merging llvm10 branch
<mikdusan>
andrewrk: re: global that was at my behest, idea was it was bad to cache _libc.txt in global + N-local caches
<andrewrk>
we should try to remember to run tests in valgrind in the future when we mess with trying to reclaim memory
<mikdusan>
yes that is sound advice
<mikdusan>
I should have done so
<andrewrk>
hmm yeah I think the global one is better than N local ones
<andrewrk>
but maybe better yet would be no caching
<andrewrk>
for all I know it could have been my commits too, I haven't run valgrind in a while
<andrewrk>
a bisect would be useful, but first I'm going to try to just fix it
<mikdusan>
i was actually thinking _currently_ it is better to plop _libc.txt into global, but _after_ we move on self-hosted, we can leverage `zig build` and cache key/values like cmake, only much better so then it would go back into just a per-build cache
<mikdusan>
It's sad that valgrind is probably never going to work on macos again
<andrewrk>
that is indeed sad
<andrewrk>
yeah i'm fine with revisiting the native_libc.txt file after self-hosted is what we ship
<FireFox317>
im not a windows export, but i think its not possible to have async io on stdout/in on windows. We need the same workaround as on linux (making a seperate thread). see this link: https://tim.mcnamara.nz/post/176613307022/iocp-and-stdio
<squeek502>
experimenting with zig cc, running into `__GLIBC_USE is not defined` errors from limits.h in /zig/libc/include/generic-glibc/limits.h; a simple `#include <limits.h>` in test.c and then `zig cc -o test.o -c test.c` is enough to reproduce it for me. any ideas?
<mikdusan>
andrewrk: if valgrind found something after zig_llvm_emit_output, maybe try disable `g->pass1_arena->destruct(&heap::c_allocator);` . that's a big stick tho.
<andrewrk>
squeek502, what target?
<squeek502>
native on ubuntu
<mikdusan>
and my most recent heap free was with commit 770631cc79a655bc5e21184ca15bdb6192e905de ; see ira_deref loop on constants.length, destroying instr with refcount==0 and no-sideeffects
<andrewrk>
squeek502, hmm, I'm confused why I can't repro it
<squeek502>
no worries, i'm probably doing something dumb
<andrewrk>
hm I'm not ready to blame you yet :)
<andrewrk>
ooh I should implement -### which does --verbose-cc
<squeek502>
i can show you my failing zig clang call if that helps?
<andrewrk>
squeek502, hmm, ok so /usr/include/limits.h is interfering with zig's header files. I think I understand the problem. Zig is adding your system native lib dirs because -lc is implied by `zig cc`, and I think any `-l` arg triggers adding native lib dirs
<andrewrk>
and then zig is adding those dirs with -I rather than -isystem, which are incorrectly taking precedence over zig's libc headers
<andrewrk>
as a test can you try replacing -isystem with -I in that command line?
<andrewrk>
there are 5 occurences
<squeek502>
that indeed fixes it
<squeek502>
should i file an issue?
<andrewrk>
hmm ok so that's one possible fix. normally we would want -I args to be able to override -isystem stuff. the problem here is that we only want to ignore the conflicting native system includes, but they're mixed in with potential library header files that we don't want to ignore
<andrewrk>
let me spend 5 minutes trying to fix this while it's fresh in my mind, and otherwise yeah an issue
<squeek502>
ok sounds good
<andrewrk>
this is also a problem with regular zig (when building c files), not just zig cc
<ifreund>
_ = foo() explictly ignores a return value, not an error
<andrewrk>
yeah, one thing I want to investigate is doing away with the msvc dependency entirely
<r4pr0n>
ifreund: yeah, i totally understand that, I phrased it poorly, but I actually wanted to know if and how it's possible to just throw it away instead of panicking when it arrives
<r4pr0n>
but i guess that's what catch undefined does
<BaroqueLarouche>
You should keep msvc support imo, but I agree it should work without msvc installed