ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
kbd has joined #zig
LewisGaul has quit [Ping timeout: 240 seconds]
<g-w1> is an error union ever not a valid var type?
Techcable has quit [Remote host closed the connection]
<andrewrk> just arm left todo now in the llvm12 branch
<andrewrk> after this, the "Upgrading to new LLVM" process will get a much simpler, at least as far as cpu features goes :)
leon-p has quit [Quit: leaving]
raggi has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
<g-w1> andrewrk: if implimenting runtime error comparisons for the cbe, should I make a new tzir inst for error comparison? or is there already something that I can use?
brzg has joined #zig
<g-w1> should I just use cmp_eq?
<g-w1> for the cbe, cmp_eq will work I think, but idk about the other backends since they use intInfo so I would have to add some error specific code in there
Techcable has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
earnestly has quit [Ping timeout: 256 seconds]
osa1 has quit [Ping timeout: 246 seconds]
<andrewrk> g-w1, which type are we talking about here? error set or error union?
<g-w1> error.Val
<g-w1> see zir_sema.zig:2221
<mikdusan> andrewrk: does zig change debug info generation based on build-type? ie: an arg is a slice VS an arg is a ptr + len ?
<mikdusan> if my question doesn't make sense just say so :)
<andrewrk> g-w1, that's a value with type of error set. in codegen, every TZIR instruction will have a corresponding machine code value. this machine code value will be a simple integer and can be compared directly
<andrewrk> TZIR tag of cmp_eq is ok to pass to codegen for error set values
<g-w1> ok, so in genCmp in codegen.zig I will have to check if it is an error set and then do different stuff right? since it has no intinfo
<andrewrk> mikdusan, the answer to the first question is "no", but I don't understand how the second clause relates
<mikdusan> i added a comment to #6408 and am perplexed why in RELEASE the two slice args end up as (ptr,len) and in DEBUG the two slice args end up as (<unavailable>),(ptr,len)
<mikdusan> ie: RELEASE loses the first arg "path" ? wtf.
<mikdusan> if nothing comes to mind I'll continue digging
<andrewrk> mikdusan, flattening a struct into args is a nice optimization
<andrewrk> optimizations have to try to produce debug info that describes the original source
kbd has joined #zig
<andrewrk> it's very common for a release build to have <unavailable> or <optimized out> things
<mikdusan> we have debug info for same function (path: []const u8, expect: []const u8) vs (expect: (ptr, len)) <-- in the 2nd arglist, there is no "path"
<andrewrk> bad debug info would not cause a test failure; you can strip debug info and it still runs the same
<andrewrk> mikdusan, I'm guessing that test failure is unrelated to #6408
<mikdusan> yeah I have a few other angles I think may reduce #6408 proper
brzg has quit [Quit: leaving]
squeek502 has quit [Remote host closed the connection]
<andrewrk> mikdusan, done! invoking that update_cpu_features.zig tool now produces an empty git diff in the llvm12 branch
<mikdusan> very nice!
<mikdusan> have you ever tried building llvm with LLVM_ENABLE_EXPENSIVE_CHECKS=ON ?
<andrewrk> not that I recall
<mikdusan> ok I'll try it out while building a few variants of llvm
<andrewrk> I kicked off the first test suite run of llvm12, now that the cpu features are repaired. let's see how it fares
<g-w1> hmm, I am trying to work off of one of vexu's prs. it is not rebased with master, but I need it to be to add my features (error testing stuff in his cbe error pr) what is the best way to do this with the least breakage/headache?
<g-w1> make a branch off his pr then rebase with master? merge with master? ask him to do it?
<mikdusan> rebase his pr. rebase your branch. merge his pr to your branch.
<g-w1> i tried merging with master but it showed all the commits in my pr so I thought that was not the right way to do it
<g-w1> ok, wdym by rebase his pr?
kbd has quit [Quit: Textual IRC Client: www.textualapp.com]
Techcable has quit [Ping timeout: 245 seconds]
<g-w1> i need my branch to go off his pr
<g-w1> but also his pr to be rebased with master first
<mikdusan> ok so if you create a tmp branch to equal his pr,
<mikdusan> then you can rebase it to master
<g-w1> ok, ill try
<mikdusan> which PR of his?
lunamn0 has joined #zig
lunamn has quit [Ping timeout: 256 seconds]
lunamn0 is now known as lunamn
<mikdusan> something like this:
<mikdusan> git remote add https://github.com/Vexu/zig.git
<mikdusan> err wrong
<mikdusan> git remote add vexu https://github.com/Vexu/zig.git
<andrewrk> next llvm12 problem, building glibc has regressed
<g-w1> i got that with `gh pr checkout 7934` :)
<mikdusan> git fetch vexu
<mikdusan> git co -b pr7934 vexu/stage2-cbe
<mikdusan> and now your local branch pr7934 will equal
<mikdusan> and then `git rebase master` and you'll get codegen conflict
<mikdusan> fix and rebase --continue
<g-w1> ok, i think it worked!
lunamn6 has joined #zig
lunamn has quit [Ping timeout: 240 seconds]
lunamn6 is now known as lunamn
<andrewrk> hmm, libc.so.6 has no symbols
<mikdusan> can you see what .ll target is just to verify the abi name at end?
<andrewrk> libc.so & friends are produced by assembling generated .s files
Techcable has joined #zig
<g-w1> mikdusan: now I get this? should I still make a pr? https://github.com/Vexu/zig/compare/stage2-cbe...g-w1:stage2-cbetest?expand=1
<g-w1> the easiest solution is probably just to ask him to rebase
Techcable has quit [Remote host closed the connection]
<mikdusan> andrewrk: looks like all the syms in `c.o` which libc.so.6 links against are HIDDEN . vs 50% hidden 50% not when built from master
<andrewrk> mikdusan, it fixed it to take away hidden, but looking at the symbols I wonder if some of them should be hidden
<andrewrk> yeah in master branch the ones with version numbers are LOCAL HIDDEN and the bare names are GLOBAL DEFAULT
<andrewrk> damn I bet TheLemonMan would know how to fix this
<andrewrk> we need a batman search light but instead of the bat logo it is the shape of a lemon
ky0ko has quit [Remote host closed the connection]
<mikdusan> hmm i might have a hint
<mikdusan> adding a -v to `zig clang` for c.s -> c.o here is what shows for llvm-11:
<mikdusan> (putting in a gist)
<mikdusan> well it's one diff in `-cc1as` command line; llvm-12 **ADDS* this:
<mikdusan> --mrelax-relocations
<andrewrk> that sounds unrelated
<mikdusan> ok
<andrewrk> dalias from #musl said it sounds like a regression in clang
<mikdusan> used clang from my toolchain and... clang11 c.s -> c.o is good. clang12 all same args, and generates 100% hidden symbols .
<mikdusan> so sounds like a regre
squeek502 has joined #zig
squeek502 has quit [Remote host closed the connection]
squeek502 has joined #zig
osa1 has joined #zig
craigo has quit [Ping timeout: 265 seconds]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk> mikdusan, I just had a chat with the person who made the relevant change to clang. apparently it was a bugfix. and now there is no way to get the previous behavior
<mikdusan> what's the birds-eye here... I didn't see in logs how `c.s` actually got created. do you run a bunch of internal `clang -S` on glibc sources?
<mikdusan> s/internal/embedded
<andrewrk> glibc.zig line 806
<andrewrk> tools/update_glibc.zig creates lib/libc/glibc/{abi,fns,vers}.txt
<mikdusan> ha i didn't know you did this. just populating syms?
<andrewrk> glibc.zig uses those txt files to produce c.s
<andrewrk> the txt files contain data for multiple ABI versions of glibc and the .s file is generated based on the target glibc version
<daurnimator> did we ever fix that issue where libc wasn't recompiled when cpu features were changed?
<andrewrk> daurnimator, I'm looking at the line of code that adds cpu features to the cache hash
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
cole-h has quit [Ping timeout: 265 seconds]
<daurnimator> andrewrk: okay cool :)
leon-p has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
<mikdusan> andrewrk: can we just generate stub.c file, clang -c stub.c, ld.lld -shared -o libc.so.6 stub.o ?
<mikdusan> each fn would have something like:
<mikdusan> __asm__(".symver one, one@@GLIBC_2.2.5");
<mikdusan> void one() {}
xackus_ has joined #zig
ky0ko has joined #zig
podge has joined #zig
earnestly has joined #zig
<andrewrk> mikdusan, how is that an improvement on the .s file we generate?
<mikdusan> the .so with above `one()` has:
<mikdusan> DYNAMIC SYMBOL TABLE:
<mikdusan> 00000000000012d0 g DF .text 0000000000000006 GLIBC_2.2.5 oney
<mikdusan> and same so via readelf:
<mikdusan> Symbol table '.dynsym' contains 2 entries:
<mikdusan> Num: Value Size Type Bind Vis Ndx Name
<mikdusan> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
<mikdusan> 1: 00000000000012d0 6 FUNC GLOBAL DEFAULT 8 one@@GLIBC_2.2.5
<andrewrk> the problem is when there are multiple versions for the same symbol name
Thale has joined #zig
<Thale> Hello
<Thale> I'm just trying to comile my program on linux, coming from windows. So I downloaded the latest linux binaries. But when I compile it, I get the following error:
<andrewrk> hello
<Thale> Semantic Analysis... ./src/data_structures.zig:89:13: error: expected function or variable declaration after pub
<Thale>         pub inline fn get(self: *DynamicArray(T), index: usize) *T {
<Thale> Is this because something has changed in the language or am I doing sth wrong?
<andrewrk> Thale, run `zig fmt` on your code. it will auto-update the `inline` to the new syntax
<Thale> Ahh cool, thanks!
<mikdusan> andrewrk: you're right same deal. I tried using __attribute__((visibility ("hidden")) from .c source and still marked its counterpart as hidden
podge has quit [Ping timeout: 246 seconds]
podge has joined #zig
<mikdusan> hmm grep'ing glibc sources this pattern comes up. I have no idea what 'set' does or if it is ia640-only
<mikdusan> ./sysdeps/ia64/fpu/e_exp2.S:.symver exp2,exp2@@GLIBC_2.29
<mikdusan> ./sysdeps/ia64/fpu/e_exp2.S-.weak __exp2_compat
<mikdusan> ./sysdeps/ia64/fpu/e_exp2.S-.set __exp2_compat,__exp2
<mikdusan> ./sysdeps/ia64/fpu/e_exp2.S:.symver __exp2_compat,exp2@GLIBC_2.2
<mikdusan> anyhow I got to get some sleep. back tomorrow. night
<andrewrk> good night
<andrewrk> one thing we can try is adjusting the version script
<mikdusan> i tried before but with just one vers. now with 2 and `local` seems to override:
<mikdusan> Symbol table '.dynsym' contains 3 entries:
<mikdusan> Num: Value Size Type Bind Vis Ndx Name
<mikdusan> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
<mikdusan> 1: 0000000000001340 6 FUNC GLOBAL DEFAULT 8 one@@GLIBC_2.2.5
<mikdusan> 2: 0000000000001350 6 FUNC GLOBAL DEFAULT 8 one@GLIBC_2.31
<mikdusan> this is from version.script:
<mikdusan> GLIBC_2.2.5 {
<mikdusan> };
<mikdusan> GLIBC_2.31 {
<mikdusan> local: one_b;
<mikdusan> };
<mikdusan> and main.c is:
<mikdusan> __asm__(".symver one, one@@GLIBC_2.2.5");
<mikdusan> void one() {}
<mikdusan> __asm__(".symver one_b, one@GLIBC_2.31");
<mikdusan> void one_b() {}
Thale has quit [Quit: Connection closed]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
<ifreund> > @: start a builtin expression and/or access a builtin object, escape with $@
<ifreund> marler8997: is this a typo? it seems to me that escaping with @@ would be more intuitive...
<ifreund> oh but you seem to be using @@ for delimited strings now. hmm
<ifreund> I'd probably use something else, say @%"foo" for delimited strings and use @@ to escape @. Using @$ to escape $ instead of $$ is the right call I think
<marler8997> Yeah I wasn't sure what would be a good character for delimited string literals
<ifreund> kakoune uses % in a somewhat similar way which is what made me think of it
<marler8997> @@"..." looks farily clean, @$"..." looks a bit uglier to me, and @@"..." is easy to type
<marler8997> that's pretty cool
<marler8997> If I were to use the same, I'd be adding 3 special characters, ', " and %
<ifreund> Yeah I'm not sure if it's a perfect fit for stitch, but certainly food for thought :)
<ifreund> I've found it quite plesant to use in practice
<marler8997> found kakoune pleasent to use?
<ifreund> kakoune and this syntax in particuar
<marler8997> yeah I like it actually
<marler8997> oh, and if the closing delimiter is double it's considered apart of the string
<marler8997> interesting idea, but it kinda defeats the purpose of the delimited string, that its a WYSIWYG string
<ifreund> well, it's either that or completely disallow the delimiter in the string
<marler8997> right
<marler8997> I'm thinking if have to esacpe your delimiter, just use a different delimiter
<ifreund> indeed, though with that approach there are strings you can't encode
<ifreund> e.g. a string containing every character
<marler8997> you could still do %"hello "@"Joe@"
<marler8997> by that I mean, end the delimited string and tak on more
<ifreund> another approach I've seen is something like @``string here`still in the string``
<ifreund> where you can use an arbitrarily high number of ` at the start, and the string continues untill that same number is found consecutively
<ifreund> I think that can't handle empty strings though
<marler8997> If we didn't add any special characters, what about @' to start a delimited raw string?
<marler8997> @''hello'
<marler8997> single-quote could be the default conventional delimiter
<marler8997> I think I'll switch to that for now, and make a note about kakoune's syntax to consider
<ifreund> hmm, aesthetically @''hello' feels unbalanced to me
<ifreund> I think I'd go with @"hello" as the standard string with no way to escape "s between the quotes, and also have the @```foo``` syntax to allow arbitrary string contents
<ifreund> then you don't need arbitrary delimiters as you can always add more `s
<ifreund> and you have @"" for the empty string edge case
<marler8997> not bad
<marler8997> I'm very tempted to just allow "..."
<marler8997> one big reason is that " almost always a special character, and people will expect it to be
<ifreund> true, you could also go with what I just proposed but drop the @s
<marler8997> so it would be "this is a string" or @`this is a "string" that can use double quotes`
<marler8997> I could do the same with just double quotes right?
<marler8997> """this is a string"""
<ifreund> yeah, but then you can't handle the empty string
<marler8997> @emptystring :)
<ifreund> fair enough :P
<marler8997> or (@echo)
<ifreund> that works, but it would be kinda suprising to find out that was the only way to write an empty string as a newcommer I think
<marler8997> yeah, we might be able to do better
<marler8997> So maybe "..." and @""""....""""
<marler8997> or the other way? @"..." """"....""""
<ifreund> in that case people would likely only use @"" for the empty string
<ifreund> it would be in practice """...""" and @""
<ifreund> which might be fine tbh
<marler8997> yeah that seems odd
<marler8997> If we suppsed "...", then using something like @%X...X seems more tractable than without "..."
<marler8997> because @%X...X would be alot more rare
<ifreund> if we used a delimiter that is a matching pair, the """...""" syntax can represent the empty string
<ifreund> <<....>>
<ifreund> <>
<ifreund> could also go the other way and do >...< >>>...<<< ><
<marler8997> interesting
<marler8997> so may ways!!
<ifreund> i kinda like >hello< tbh
<marler8997> yeah it has a certain look to it that's appealing
<marler8997> I think supporting double quote "..." is probably the right way to go, so I think we can simplify and assume that one
<marler8997> with no way to escape the double-quote
<marler8997> >hello ! this is a "string" with all sorts of character<
<ifreund> if we were to break with most programming languages and go with >foo< for strings, we wouldn't need "..."
<marler8997> >hello<
<marler8997> >>my <xml> tag<<
<marler8997> >>my stitch string >hello<<<
<marler8997> oh that wouldn't work
<ifreund> ah yeah, you can't end the string with the delimiter :/
<marler8997> yeah, can't end strings with <
<ifreund> actually I don't think that's ambiguous
LewisGaul has joined #zig
<ifreund> just keep looking for the next < until you find another character, then subtract the number of >s at the start
<marler8997> huh?
<ifreund> I think since < is a special character too, >>foo<< could be "foo" and >>foo<<< could be "foo<"
<marler8997> oh I see, you keep going while you see <
<ifreund> during parsing don't stop after finding N closing delimiters, instead count how many consecutive <s are found and subtract N where N is the number of >s
<marler8997> I see now
<marler8997> ok, so the current idea is "..." and >>>...<<<
<marler8997> we have 2 methods, increasing delimiter count, or custom delimiters
<ifreund> I'm not sure we need "..." tbh, only reason to have it is if >foo< is too jarring for people used to "foo" strings
<marler8997> oh right
<ifreund> >>>...<<< solves all use cases IMO
<marler8997> so we only need ><
<marler8997> say we did that, what would you think about multiline?
<ifreund> I don't think line breaks in the source cause any issues there, we could allow them
<marler8997> so we could solve all the issues with ><
<marler8997> but compare that to "..." and @"""..."""
<ifreund> one issue with that is you need a way to escape "
<ifreund> and @" doesn't work
<ifreund> >< would require @> and @< but they wouldn't cause issues
<marler8997> we could go back to "..." and @"X...X
<ifreund> or "..." and @```...```
<marler8997> how is @```...``` different from @"""..."""?
<ifreund> you can use @" to escape "
<marler8997> oh right
<marler8997> @>>><<<
<marler8997> there's that one too
<marler8997> "..." and @>>>...<<<
<ifreund> Is there a downside to just >foo< >>>...<<< other than the strangeness factor?
<marler8997> @>>hello this is a coo! string with <xml> tags and stitch @>strings< as well<<
<marler8997> more reserved characters
<ifreund> I guess if you want to use @< and @> for comparison operators there's a conflict there too
<marler8997> true
<marler8997> those are not planned right now though
<marler8997> $eq $lt $gt are the plan at the moment
<marler8997> I mean @eq...
<ifreund> sounds fine to me, @lt and @gt feel better than @< @> to me because of the prefix
<marler8997> How often do we think someone will use >...<?
<ifreund> I think strings will mostly be used to pass arguments to programs
<ifreund> or to output formatted text
<ifreund> really I think we'd need to translated some of the example code and see how it looks
<marler8997> ok, I think at this point we need to write down the options and come back to this
<marler8997> I'm going to create an issue in the repo and enumerate them
<ifreund> cool, I'll take a look and comment with anything I think is missing
<ifreund> (I wonder if we should have a #stitch channel, this is a lot for #zig...)
<marler8997> this is the second time we've taken over the Zig channel, it might be time for that as at some point too much discussion is probably rude
<ifreund> #stitch is free
<marler8997> let's do it
_whitelogger has joined #zig
podge has quit [Quit: quit]
emptee has joined #zig
eax has joined #zig
eax has quit [Remote host closed the connection]
bitmapper has joined #zig
emptee has quit [Remote host closed the connection]
emptee has joined #zig
LewisGaul has quit [Ping timeout: 240 seconds]
save-lisp-or-die has left #zig ["The Lounge - https://thelounge.chat"]
<emptee> Where does testing for zig fmt happens?
<ifreund> emptee: lib/std/zig/parser_test.zig
cole-h has joined #zig
<emptee> thanks!
dyeplexer has joined #zig
cole-h has quit [Ping timeout: 260 seconds]
craigo has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
Akuli has joined #zig
waleee-cl has joined #zig
Techcable has joined #zig
LostKobrakai has joined #zig
LostKobrakai has left #zig [#zig]
LostKobrakai has joined #zig
Techcable has quit [Quit: Leaving]
LostKobrakai has left #zig [#zig]
Techcable has joined #zig
LostKobrakai has joined #zig
<LostKobrakai> Hi, I'm new to zig and working with a C library expecting a const char *iban. How would I be creating that in zig?
<ifreund> "foo" would be one way
<ifreund> what data are you trying to pass?
<ifreund> assuming the C code expects a 0 terminated pointer, the equivalent zig type would be [*:0]const u8
<LostKobrakai> When I try a literal string I get this error: error: expected type '[*c]const u8', found '[]const u8'
<ifreund> the type of "foo" is *const [3:0]u8, so I'm assuming you are doing something to coerce it to []const u8 before passing it to C
Swahili has joined #zig
<LostKobrakai> yeah, I'm passing it into a function and that's the type I assumed it would be
<LostKobrakai> can I use a different type in the functions parameter?
<ifreund> indeed, you could use [*:0]const u8
<ifreund> which is a 0 terminated constant pointer to u8
<LostKobrakai> with this I get errors of ld.lld about my C libraries functions being undefined symbols
<g-w1> how do you link it?
<ifreund> how are you building?
<LostKobrakai> I don't have the source, but a lib.a and lib.h file, which I copied into a folder and include that in zig
<g-w1> you need to link lib.a
dyeplexer has quit [Remote host closed the connection]
<LostKobrakai> Thanks. Seems to work now, but also interesting that I didn't seem to have hit this before at all
<Gliptic> presumbly you weren't actually calling anything in the library until now
<Gliptic> *presumably
haliucinas has quit [Quit: Lost terminal]
haliucinas has joined #zig
<v0idify> line 768 at std/event/loop.zig says: @compileError("TODO: integrate timers with epoll/kevent/iocp for single-threaded"); how would this (timers through epoll) be implemented?
LostKobrakai has quit [Quit: LostKobrakai]
LewisGaul has joined #zig
neptunepunk has quit [Ping timeout: 272 seconds]
<mikdusan> regarding the llvm12 `sret` issue, now that we have the lemon-fix in place, are **ALL** `sret` to be using parens? I see a ton of `sret %0` or `sret %8` style in the code
<mikdusan> andrewrk: ^^
<mikdusan> because I just ran into the same gen llvm-ir, run it through llc and it complains about expecting '('
<mikdusan> my ir is actually a mix. some `sret(...)` and some not
neptunepink has joined #zig
TheLemonMan has joined #zig
Swahili has quit [Remote host closed the connection]
kenran has joined #zig
kenran has quit [Remote host closed the connection]
kenran has joined #zig
emptee has quit [Quit: Konversation terminated!]
hnOsmium0001 has joined #zig
riba has joined #zig
qbit has joined #zig
<qbit> hio!
<mikdusan> so hunting 1 bug I find another. and boom, lemon engages and they've found an upstream bug: #6408
_whitelogger has joined #zig
kenran has quit [Quit: leaving]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
gpanders has quit [Ping timeout: 268 seconds]
gpanders has joined #zig
cole-h has joined #zig
leon-p has quit [Quit: leaving]
<LewisGaul> Hey all, I'm trying to build zig master branch for the first time (WSL1 Ubuntu) and cmake is failing with:
<LewisGaul> -- Could NOT find clang (missing: CLANG_LIBRARIES CLANG_INCLUDE_DIRS)
<LewisGaul> -- Could NOT find lld (missing: LLD_LIBRARIES LLD_INCLUDE_DIRS)
<LewisGaul> and then failing to find libpthread. Are the above errors the first thing to fix? I have installed clang/llvm/lld 11. Any ideas?
xackus_ has quit [Ping timeout: 245 seconds]
midgard has quit [Read error: Connection reset by peer]
midgard has joined #zig
<mikdusan> LewisGaul: I have no exp with WSL1 but have you have installed "llvm-11", what about "llvm-11-dev" ?
<LewisGaul> I have indeed - I'm hoping WSL1 won't be a factor but annoyingly it is sometimes... May end up switching to try native windows I guess
<mikdusan> and maybe libclang-11-dev, liblld-11-dev
riba has quit [Ping timeout: 245 seconds]
<LewisGaul> Didn't have them, trying installing them
<LewisGaul> I'm suspicious that I have /usr/lib/llvm-11/lib/libclang-cpp.so.11 but Findclang.cmake doesn't seem to look at that path?
<mikdusan> needs header files (include/) too
<LewisGaul> nvm installing the suggested packages seems to get cmake to succeed, thanks :)
Akuli has quit [Quit: Leaving]