ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
steveno has quit [Quit: Leaving]
<mgxm> andrewrk: I'm going to start working on making the cross comp work for FreeBSD
<mgxm> Do you thing that the best approach to target FreeBSD from non-BSD is to port Scrt and related to zig?
testuser678 has quit [Ping timeout: 256 seconds]
hooo has quit [Quit: Connection closed for inactivity]
diltsman has quit [Ping timeout: 256 seconds]
kristate has joined #zig
diltsman has joined #zig
kristate has quit [Remote host closed the connection]
emekoi has joined #zig
<emekoi> link order is important when you're constructing a link job in `construct_linker_job` right?
kristate has joined #zig
kristate has quit [Remote host closed the connection]
marmotini_ has joined #zig
<andrewrk> mgxm, yes I think that is a reasonable approach. I also think it would be reasonable to look at freebsd's Scrt and related, and consider what, if anything is necessary to statically link. Potentially, we would be able to not link any of that stuff.
<emekoi> how would you emit inject from symbols within the compiler?
belgin has joined #zig
kristate has joined #zig
belgin has quit [Client Quit]
<andrewrk> emekoi, I'm actually not sure if link order is important. it is for gnu binutils ld, but it might not be for LLD
<andrewrk> I'm not sure about your second question, can you elaborate on what you're trying to do?
<emekoi> i'm trying to get the hello_libc example to compile on windows under mingw-w64, but i get link errors because `__image_base__` and `__stack_chk_guard` aren't defined.
<emekoi> if i link manually and ignore undefined symbols it compiles but then it gets stuck in a loop for a while, then it segfaults.
<andrewrk> if those symbols are needed it's because something is calling them
<emekoi> and i can't define `__stack_chk_guard` myself because exporting values like `usize` or `[@sizeOf(usize]u8` doesn't seem to work.
<emekoi> yeah, they seems mingw libc is calling them in `__security_init_cookie` to enable stack-smashing detection.
<andrewrk> you have to port the mingw libc functions to std/special/builtin.zig
<andrewrk> what happened when you tried to export a usize?
kristate has quit [Remote host closed the connection]
<emekoi> i got `TODO export const value of type usize`
<andrewrk> ahh! don't be scared of a little TODO panic :)
<andrewrk> that's how you wanted to export __image_base__ right?
<emekoi> __stack_chk_guard, actually
<andrewrk> __stack_chk_guard is an integer variable, not a function?
<andrewrk> anyway for both of these, it might be better to provide them manually in codegen.cpp when the target is mingw
<andrewrk> or perhaps are these defined in libgcc, which is not being linked in?
<emekoi> i link i libgcc so that's whats got me confused.
<andrewrk> sorry, did you say you are or are not linking against libgcc?
<andrewrk> it would be beneficial to understand where these symbols come from when you create a binary with mingw gcc
belgin has joined #zig
<emekoi> i sorry i meant i link agains't libc
<emekoi> i link againt all the libraries gcc does when i compile a file with verbose mode
belgin has quit [Client Quit]
<emekoi> i just remembered lld has a mingw driver that solves some of these problems
<emekoi> i just realized that export error was weird because exporting where it's declared works.
emekoi has quit [Ping timeout: 272 seconds]
hooo has joined #zig
forgot-password has joined #zig
adrusi_ has quit [Quit: ZNC 1.7.1 -]
adrusi has joined #zig
zezic has joined #zig
knebulae has quit [Read error: Connection reset by peer]
forgot-password has quit [Ping timeout: 250 seconds]
Zaab1t has joined #zig
forgot-password has joined #zig
marmotini_ has quit [Remote host closed the connection]
steveno has joined #zig
<forgot-password> Is there a way to force a function to be evaluated at compile time? If I were to remove the comptime from the function call I wouldn't get a compilation error and cause a crash at runtime.
hooo has quit [Quit: Connection closed for inactivity]
halosghost has joined #zig
meheleventyone has joined #zig
hooo has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<forgot-password> I got it to work by just using a comptime_int instead of a u32. Is that a valid workaround or too hacky?
forgot-password has quit [Quit: leaving]
darithorn has joined #zig
<mgxm> andrewrk: great, I'll check that
steveno has quit [Ping timeout: 250 seconds]
steveno has joined #zig
forgot-password has joined #zig
wootehfoot has joined #zig
<andrewrk> forgot-password, that's a good workaround. there's a known issue right now where zig generates a runtime function unnecessarily (if you only call the function at comptime, it shouldn't do this)
<andrewrk> mgxm, it's OK to put in a bunch of FreeBSD-specific linker logic into link.cpp
<andrewrk> you can look at codegen->zig_target.os
<forgot-password> andrewrk: Oh okay, but that shouldn't be that much of a problem since it hopefully doesn't get called, right? Of course, it's still a waste of space.
<andrewrk> it's usually not a problem, and could even be convenient for debugging purposes - and would get deleted in release modes
<andrewrk> when it becomes a problem is if you have logic in the function that can only work at comptime, e.g. if you use the ++ operator, but zig mistakenly tries to create a runtime version of the function and gives you a compile error
<forgot-password> Can I somehow format an int into a string at compile time? std.fmt.bufPrint won't work, because you currently cannot call var arg functions at comptime...
<andrewrk> your comptime_int thing is a good workaround, until this is fixed, because zig then knows not to create a runtime version of the function
<forgot-password> But when I don't use a comptime_int it won't be forced to run at comptime, right? Because then the caller is obligated to make it a comptime expression.
<andrewrk> std.fmt.bufPrint will be the way to do that, just need to make more progress on the compiler internals. I don't have a workaround for that off the top of my head
<andrewrk> you're running into the immaturity and "beta"-ness of zig here
<forgot-password> I'm thinking ofjust adding 0x30, but that will only work up to 9 :/
<andrewrk> try std.fmt.formatIntBuf
<forgot-password> I found that in the source as well, but I didn't now what to pass at a glance, so I just ticked it off :p
<forgot-password> Will take a look though, thanks :)
<andrewrk> const result = out_buf[0..formatIntBuf(out_buf, integer_value, 10, false, 0)];
<andrewrk> a bit clunky, but, that's because bufPrint is the real answer once the issues are resolved
<forgot-password> I'm getting this error: 'comptime_int' does not support field access
<forgot-password> Casting did the trick
meheleventyone has joined #zig
steveno has quit [Ping timeout: 252 seconds]
<forgot-password> However, now I have a problem with allocating the buffer... A slice doesn't work, because it demands a []u8 and using a DirectAllocator just hangs the program(/compiler?)
<andrewrk> you're trying to allocate at compile time?
<forgot-password> How else would I go about it? I cannot get the stack allocation to work.
steveno has joined #zig
<andrewrk> what are you trying to do?
<forgot-password> Here's the snippet:
<andrewrk> forgot-password, I think you can move it to inside the while loop: comptime var buf: [100]u8 = undefined;
<andrewrk> you need it to be an array. a slice references other memory
<forgot-password> THat still gives me
<forgot-password> Sorry, I thought I was in my editor. I didn't mean to send it already
<forgot-password> It still gives me 'expected type []u8, found [100]u8'
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
steveno has quit [Ping timeout: 268 seconds]
steveno has joined #zig
<andrewrk> zig won't automatically turn an array into a slice unless you take the address of it
forgot-password has quit [Ping timeout: 268 seconds]
forgot-password has joined #zig
<forgot-password> andrewk: Alright, how do I do that? I tried to somehow turn it to an array before, but I couldn't figure it out.
<andrewrk> where it is telling you it expects a slice, and it found an array, you can take the address of the array
<andrewrk> &array
<forgot-password> That's what I just did, but then I get a pointer to that array and it complains about that
<forgot-password> Wait nevermind
<forgot-password> Weird, that's exactly what I had. Maybe I forgot to save. Anyways, thank you very much :)
Ichorio has joined #zig
<andrewrk> forgot-password, no problem. I understand it's frustrating when you run into some of the TODO issues
<forgot-password> andrewrk: I wasn't frustrated at all, did it come off like that? I'm very sorry if so. It's totally fine and understandable to run into issues, because, like you said yourself, this is a rather young language. You guys are doing a great job at nurturing Zig and noobs like me :)
<forgot-password> Not that there's anything wrong with being frustrated, though
<andrewrk> I wasn't responding to anything in particular, just communicating friendliness
Zaab1t has quit [Quit: bye bye friends]
<sjums> Andrew is like a super human good guy, forgot-password 👌
<sjums> Besides the huge brain I'm amazed how patient and helpful he is.
<sjums> You'll go far in this world, Andrew!
<andrewrk> I don't have a huge brain, I just try hard
<andrewrk> zig is for people with medium size brains who are willing to put the work in :)
<forgot-password> sjums: At least the helpfulness and patience applies to all of you, the other I don't know about ;)
zez1c has joined #zig
zezic has quit [Ping timeout: 240 seconds]
<mgxm> andrewrk: yeah, like you did with osx and windows?
<andrewrk> mgxm, yes
<mgxm> ok, thanks
<andrewrk> mgxm, to give you a vision of the future: someday we'll have the ability to build C projects from source purely with zig, on any supported platform, targeting any supported platform
<andrewrk> so your zig project, for example, could depend on a C library, which in turn depends on other C libraries, and so on, but they're all packaged up in a way that zig understands how to build
<andrewrk> so you could build the project on any OS, targeting any OS, with only Zig as a system dependency on all the systems
<andrewrk> of course, distributions such as debian are then free to package up software however they see fit; probably breaking it up into its dependencies and using system packages. But for development purposes, the ability to rely on dependencies always being there regardless of the system and its configuration is a huge productivity and collaboration boon
halosghost has quit [Quit: WeeChat 2.3]
Ichorio has quit [Ping timeout: 250 seconds]
<mgxm> that... it's the main reason to start contributing :)
steveno has quit [Remote host closed the connection]
<mgxm> and how about the libc?
steveno has joined #zig
<mgxm> I read that the main goal is to no depend on it
<andrewrk> for macos, freebsd: zig will build c libraries which dynamically link libc, with the linker option that makes it not required to be present on the native system
forgot-password has quit [Quit: leaving]
<andrewrk> for windows, linux: zig will build its own libc from source and statically link it in when building C libraries that depend on libc
<andrewrk> this will mostly be a port of musl (linux) and newlib (windows)
<andrewrk> of course, pure zig projects can rely on the standard library, no libc needed
<andrewrk> but when depending on C libraries that do use libc, libc and the zig standard library will share code
wootehfoot has quit [Read error: Connection reset by peer]
steveno has quit [Ping timeout: 250 seconds]
zez1c has quit [Ping timeout: 268 seconds]