01:29 <mgxm> andrewrk: I'm going to start working on making the cross comp work for FreeBSD

01:29 <mgxm> Do you thing that the best approach to target FreeBSD from non-BSD is to port Scrt and related to zig?

03:45 <emekoi> link order is important when you're constructing a link job in `construct_linker_job` right?

05:57 <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.

06:27 <emekoi> how would you emit inject from symbols within the compiler?

06:32 <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

06:32 <andrewrk> I'm not sure about your second question, can you elaborate on what you're trying to do?

06:37 <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.

06:37 <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.

06:39 <andrewrk> if those symbols are needed it's because something is calling them

06:39 <emekoi> and i can't define `__stack_chk_guard` myself because exporting values like `usize` or `[@sizeOf(usize]u8` doesn't seem to work.

06:40 <emekoi> yeah, they seems mingw libc is calling them in `__security_init_cookie` to enable stack-smashing detection.

06:41 <andrewrk> you have to port the mingw libc functions to std/special/builtin.zig

06:41 <andrewrk> what happened when you tried to export a usize?

06:46 <emekoi> i got `TODO export const value of type usize`

06:48 <andrewrk> ahh! don't be scared of a little TODO panic :)

06:49 <andrewrk> that's how you wanted to export __image_base__ right?

06:50 <emekoi> __stack_chk_guard, actually

06:50 <andrewrk> __stack_chk_guard is an integer variable, not a function?

06:51 <andrewrk> anyway for both of these, it might be better to provide them manually in codegen.cpp when the target is mingw

06:52 <andrewrk> or perhaps are these defined in libgcc, which is not being linked in?

06:52 <emekoi> i link i libgcc so that's whats got me confused.

07:01 <andrewrk> sorry, did you say you are or are not linking against libgcc?

07:02 <andrewrk> it would be beneficial to understand where these symbols come from when you create a binary with mingw gcc

07:11 <emekoi> i sorry i meant i link agains't libc

07:12 <emekoi> i link againt all the libraries gcc does when i compile a file with verbose mode

07:24 <emekoi> i just remembered lld has a mingw driver that solves some of these problems

07:47 <emekoi> i just realized that export error was weird because exporting where it's declared works.

14:26 <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.

17:05 <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?

17:20 <mgxm> andrewrk: great, I'll check that

18:09 <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)

18:10 <andrewrk> mgxm, it's OK to put in a bunch of FreeBSD-specific linker logic into link.cpp

18:10 <andrewrk> you can look at codegen->zig_target.os

18:11 <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.

18:12 <andrewrk> it's usually not a problem, and could even be convenient for debugging purposes - and would get deleted in release modes

18:12 <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

18:13 <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...

18:13 <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

18:14 <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.

18:15 <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

18:15 <andrewrk> you're running into the immaturity and "beta"-ness of zig here

18:16 <forgot-password> I'm thinking ofjust adding 0x30, but that will only work up to 9 :/

18:17 <andrewrk> try std.fmt.formatIntBuf

18:18 <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

18:18 <forgot-password> Will take a look though, thanks :)

18:18 <andrewrk> const result = out_buf[0..formatIntBuf(out_buf, integer_value, 10, false, 0)];

18:18 <andrewrk> a bit clunky, but, that's because bufPrint is the real answer once the issues are resolved

18:22 <forgot-password> I'm getting this error: 'comptime_int' does not support field access

18:26 <forgot-password> Casting did the trick

18:31 <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?)

18:32 <andrewrk> you're trying to allocate at compile time? https://github.com/ziglang/zig/issues/1291

18:33 <forgot-password> How else would I go about it? I cannot get the stack allocation to work.

18:42 <andrewrk> what are you trying to do?

18:48 <forgot-password> Here's the snippet: https://pastebin.com/raw/nXBazuue

18:59 <andrewrk> forgot-password, I think you can move it to inside the while loop: comptime var buf: [100]u8 = undefined;

18:59 <andrewrk> you need it to be an array. a slice references other memory

19:01 <forgot-password> THat still gives me

19:02 <forgot-password> Sorry, I thought I was in my editor. I didn't mean to send it already

19:02 <forgot-password> It still gives me 'expected type []u8, found [100]u8'

19:36 <andrewrk> zig won't automatically turn an array into a slice unless you take the address of it

19:49 <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.

19:49 <andrewrk> where it is telling you it expects a slice, and it found an array, you can take the address of the array

19:50 <andrewrk> &array

19:50 <forgot-password> That's what I just did, but then I get a pointer to that array and it complains about that

19:50 <forgot-password> Wait nevermind

19:51 <forgot-password> Weird, that's exactly what I had. Maybe I forgot to save. Anyways, thank you very much :)

20:14 <andrewrk> forgot-password, no problem. I understand it's frustrating when you run into some of the TODO issues

20:18 <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 :)

20:19 <forgot-password> Not that there's anything wrong with being frustrated, though

20:20 <andrewrk> I wasn't responding to anything in particular, just communicating friendliness

20:35 <sjums> Andrew is like a super human good guy, forgot-password 👌

21:08 <sjums> Besides the huge brain I'm amazed how patient and helpful he is.

21:08 <sjums> You'll go far in this world, Andrew!

21:15 <andrewrk> I don't have a huge brain, I just try hard

21:15 <andrewrk> zig is for people with medium size brains who are willing to put the work in :)

21:20 <forgot-password> sjums: At least the helpfulness and patience applies to all of you, the other I don't know about ;)

21:44 <mgxm> andrewrk: yeah, like you did with osx and windows?

21:44 <andrewrk> mgxm, yes

21:45 <mgxm> ok, thanks

21:50 <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

21:51 <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

21:52 <andrewrk> so you could build the project on any OS, targeting any OS, with only Zig as a system dependency on all the systems

21:56 <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

22:45 <mgxm> that... it's the main reason to start contributing :)

22:52 <mgxm> and how about the libc?

22:53 <mgxm> I read that the main goal is to no depend on it

22:54 <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

22:54 <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

22:55 <andrewrk> this will mostly be a port of musl (linux) and newlib (windows)

22:55 <andrewrk> of course, pure zig projects can rely on the standard library, no libc needed

22:56 <andrewrk> but when depending on C libraries that do use libc, libc and the zig standard library will share code