<andrewrk>
the part where it does not improperly wrap is nice though :)
<Snektron>
How far along is the zig cc/zig c++ part of the llvm12 branch? I need some c++20 features on a remote machine which doesn't have a capable compiler (and i'm not authorized to install one), so zig is probably the easiest option.
<andrewrk>
Snektron, let me sync master right now. afaik it's working fine. what target(s)?
<Snektron>
x86
<Snektron>
(_64)
<andrewrk>
Snektron, ok master is merged in. it should work flawlessly, let me know if you run into anything
<Snektron>
Alright, thanks. I need a musl version of the llvm12 libraries in order to build a musl version of zig, right?
<andrewrk>
no
<andrewrk>
let me sync the zig-bootstrap repo and you'll have an easy time I think
<Snektron>
That was my guess as well :) thanks for syncing for me
<andrewrk>
np
pta2002 has joined #zig
pta2002 has quit [Client Quit]
<andrewrk>
mikdusan, you're only supposed to edit clang_options_data.zig indirectly, by modifying tools/update_clang_options.zig
<mikdusan>
ah ok will fix
<daurnimator>
TIL MREMAP_MAYMOVE is a thing
<andrewrk>
Snektron, zig-bootstrap, master branch, is what you want I think
<Snektron>
thanks a lot
<andrewrk>
np
<g-w1>
so zig-bootstrap has llvm12 but zig has llvm11?
<andrewrk>
g-w1, llvm12 branch has llvm12. zig-bootstrap master branch tracks zig llvm12 branch and llvm release/12.x branch
<g-w1>
ah
gazler_ has joined #zig
gazler has quit [Ping timeout: 256 seconds]
nvmd has quit [Quit: Later nerds.]
<mikdusan>
heh byte-for-byte identical :)
<andrewrk>
nice :)
notzmv has joined #zig
<mikdusan>
it occurs to me all this .td and tbl-gen stuff... if one were to write llvm in zig today... that's all comptime stuff
<mikdusan>
but if really really heavy, yeah I get it might be preferable to pregen
<andrewrk>
yep
<Snektron>
hm, i'm running into a problem. I've compiled everything using zig-bootstrap for target native-native-musl with mcpu=native also.
<Snektron>
Zig cc now reports native-native-unknown-musl as target, and some component of my build system (meson) isn't able to deal with that.
<Snektron>
It seems meson passes `-E -dM -` to `zig cc`, and it indeed reports that as problematic
<mikdusan>
error: macho does not support linking multiple objects into one
<andrewrk>
Snektron, what is the problem? zig cc not handling those cli args correctly?
<Snektron>
I'm not sure whats the desired result here honestly wrt to cross compiling. Setting CXX to `zig c++ -target x86_64-linux-musl` instead of `zig c++` makes everything work.
<daurnimator>
oh that reminds me; we need to add support for x86_64-v2 and v3
<daurnimator>
or at least figure out our equivalents
<Snektron>
if i run `echo | zig cc -E -dM -` on my local build everything works, but the same doesn't work with the native-native-unknown-musl version.
<mikdusan>
daurnimator: is that a clang or gcc or both thing?
<daurnimator>
botg
<daurnimator>
both
<andrewrk>
daurnimator, that's already supported with -mcpu=x86_64_v2
<mikdusan>
i was just looking at llvm triples source code and x86_64_v2 is not an "arch"
<andrewrk>
Snektron, what's the meson error message?
<Snektron>
Seems like the rc3 version of llvm is still missing a feature required for my project, though master seems to contain it according to godbolt. I think its a problem in libcxx, would i just be able to update the libcxx sources in the zig directory to master and expect it to work?
<mikdusan>
Snektron: and what I saw before is if I switched from `-E ... -` to `-E ... empty.c` a valid -triple is sent to cc1
<Snektron>
yep, it seems you're right
<andrewrk>
is zig passing 'native-native-unknown-musl' to llvm or clang? we have a function for passing a proper llvm triple and it won't have "native" in it
<andrewrk>
I want to know where that 'native-native-unknown-musl' string is getting generated / passed to llvm/clang
<mikdusan>
all we see is the cc1 so can't tell
<mikdusan>
wait. strace. lol
<mikdusan>
oh that won't work. embedded.
<andrewrk>
it will work
<andrewrk>
Snektron, re: libcxx that is worth a try
<Snektron>
Alright, will try that tomorrow.
<andrewrk>
Snektron, I have a workaround for you - in build script change -DLLVM_DEFAULT_TARGET_TRIPLE="$TARGET" to x86_64-linux-unknown-musl
<andrewrk>
but we should really find out where zig is incorrectly allowing llvm to use this value instead of overriding it
<Snektron>
Especially strange since its only the case when reading from stdin. At least it narrows the places to look.
<andrewrk>
zig unconditionally passes -target. I think it's an llvm bug
<andrewrk>
but I expect the workaround to work
<Snektron>
Anyway thanks for the workaround. Ill also try that tomorrow, its getting late
<mikdusan>
I wish github has a selective highlighter for syntax-colored langs. tired of overloading `diff` and losing subject syntax colors
<mikdusan>
andrewrk: #8232 is pr for `zig cc -E -` bug with Snektron; was kind of hoping it would be fewer lines :(
xackus_ has quit [Ping timeout: 245 seconds]
fputs has quit [Quit: WeeChat 3.0.1]
bitmapper has quit [Quit: Connection closed for inactivity]
semarie has quit [Ping timeout: 276 seconds]
semarie has joined #zig
mmohammadi9812 has joined #zig
cole-h has quit [Ping timeout: 276 seconds]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
kshlm has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
semarie has quit [Quit: WeeChat 3.0.1]
mmohammadi9812 has quit [Quit: Leaving]
craigo has joined #zig
earnestly has joined #zig
semarie has joined #zig
_whitelogger has joined #zig
sord937 has joined #zig
sord937 has quit [Client Quit]
sord937 has joined #zig
sord937 has quit [Client Quit]
gphilipp has joined #zig
yyp has joined #zig
gphilipp has quit [Quit: Going offline, see ya! (www.adiirc.com)]
forgot-password has joined #zig
yyp has quit [Quit: disconnected]
yyp has joined #zig
kevinsjoberg has joined #zig
forgot-password has quit [Ping timeout: 245 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 246 seconds]
TheLemonMan has joined #zig
klltkr has joined #zig
craigo has quit [Quit: Leaving]
companion_cube has quit [*.net *.split]
lunamn has quit [*.net *.split]
lohengrin has quit [*.net *.split]
torque has quit [*.net *.split]
mipri has quit [*.net *.split]
benaiah has quit [*.net *.split]
Stephie has quit [*.net *.split]
mmurd has quit [*.net *.split]
noam has quit [*.net *.split]
Thalheim has quit [*.net *.split]
lonjil has quit [*.net *.split]
allan0 has quit [*.net *.split]
edr has quit [*.net *.split]
Cloudef has quit [*.net *.split]
shodan45 has quit [*.net *.split]
lonjil2 has joined #zig
Cloudef has joined #zig
benaiah has joined #zig
mmurd has joined #zig
companion_cube has joined #zig
torque has joined #zig
lohengrin has joined #zig
lunamn has joined #zig
edr has joined #zig
midgard has quit [Ping timeout: 246 seconds]
crimson_penguin has quit [Ping timeout: 246 seconds]
allan0 has joined #zig
notzmv has quit [Ping timeout: 264 seconds]
crimson_penguin has joined #zig
Stephie has joined #zig
midgard has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
zags has joined #zig
leon-p has joined #zig
Voltaire has joined #zig
dimenus has joined #zig
<s-ol>
is there any way to generate functions as decls in a struct (at comptime)?
<s-ol>
I want to wrap a C library that wraps C++ code. It has lots of struct types that contain function pointers (which are optional when cImport'ed) in different sub-structs
<s-ol>
I want to generate a wrapper-type around one such struct that lifts up that creates one decl-function for each vtable-field that is a function-pointer. The decl-function should then delegate to the vtable-fp
<s-ol>
I can use @typeInfo() to look into the vtable and get the fps and their types, but can I even declare functions? Do I need to generate zig code in a separate build step and then import it in a later one to make this happen?
<ifreund>
I bet there's another way to achieve what you want though. Code generation in a build step would certainly work but I'm not sure it's necessary
<ifreund>
s-ol: is the issue just that the function pointers are optional so they aren't very ergonomic to call directly?
<s-ol>
ifreund: that, and there are two layers of C pointer-nesting to get to them
<s-ol>
the base type is struct{ vtable: [*c]struct{ IfaceA: [*c]struct { method: ?fn(...), ... }, IfaceB: [*c]struct { ... } } }
<s-ol>
ah, I didn't know #6709 wasn't implemented, that explains what I hit the other day doing something simpler. So this kind of type-generation is a nogo currently then
mikdusan has quit [Quit: WeeChat 3.0.1]
<ifreund>
s-ol: what library is this out of curiousity?
<s-ol>
both macros aren't translated, so I'm just left with the base struct type (the "This")
<s-ol>
My first thought was just to make a proper C wrapper with a header file, but there's no easily machine-readable info about arguments and argument-types, so zig's cImport is actually the best starting point I have atm
<ifreund>
hmm, yeah I see the problem
forgot-password has joined #zig
notzmv has joined #zig
bjornroberg has joined #zig
mps has joined #zig
<s-ol>
going down the code-gen route, whats a good way to replace the module name in an @typeName() like "[*c].cimport:3:11.struct_IRenderDevice" with a known constant?
<s-ol>
e.g. here I would like to replace '.cimport:3:11' with just 'c' and emit a 'const c = @cImport...' above
<s-ol>
what are the :3:11 there? it looks like a position in a file but they are all the same
bjornroberg has quit [Ping timeout: 264 seconds]
forgot-password has quit [Ping timeout: 264 seconds]
factormystic has quit [Remote host closed the connection]
factormystic has joined #zig
factormystic has quit [Remote host closed the connection]
factormystic has joined #zig
cole-h has joined #zig
forgot-password has joined #zig
<ifreund>
s-ol: I think that's the location of the @cImport() in your zig file
<ifreund>
s-ol: also one workaround to avoid the codegen I thought of, this should be possible:
<ifreund>
Method would be an enum of all the methods of the interface
<ifreund>
and the function pointer return type would be determined at comptime based on that enum
<ifreund>
usage would look like factory.call(.create_devices_and_contexts)(arg1, arg2)
<ifreund>
not ideal, but maybe better than codegen?
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
forgot-password has quit [Ping timeout: 256 seconds]
<ifreund>
s-ol: also with regard to the cimport type, struct_IRenderDevice would be what you actually use in code
<ifreund>
the line numbers are just for the compiler error message since type names may not be unique
zags has quit [Ping timeout: 276 seconds]
notzmv has quit [Ping timeout: 264 seconds]
<ifreund>
actually, translate-c should generate an alias for the type so just IRenderDevice should work
<mps>
is it possible to build zig 0.7.1 without some targets (hexagon in my current case) and how?
wootehfoot has joined #zig
zags has joined #zig
<s-ol>
ifreund: that sounds comfortable enough actually, i will give it a try
wootehfoot has quit [Read error: Connection reset by peer]
notzmv has joined #zig
notzmv has quit [Ping timeout: 256 seconds]
notzmv has joined #zig
forgot-password has joined #zig
cole-h has quit [Ping timeout: 256 seconds]
wootehfoot has joined #zig
Voltaire is now known as Thalheim
mikdusan has joined #zig
txdv has joined #zig
Akuli has joined #zig
<txdv>
Can I comptime read a file, parse the json and embed the values into my binary?
<ifreund>
txdv: @embedFile() will give you the file contents as bytes at comptime
<ifreund>
so yes
<ifreund>
as for parsing the json at comptime, that's actually the example on the homepage: https://ziglang.org
<txdv>
This is crazy, I have seen so many times when people generate C code from XML or another annotation language, where they have listed for example OP CODE of their virtual machine and in zig it seems like you can do that within zig
<txdv>
That example is comptime?
<txdv>
O, since everything is just an expression it can actually do that
<ifreund>
txdv: all global variables must be initialized at comptime
<ifreund>
so yeah the json parsing in that example happens at comptime
forgot-password has quit [Ping timeout: 264 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 256 seconds]
klltkr has joined #zig
waleee-cl has joined #zig
<dimenus>
the simplicity you get from everything being the same language cannot be overstated
wootehfoot has quit [Read error: Connection reset by peer]
a_chou has joined #zig
isolier6 has joined #zig
isolier has quit [Ping timeout: 246 seconds]
isolier6 is now known as isolier
a_chou has quit [Remote host closed the connection]
<ugla>
I was reading about a new Rust feature (const generics) and tried it in Zig, and it just worked. I also tried some of the planned future features to expand on const generics, and that also worked.
<andrewrk>
haha
<ugla>
I like Rust for some things, but it's so sweet how a few carefully chosen features can replace a whole ton of them.
<andrewrk>
comptime is a really nice language simplification
<ugla>
Yeah :)
layneson has joined #zig
<dimenus>
andrewrk: i submitted a very small pr for zig-bootstrap fyi, just adding a line to cmake. I was unable to get llvm12 to build when my host had llvm11
<dimenus>
it matched the wrong llvm-config
<andrewrk>
dimenus, hmm interesting. we're actually wanting cmake to hit the last block in the else-if chain tho for the zig-bootstrap case
<andrewrk>
we might need another cmake option to force it
<dimenus>
andrewrk: in this case i was building native baseline so it triggered the native case rather than the last else block
<andrewrk>
yeah I see
<dimenus>
another cmake option is probably better
<yyp>
I think it should be submitted to upstream ziglang/zig repo instead of zig-bootstrap which just vendors it
<andrewrk>
dimenus, do you mind handing this off to me and I solve it a different way?
<andrewrk>
thanks for the initial investigation :)
<dimenus>
andrewrk: not a problem
<dimenus>
i figured it might not be the most optimal solutoin and might just start the conversation
<dimenus>
*solution
<andrewrk>
yeah you did the hard part already
<dimenus>
yyp: understood, i thought about that but this is an interesting case since the zig folder isn't a submodule, its just a specific snapshot in time
<yyp>
Yeah, that's werid. Submodules do the same (snapshot in time)
<mps>
andrewrk: sorry for impatience but have you seen my question above, i.e 'is possible to build zig 0.7.1 without some targets (hexagon in my current case) and how?'
<mps>
people on alpine waits and asks about 3 months for zig 0.7.1, when it will be upgraded
<mps>
llvm11 on alpine disabled hexagon target because some tests failed on some arches
<andrewrk>
since a primary use case of zig is cross compiling, you have to patch/fork zig if you want to disable targets. it's not officially supported
<mps>
ah, ok. will wait few days, maybe someone will fix llvm in meantime
<mps>
if not, patch is only option
<mikdusan>
andrewrk: wrt #8218, what is the goal of -fcompiler-rt; to resolve what is _needed_ of compiler-rt and thus just have local defs, or embed _all_ syms and have global defs?
<mikdusan>
I slapped together a "_ = @import("compiler_rt.zig") thing in start.zig, based on a new builtin.embed_compiler_rt and it works, but it _all_ syms are there right now.
<yyp>
mps: how did you even get LLVM 11 on Alpine?
<andrewrk>
mikdusan, interesting idea, doing it with start.zig. So let's break this problem down:
<andrewrk>
when building a static library, -fcompiler-rt means there should be a compiler_rt object inside the static archive
<mikdusan>
and 100% syms ?
<mps>
yyp: no, sorry, date is Fri Mar 12 22:51:34 2021 +0100
<andrewrk>
note that we build it with -ffunction-sections so that the linker can strip unused functions, and we also export all the symbols weak, so that someone can override any of the symbols if they want to
<mikdusan>
yup with you so far
<andrewrk>
for ELF, LLD actually supports linking two object files together into one. we currently take advantage of that right now. this is nice because the -ffunction-sections applies only to compiler_rt and not the rest of the zig code
<andrewrk>
for the use case of build-obj combined with -fcompiler-rt, likely the situation is that the user is plugging zig into an existing build system, and perhaps a different linker. they just want the .zig code to work, which requires compiler-rt functions
<andrewrk>
ideally the unused functions would get stripped, but if that's not possible, we'd rather have them all than none
<mikdusan>
ok how about this. do we have ability at comptime to export vs. not export
<andrewrk>
yes
<andrewrk>
but we don't know until LLVM's optimizer finishes running (at the very end) what compiler_rt functions we need
<mikdusan>
effen llvm.
<mikdusan>
what's an example code path I can use in .zig to force llvm to need a compiler_rt sym?
<andrewrk>
target a 32 bit architecture and do multiplication on a u64
<mikdusan>
ok. I'll tinker with this a bit
<andrewrk>
I think the null hypothesis here is to have -fcompiler-rt used with build-obj to, in stage1, do the equivalent of `_ = @import("compiler_rt")`
<andrewrk>
then we would do that for non-ELF targets
ur5us has joined #zig
<andrewrk>
mikdusan, btw thanks for taking a look into this :) I happen to know rtfeldman - the one interested in this working - and he's working on an interesting project that I think will be announced soon, rumor has it there is some zig powering it :)
<mikdusan>
nice
<andrewrk>
mikdusan, also thanks for #8232 - give me a bit of time to look into whether we want to try to go through the rest of addCCArgs as well, maybe punt_to_clang would have other issues as well
<andrewrk>
we might need to make the control flow go through the main way that clang is invoked
mps has left #zig [#zig]
zags has joined #zig
zags has quit [Ping timeout: 260 seconds]
<mikdusan>
sure. #8232 smells for sure. if you want the control flow reworked let me know.
<andrewrk>
mikdusan, I have another approach for you to try- punt_to_clang is only supposed to be called for trivial stuff like --help and "no input files"
<andrewrk>
I think all we need to do is adjust the logic that detects if there are no input files to include `-` as counting as an input file (stdin)
<mikdusan>
ok so let it fall thru and hit the cases below. got it.
<andrewrk>
then `clang_preprocessor_mode = .stdout` happens and I think everything else will work correctly
<andrewrk>
because we already have the "passthrough_mode" concept, which will be enabled in this case
voldyman has joined #zig
yyp has quit [Quit: disconnected]
ur5us has quit [Ping timeout: 264 seconds]
wilsonk has quit [Quit: Leaving]
zags has joined #zig
<dimenus>
andrewrk: will do
<andrewrk>
dimenus, hold on I already found a problem and fixed it and am pushing the fix
<andrewrk>
dimenus, pushed. I'm pretty sure the issue is solved now
<dimenus>
andrewrk: sounds good, thanks for your help
<andrewrk>
np, thanks for the initial exploration
sundbp has joined #zig
wilsonk has joined #zig
cole-h has joined #zig
Akuli has quit [Quit: Leaving]
aconbere has joined #zig
<aconbere>
Hi! I'm new to Zig and wanted to try out some network programming. I figured I would just do some simple open socket, read bytes, write bytes stuff to get a feel for the language. I saw that zig has the net library the std lib, and thought I would copy from that to get a simple address list and start messing around.
<aconbere>
However, I can't actually get the code from the std lib to compile?