waleee-cl has quit [Quit: Connection closed for inactivity]
marijnfs has joined #zig
marijnfs__ has quit [Ping timeout: 268 seconds]
<andrewrk>
nice we have our first mips regression caught by CI
<stratact>
Awesome
<stratact>
andrewrk: I know you're very busy, especially getting Zig ready for 0.5.0 this coming Monday and I was wondering if my PR is mergeable? Or are you saving it until after the release?
<andrewrk>
stratact, ah, is that ready for review? I'll give it a look before monday
<stratact>
It's been ready for a while :)
<andrewrk>
nice I thought you had gotten frustrated and gave up
<stratact>
I was getting tired of thinking about it and wanted to finish it up as soon as possible :)
<fengb>
Was musl ported to riscv? Or does everything just work like magic
<andrewrk>
fengb, I worked with dalias on riscv a bit when llvm9 came out, and carried the resulting patches in zig while waiting for a new release
<andrewrk>
all the patches are upstream in master, except 40e77dad836abf130bf49af1838d108f0fc2e94e which I'm confused why they haven't merged upstream yet
<stratact>
andrewrk: I'm sorry for being misleading though, I didn't give up on completing it. When you said that large fixed sized buffer are a-okay, that was the que for me to wrap the PR up and ship it. 😄
<andrewrk>
got it :)
<andrewrk>
looking forward to reading it
<stratact>
Should be a nice and easy read
<stratact>
Oh I probably should rebase from master though, since std/ is in lib/
<andrewrk>
I heard that git rebase is smart enough to figure it out
<stratact>
Awesome, I'll try it
<fengb>
Catching up on the stream and holy crap it’s amazing to see the window library be maximally performant without knowing about async
<stratact>
andrewrk: Perfection worked as expected. Rebased and squashed.
<andrewrk>
thanks! hopefully will get a chance to peek tomorrow. I'm a bit behind on release notes quota today from the stream
<stratact>
No worries and thanks
<andrewrk>
and I still want to play Noita tonight :)
<stratact>
Sounds fun. I'm rebooting into system upgrade, I'll brb
stratact has quit [Quit: Konversation terminated!]
stratact has joined #zig
doesntgolf has quit [Ping timeout: 240 seconds]
dimenus has quit [Ping timeout: 245 seconds]
mahmudov has quit [Remote host closed the connection]
owl_000 has joined #zig
chemist69 has quit [Ping timeout: 246 seconds]
chemist69 has joined #zig
owl_000 has quit [Ping timeout: 265 seconds]
avoidr has quit [Quit: leaving]
<nrdmn>
eh, wasn't sure if I should move a few things in std/os/uefi, but I think I'll leave it for now.
<nrdmn>
but I've added a PR for allocatePool and exitBootServices, which is what most OS developers will be looking for
uranther has quit [Quit: Connection closed for inactivity]
<andrewrk>
nrdmn, I'm pretty much going to accept any PR you send my way if it's UEFI related and doesn't affect anything else
<andrewrk>
at this point I trust your judgement on these matters
<donaldallen>
const lib = @import("../library/lib.zig"); results in the compiler error: import of file outside package path: '../library/lib.zig'. I can take care of this with a symlink, but curious as to why the relative path doesn't work.
<donaldallen>
I should add that the relative path is valid and the symlink does work.
<andrewrk>
donaldallen, this is in preparation for package manager. the best way to deal with this is not with a symlink but by setting the package root dir explicitly. --main-pkg-path
<andrewrk>
a symlink introduces a system dependency into your project, and one of zig's main goals is to reduce system dependencies
<donaldallen>
Ok, thnx.
<andrewrk>
donaldallen, if it helps, the default main package path is the cwd from where zig is run
<donaldallen>
I've got a directory for the whole project, with subdirs for each component, including the library. This occurred in building one of the components. Making the --main-pkg-path the project directory should fix this. I'll let you know if not.
<andrewrk>
donaldallen, another way to solve this would be in your build script using addPackagePath. you can use this to create arbitrary mappings for use with @import
<donaldallen>
--main-pkg-path works fine. Still building the old fashioned way, with a makefile, but switching to the build system is high on the agenda.
waleee-cl has joined #zig
<andrewrk>
oh, the cli version of addPackagePath is --pkg-begin [name] [path] and --pkg-end
<andrewrk>
the build system is still invoking the CLI
<donaldallen>
Thanks for the help. Gotta go ....
donaldallen has left #zig [#zig]
Hirezias has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
keegans has joined #zig
<keegans>
how can i tell the zig build system to use the Android NDK sysroot and link against the libc ? the farthest i've gotten was some linking errors while looking for crt* stuff
<keegans>
looking to build an Android aarch64 executable with zig
<andrewrk>
keegans, have you looked at the --libc parameter and `zig libc` command?
<keegans>
yes- not certain i fully understand it . i dumped the libc configuration for the default setup and then modified it a bit but ran into some issues , let me give it another try
<andrewrk>
keegans, that's all I was asking, if you had tried that, ok
<Yardanico>
keegans: hmm, you reminded me, gonna try to build zig in termux on android again
<andrewrk>
keegans, zig probably needs some android-specific adjustments to link.cpp for android
<keegans>
i'm willing to put in some work to get it going , i will just need a little bit of direction
<keegans>
let me get back to the broken state where i was and then i'll work from there
<andrewrk>
keegans, it will probably be helpful to look at what a c compiler puts on the linker line when targeting android, and compare to what zig is doing with --verbose-link
<andrewrk>
keegans, I'll be here all day :)
<keegans>
awesome :D i'll give the verbose link a try
<ceymard>
is it normal that `zig translate-c stdio.h` segfaults ?
<ceymard>
I suppose not
rifkik has joined #zig
<Yardanico>
btw, I'll also test some Zig stuff on an aarch64 android tv box with amlogic s912 (8 cortex a-53 cores + 3gb ram) when it arrives (I'll install linux there though)
<andrewrk>
yeah that has to do with some stupid constructor/destructor thing that nobody in their right mind uses
<keegans>
that was the script i used to link the produced Zig object file
<keegans>
sounds good
<Yardanico>
btw, is there a simple way to iterate over lines in file? or do I have to open the file, read the data, create a slicestream, and only then get stream of data from that?
<keegans>
also when using zig build-exe how do i specify that i'd like a dynamically linked executable , just for future reference?
<andrewrk>
Yardanico, did you see readUntilDelimiter functions?
<keegans>
because i run this stuff in a chroot so there is really no need for this to be static honestly
<keegans>
( since i ship the libc and android bins in the chroot )
<andrewrk>
Yardanico, there isn't a non-allocating one though
<Yardanico>
well yeah, basically that's what I used before
<andrewrk>
keegans, -dynamic. zig generally tries to make things static where possible though
<keegans>
ah i was misled by the description : -dynamic create a shared library (.so; .dll; .dylib)
<andrewrk>
yes the description is outdated. that flag also does not have good test coverage for build-exe
<andrewrk>
keegans, are you interested in submitting a pull request to link.cpp to make android stuff work?
<keegans>
yeah , if that's cool
<andrewrk>
yeah if you can describe the testing process; I'd like to try setting up the ndk and running some of the examples myself
<Tetralux>
Wait - what does -dynamic actually do then?
<keegans>
for sure . i'll get zig built and then hack away at it. i am not clear on exactly how i should get the NDK path from the user , though
<keegans>
should there be like a configuration file or another flag in libc.txt ... i am not sure
<keegans>
because we also need to request an Android SDK version
<keegans>
and only like NDK 19+ is clang-only, so supporting old NDK versions is probably? not easily doable
<andrewrk>
keegans, this is where the libc.txt file comes in
<andrewrk>
the current fields are not adequate to find all the directories?
<keegans>
is it possible for me to pass multiple link directories ?
<keegans>
if so then yes i guess you could specify all the paths but it won't be exactly intuitive
<andrewrk>
crt_dir and static_crt_dir are both link directories
<andrewrk>
if it makes sense to do we can also add fields or adjust the comments on that file
<keegans>
yeah i'll play around and let you know what's up
<andrewrk>
that file is exactly for this purpose; if it's not correct then it needs to be adjusted to be correct
<rifkik>
Should I upgrade my Emulator Code to Master now?, or should I wait until 5.0 stabilises
hasanyasin has quit [Remote host closed the connection]
hasanyasin has joined #zig
avoidr has joined #zig
owl_000 has quit [Ping timeout: 240 seconds]
hasanyas_ has joined #zig
<keegans>
andrewrk: so can i specify multiple include dirs and library dirs with libc.txt ?
_Vi has quit [Ping timeout: 276 seconds]
Hirezias has joined #zig
hasanyas_ has quit [Client Quit]
hasanyasin has quit [Remote host closed the connection]
FireFox317 has joined #zig
telemach has quit [Ping timeout: 265 seconds]
<FireFox317>
6 more PRs merged and we have 1000 closed PRs, would be so nice if we have exactly 1000 PRs closed at the 0.5.0 release ^^
<rifkik>
andrewrk, how much do you want to add and stabilise until you can make a 1.0 release?
<FireFox317>
rifkik, so much. Just scroll a bit through the open github issue. Especially the accepted proposals and you will see some nice things there
wootehfoot has quit [Read error: Connection reset by peer]
wootehfoot has joined #zig
<keegans>
i compiled LLVM with z3 support, and that ultimately breaks the linking phase of Zig because it incorrectly links LLVM ( i.e. : doesnt use pkgconfig )
<keegans>
what is the fix for this ? just patch it locally by linking against z3 explicitly in the zig_cpp target link libraries, or actually fixing the llvm linkage in the Cmake
<keegans>
for now i have just patched it locally
<companion_cube>
wait, llvm uses z3? :s
<keegans>
you can optionally enable SMT solving for the clang static analyzer
<keegans>
the flag is LLVM_ENABLE_Z3_SOLVER
<companion_cube>
oh, static analyzer, right.
<keegans>
yeah sorry what i said didnt actually make any sense now that i read it over lol
<andrewrk>
keegans, that should work since we use `llvm-config --system-libs` in the build
<andrewrk>
can you confirm that `llvm-config --system-libs` has -lz3 for you?
<keegans>
ha nope
<keegans>
it doesn't
<andrewrk>
sounds like an upstream bug
<keegans>
yep
<keegans>
i'm almost done this android linkage stuff then i'll have to take a look over it to make sure i haven't gone and randomly broken other shit
<andrewrk>
keegans, does the NDK come pre-built? (with the .o files and stuff) is it open source?
<keegans>
yes and yes
<keegans>
the libc is bionic which is also open but a massive pain in the ass to build
<scientes>
and sucky
<andrewrk>
typical google software
<andrewrk>
wow even on the home page for bionic: # This is the biggest mess. The C++ files are ...
<scientes>
nobody ever took that libc seriously
<andrewrk>
if you write zig for android you might not need libc
<scientes>
it was done that way to avoid glibc
<andrewrk>
honestly it might be more worth to flesh out our own multi-target libc than to try to ship bionic
<scientes>
andrewrk, well some libraries might need a libc
<keegans>
yeah in my case i need bionic
<keegans>
because i want to dlopen
<scientes>
keegans, for what, specifically?
<andrewrk>
does zig provide dlopen in its libc yet? let me check
Hirezias has quit [Ping timeout: 246 seconds]
<scientes>
keegans, yeah but that is what libhybris does and its a blank hole of wasted time
<keegans>
nah libhybris is great
<keegans>
like yeah it is garbage but like when it works it is super useful
<andrewrk>
hm not yet, but zig's libc will support dlopen eventually
<keegans>
which lets us launch Minecraft Android on Linux
<keegans>
hybris is just a copy-paste of Android's linker code and then hacks to fix binary incompatibilties between glibc and bionic
<keegans>
so you can load bionic applications on glibc linux
<keegans>
i've used it for a many other android natives , too
<keegans>
"zig's libc will support dlopen eventually" what do you mean ?
Hirezias has joined #zig
<andrewrk>
zig has its own (not fully complete) implementation of libc that works for all targets
<scientes>
by dlopen he means loading non-free bionic libraries
<keegans>
right so you have to implement all the random garbage that the bionic linker does then too
<scientes>
keegans, zig does namespace C symbols which means you can mix and match libcs (although that is not fully tested, and there might be problems that come up)
<scientes>
*C names
<scientes>
symbols is another namespace
<keegans>
ah interesting
<andrewrk>
keegans, yeah that's fine, that'll just be part of the arm-linux-android target
<keegans>
cool ! i will certainly be using that linker for other things too then ...
<andrewrk>
I'm describing vaporware, but the point is it's in scope of the zig project
<keegans>
yeah
<keegans>
ok with my changes ldd is complaining that it's missing __errno_location
<keegans>
hmm
<andrewrk>
that sounds like it should be provided by -lc
<keegans>
right that doesn't exist on bionic, right
<scientes>
ewwww, errno was a massive mistake
<scientes>
what a stupid idea
<keegans>
no i am saying yeah bionic does not have __errno_location
<keegans>
sure but i mean i can have my own annotations as an end user
<Tetralux>
Like `annotate(XXX)`
<keegans>
yeah my thinking was i can mark really anything , function or struct with an annotation that has an arbitrary name and then i can pass whatever comptime stuff i want to it as well
<keegans>
and noinline, threadlocal, and all this calling convention stuff can also just be an annotation
<andrewrk>
that's a good proposal
<keegans>
i will think about it a bit more and then write something up
<keegans>
anyway back to what i was doing on Android -- why can i not have a top-level compile time if in linux.zig
<keegans>
it is angry because it says invalid token if and i am unclear as to whats up
<keegans>
or how i should implement this checking for ABI
<andrewrk>
you can have top level compile time
<andrewrk>
happy to help if you show the output
<mq32>
andrewrk, cool thing pro annotations: you could comptime the argument (so changing calling convention by comptime computations)
<keegans>
i will say that the error formatting is annoying
<keegans>
i gotta scroll all the way up each time
<andrewrk>
keegans, what version of master branch are you working based on?
<keegans>
just cloned like an hour ago
<keegans>
then started my own branch
<andrewrk>
hmm. this looks like something that was fixed by 2c8864f yesterday
<andrewrk>
oh lovely I can reproduce this
<andrewrk>
the big stack of "referenced here" is a recent problem, that won't stick around forever. it was originally to help with dependency loops, but I took it too far
Ichorio has joined #zig
<andrewrk>
keegans, give me a minute I'll fix this
<keegans>
thank you
halosghost has quit [Quit: WeeChat 2.6]
<andrewrk>
keegans, this has uncovered 2 separate issues, which I am interested in fixing. But not today. So I'm going to do a workaround here for you
<scientes>
why does translate C create AstNodes?
<scientes>
it seems it would be saner to create ZigType first
<scientes>
oh OK, I just ran into the deprecated code not supporting gcc's vector extensions
<andrewrk>
we're trying to move to self-hosted translate-c
<andrewrk>
see src-self-hosted/translate_c.zig and `zig translate-c-2`
<scientes>
which my patch set supports for creating C header files
<andrewrk>
and test/translate_c.zig
wootehfoot has quit [Read error: Connection reset by peer]
<scientes>
ahh its in clang.zig
<andrewrk>
scientes, that file is synchronized with zig_clang.h and zig_clang.cpp
<scientes>
and how do i get @cInclude to use translate-c-2?
<scientes>
and i guess in the self-hosted code we could use ZigType without @reify
<scientes>
*couldn't use
<andrewrk>
scientes, that's not wired up because it's not passing enough tests
<andrewrk>
you can see the coverage in test/translate_c.zig
<scientes>
ok, guess i'll have to write my benchmark in C
<andrewrk>
even in the self-hosted version your question is still applicable
<andrewrk>
we're going from C-with-types to zig source
<andrewrk>
creating a .zig file, and then that gets loaded and analyzed like normal
<scientes>
oh yeah, Zig types are consts so we have to have ZigType there too
<andrewrk>
we used to create zig types directly. I'm confident that going straight to source is a better approach, having done it both ways
<scientes>
oh ok
<andrewrk>
this is better for caching and debugging
<andrewrk>
keegans, I'll open an issue for the other thing. It's a bug in Zig. Here's my suggested workaround for you: https://clbin.com/rJRMA
<keegans>
thanks
<keegans>
ok it seems that this threadlocal approach is not working andrewrk , "lld: error: undefined symbol: __emutls_v.errno"
<keegans>
the symbol is referenced from ./main.o:(std.c.linux._errno.getErrno) as expected
<keegans>
so the symbol is not being bound to errno but rather __emutls_v.errno which is strange
<keegans>
i did not know of this behaviour
<scientes>
keegans, you need to use thread_local
<scientes>
or whatever the zig keyword is
<andrewrk>
I wonder if this is llvm or lld being too clever with the android target
<keegans>
scientes: yes it is marked as threadlocal, which is the cause of this problem
<andrewrk>
I'm asking in #llvm
<keegans>
thanks
philipwhite has joined #zig
<andrewrk>
keegans, is it aarch64 or arm? v8? v7?
<keegans>
aarch64v8
<andrewrk>
keegans, https://godbolt.org/z/N9I5jK note how it changes when you delete `-android` from the -target arg
<keegans>
ha
<keegans>
so they are doing some hackery
<andrewrk>
keegans, can you join #llvm on OFTC?
<keegans>
yeah one sec
<keegans>
im here
<keegans>
missed the context though
<keegans>
so if i remove the threadlocal i now have `lld: error: undefined symbol: errno` what
<andrewrk>
the symbol might be named something else, such as `_errno`. check the .o file / .a file with objdump
<keegans>
oooh
<keegans>
yeah it's __errno duh
<andrewrk>
that's weird that it's not threadlocal though. how is that supposed to work?
<keegans>
yeah good question
<keegans>
i will investigate further soon
<keegans>
anyway it links now !
<keegans>
"./main": error: Android 5.0 and later only support position-independent executables (-fPIE).
<keegans>
but it is not a PIE
<keegans>
zig is not pie by default when dynamic ?
<andrewrk>
keegans, make target_requires_pic return true in target.cpp when target_is_android is true
<keegans>
will do thanks
<andrewrk>
keegans, we may also want to introduce target_requires_pie (side note: love that function name) and make link.cpp check it for construct_linker_job_elf() and add -pie to the linker line in this case
<keegans>
unfortunately it doesnt seem like that fixes it
<keegans>
ah
<andrewrk>
yeah the pic thing is still a good change to make though
<keegans>
true^ and yeah that seems like a good way to go
<keegans>
i'll do that
<keegans>
what other platforms do i add to target_requires_pie , though ?
<andrewrk>
we can talk about -dynamic making things PIE later, but this is still a good thing to do, force it on android
<scientes>
yeah android requires pic
<andrewrk>
only enable it for android for now
<andrewrk>
it's just going to have 1 callsite, in construct_linker_job_elf
<andrewrk>
for now
<keegans>
:+1:
<keegans>
"All your base are belong to us." success!
<andrewrk>
keegans, this is good stuff, I think we're going to be able to add a column to the support table for Android after your changes are merged
<keegans>
exciting !
<keegans>
thank you for your help
<andrewrk>
np, looking forward to your patch
<philipwhite>
what is the right way to read stdout from a ChildProcess? I'm rather confused by the standard library. running v0.4.0, so maybe there's been some changes, but I imagine not too much.
utzig has joined #zig
telemach has joined #zig
Akuli has quit [Quit: Leaving]
<keegans>
so i can no longer produce fully static executables like i could earlier hmm
<keegans>
i'll put up the pr but i've gotta fix that before you should merge
<keegans>
because it is confusing what libc do i link against anyway