<IntoxicatedHippo>
I have multiple files with exports, is there a way to tell zig to export the symbols from all the files without putting all the exports in one file?
kristoff_it has joined #zig
darithorn has quit [Quit: Leaving]
dawzon has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
laaron- has quit [Remote host closed the connection]
laaron has joined #zig
<mikdusan>
would putting imports in a single root file be ok?
<mikdusan>
if so at top of collector file just put `comptime { _ = @import("file1.zig"); _ = @import("file2.zig"); ... }`
<dawzon>
Hi, Zig noob here. Is there any documentation on how to include C libraries? I see the stuff about @cImport but I couldn't find anything specific about where it looks for headers. Do I just make my own folder under /lib in my Zig install dir? Using release 0.4.0 on Windows, by the way
darithorn has joined #zig
hio has joined #zig
IntoxicatedHippo has quit [Ping timeout: 258 seconds]
dawzon has quit [Remote host closed the connection]
fengb has quit [Ping timeout: 260 seconds]
brakmic has joined #zig
brakmic_ has joined #zig
brakmic has quit [Ping timeout: 268 seconds]
darithorn has quit [Quit: Leaving]
brakmic has joined #zig
brakmic_ has quit [Ping timeout: 272 seconds]
_whitelogger has joined #zig
_whitelogger has joined #zig
kristoff_it has joined #zig
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kristoff_it has quit [Ping timeout: 268 seconds]
_whitelogger has joined #zig
nifker has joined #zig
SimonNa has joined #zig
SimonNa has quit [Remote host closed the connection]
<nifker>
can I read volatile from an usual pointer?
wootehfoot has joined #zig
very-mediocre has joined #zig
brakmic has quit [Ping timeout: 258 seconds]
brakmic has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre1 has joined #zig
SimonNa has joined #zig
jjido has joined #zig
SimonNa has quit [Remote host closed the connection]
<very-mediocre1>
Is there a design reason why allocator.alloc/create doesn't initialize memory even though a type T is passed which may have default values for fields?
very-mediocre1 is now known as very-mediocre
<very-mediocre>
nvm I realized it would be an inconsistent mess if only some fields were initialized
<very-mediocre>
It might be nice/safe to wrap the allocator.alloc/create functions with something that accepts an init param
<very-mediocre>
that would force the programmer to think about it, and have to explicitly pass `undefined` for uninitialized memory
<mikdusan>
something like `allocator.create(self: *Allocator, init: var)` ?
<very-mediocre>
Yep!
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mikdusan>
oh i forgot there's no fn overloading. so yeah it would have to be .createWithInit(...) or somesuch.
<very-mediocre>
imho it should replace the existing function
<very-mediocre>
just pass undefined if you want uninitialized memory
<very-mediocre>
it feels like the zig way that you have to think about it
<very-mediocre>
the only thing that might be misleading is if you're initializing to a complex data structure, a newcomer might expect some of its inner properties to be initialized
<very-mediocre>
I guess it would be confusing if some of those properties pointed to stuff on the heap
<very-mediocre>
const some_struct = SomeStruct{ .innerVars = (heap allocated array) } -> all instances would point to the same array
Ichorio has joined #zig
<mikdusan>
so i tried `undefined` in a mockup: error: parameter of type '(undefined)' requires comptime
<very-mediocre>
hm, the alignedAlloc function in std.mem calls `@memset(byte_slice.ptr, undefined, byte_slice.len);`
<very-mediocre>
Was that error from std.debug.warn?
jjido has joined #zig
<mikdusan>
just an empty function: `fn doit(value: var) void {}`
<very-mediocre>
this is beyond my zig knowledge, I'm unsure if you're supposed to not be able to pass `undefined` to a var param
<Tetralux>
I think undefined has to be a pointer type.
<very-mediocre>
@memset takes a u8 for its 2nd param, and in std.mem.alignedAlloc undefined is passed for it
<Tetralux>
Or no - wait. I'm not actually sure about that.
<mikdusan>
ok so if `undefined` is known at comptime then it can be checked for. and acted properly. but for runtime, i don't think there's a check for that and that's what optional is for.
<mikdusan>
i suppose though if undefined was it's own type, then comptime special function could say "ok no init".
<very-mediocre>
optional is for null, undefined is just like, uninitialized memory
<very-mediocre>
the keyword undefined usually lets the programmer state that a variable has deliberately not been initialized
<very-mediocre>
what that implies for passing undefined is beyond me
<very-mediocre>
you _can_ declare an undefined variable, and then pass that variable
<mq32>
mikdusan: i think the problem is that "undefined" has the type "undefined" and you tried to pass "undefined" to a var that was not comptime
<mikdusan>
wouldn't that _force_ a copy? i mean who wants to copy undefined
<mq32>
so something like "foo(i:u32)" would require "foo(u32(undefined))"
<very-mediocre>
mikdusan: I guess the compiler should be smart enough to never copy undefined
<very-mediocre>
and never needs to be, it's literally undefined behavior, typically garbage memory
<mikdusan>
today we have create() which alloc and never init.
<mikdusan>
on the table is a _replacement_ that always inits. i don't see how passing undefined would stop an init/copy, in which case it's doing more work (in debug/safe builds) than old create()
<very-mediocre>
I see your point, but I expect the compiler to know not to ever copy "undefined"
<mikdusan>
`var a: usize = undefined; var b = a;` i believe b = a will be a copy?
<very-mediocre>
yes, but i would argue it shouldn't be
<very-mediocre>
anyway when you really think about it, it's a moot point
<very-mediocre>
you could use any convention
<very-mediocre>
the goal is to let the programmer say "i want uninitialized memory"
<mikdusan>
mq32: yes i agree. which i see as an issue
<very-mediocre>
if that means passing a null, so be it
<very-mediocre>
no that was dumb of me, but i guess it could be a flag
<very-mediocre>
or... wait for it... your original suggestion of having a second function, createWithInit
<mq32>
i think optional/null would be more semantic, even if we have "undefined" as a keyword
<very-mediocre>
no because sometimes you want to initalize to null, which is not the same as uninitialized memory
laaron has quit [Remote host closed the connection]
<mikdusan>
yes, it looks to me a second fn is necessary
lunamn has joined #zig
<mikdusan>
and let's be honest, all this really does is have an alloc function that does a copy for you,
laaron has joined #zig
<mikdusan>
instead of doing it at the call-site after bare-bones alloc.create()
<very-mediocre>
that's true
<very-mediocre>
this whole idea came about because of default field init values
<very-mediocre>
semantically it "feels" like they should be initialized
<very-mediocre>
of course that's irrational
<Tetralux>
Personally, I'd like to have `createUninitialized` and `create` which initializes, which would be zeroing in other langs, but in Zig maybe it takes a T to initialize it with.
<mikdusan>
zig zen is going to be the deciding factor on that. i'd wait for the zen masters opinions on this too :)
<very-mediocre>
mikdusan: you've convinced me, it's probably not worthwhile
<very-mediocre>
Tetralux: can't init with T, because not all fields will have a default init value
<Tetralux>
very-mediocre: You'd be passing the T, and so you'd be doing .create(T{ .f1 = v1, .f2 = v2, ... })
<Tetralux>
i.e: You're either forced to init, or you call createUninit
<very-mediocre>
right ok, that's what the proposal was
<Tetralux>
Personally however
<Tetralux>
I'd prefer you had zero-initting and constructors
<Tetralux>
and then create (the one that inits) would call the initializer _and_ the constructor if there was one.
<Tetralux>
But in Zig we only have constructors, essentially.
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
<very-mediocre>
even constructors aren't really a thing in zig
<very-mediocre>
it
<very-mediocre>
it's just a convention
<Tetralux>
I was using those words specifically.
<Tetralux>
I mean
<Tetralux>
"T{ .f1 = v1, ... }" = constructor.
<Tetralux>
Whereas var x: T; is zeroing.
<Tetralux>
Except that in Zig you can't do that
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Tetralux>
Because it has to have a value.
<Tetralux>
But what I'm sayin g
<Tetralux>
Is that the default value would be to zero
<Tetralux>
Unless the type has a constructor in the struct definitiuon
<Tetralux>
in which case it would run that as well.
<Tetralux>
^^ calls the constructor after zeroing.
<Tetralux>
And so f1 == 42;
<very-mediocre>
I see, I'll have to take your word for it as I'm not familiar with any of this
<Tetralux>
XD
<Tetralux>
My point is - this is very simple.
<Tetralux>
And trivial to get your head around.
<Tetralux>
Because you always want things zeroed unless you don't.
<Tetralux>
Meaning, struct default values + constructor fn is enough.
<Tetralux>
And in Jai
<Tetralux>
You can call initializer_of(T) and constructor_of(T) to get the fn pointers for them.
<Tetralux>
.. meaning that userland code and call constructors and initializers manually.
<Tetralux>
.. meaning that Allocator.create can.
Ichorio has joined #zig
<Tetralux>
Whereas in Zig, it only could if you provided a value yourself, or had default values for all struct fields, in which case Allocator.create could just set it equal to {}.
<Tetralux>
In Jai
<Tetralux>
It looks like this:
<Tetralux>
p: *T = ...; init := initializer_of(T); con := constructor_of(T); if init { init(p) } if con { con(p) } return p;
<Tetralux>
Something like that.
<very-mediocre>
Yeah, that's martian to me as I've not looked into jai for ages
<Tetralux>
*grins*
<Tetralux>
= *get ptr to newly allocated thing*, *ask for the initializer fn ptr*, *if it exists, call it on the ptr*, *(same with constructor)*, return newly initted and 'constructed' ptr
forgot-password has joined #zig
<Tetralux>
Point is, struct instances are zero-initted by default, and constructors are called if they are specified for the type when you do the equivalent of `var x: T;`
<very-mediocre>
Noted
<Tetralux>
And you can get those initializer and constructor fns at runtime for a given type and then call it.
<Tetralux>
Which is what the equivalent of Allocator.create does in Jai.
<Tetralux>
In Zig, I believe you could only do initialize a struct instance by having the user pass a value into .create
<dimenus>
Tetralux: are you going off of videos or is there a public release now?
<Tetralux>
dimenus: Many videos. But that particular part of the stdlib has been shown quite a number of times.
forgot-password has quit [Ping timeout: 245 seconds]
<Tetralux>
But that's a whole other thing which I've been through before xD
<Tetralux>
Hmmmm.
<scientes>
hryx, so I rebased and updated my patch series as much as I could, but now I'm running to compiler bugs, and I have other priorities than #2129 https://github.com/shawnl/zig/tree/utf8-less
<Tetralux>
I guess that you could have .create---if you wanted it to initialize---check the type def for .init and if it exists, call it.. but that could take arbitrary params. :')
<Tetralux>
I guess it could emit a compile error in that case though.
<Tetralux>
(.. since the whole point is that you want it to auto init)
<mikdusan>
Tetralux: imo as soon as the init requires params, it _really_ should be in the type's struct
<mikdusan>
so Foo.create(allocator: *std.mem.Allocator, name: []const u8, num: usize, etc...) and have it call allocator, and then init alloc result.
<mikdusan>
is there really any incentive to make alloc.create() check a type's struct for defs of .init or similar? without params that's the same as default values, no?
fengb has joined #zig
<fengb>
Default values currently don't run on allocator creation
<fengb>
Although I'd love it if it did
<Tetralux>
mikdusan: It isn't necessarily the same, depending on exactly what init actually does.
<Tetralux>
If it just returns an instance with fields values specified, then no.
<Tetralux>
But if it does some sort of non-trivial computation, then yes it is different.
<Tetralux>
The latter is what I was calling a "constructor" before.
<fengb>
How would it handle multiple arguments?
<Tetralux>
It would emit a compile error if you tried to call .create on a type that requires extra args to .init
<fengb>
wat
SimonNa has joined #zig
<Tetralux>
If the set up of a type requires extra data, like an allocator or something, then you'd be expected to call .createUndefined(T) and do ptr.* = T.init(...);
<Tetralux>
At least, with status-quo Zig, you would.
<fengb>
There's an issue to detect using undefined in debug/safe mode
<Tetralux>
Essentially, T.init() would be called by .create(T). If .init has extra arguments that need to be passed, then .create has no idea where to get those values from and so it errors. In which case, you'd have to do .createWithValue(T, T.init(...)} or .createUndefined(T) and initialize the ptr yourself.
<Tetralux>
(The last one is how we do it now.)
<Tetralux>
Well... I suppose you could do .createUndefined(T).init(...), which'd be cleaner.
<fengb>
At that point, I'd just prefer .create(T).init() as a convention and let the system catch accessing undefineds
<Tetralux>
If you could get at the default values of the fields in RTTI, and .init only had one arg (*Self) then you could just have .create set the fields to their defaults and then call .init if there is one.
<Tetralux>
And then var x = allocator.create(T)
<Tetralux>
would be the same as
<fengb>
It also gets much more complicated when allocating nested structs
Flaminator has joined #zig
<Tetralux>
var x = allocator.createUndefined(T).init(); // also sets fields to default values.
<mikdusan>
small note it would need to be: `(try .create(T)).init()`
<Tetralux>
mikdusan: Yes it would.
Akuli has joined #zig
<Tetralux>
Point is - it is _possible_ for .create(T) to set fields to defaults and call .init() ?
<Tetralux>
And also note how right now, if any field did not have a default, it would emit a compile error.
<Tetralux>
Honestly, I kinda like the simplicity of .create(T).init() and .createUndefined(T).init()
<Tetralux>
_Except_
<Tetralux>
As soon as you need to pass things to .init, you have to expand it to the status quo.
<Tetralux>
Or no
<Tetralux>
That's not right.
<Tetralux>
You do have to have .init on your type, otherwise you have to expand to status quo.
<Tetralux>
Wait - not .create(T).init() -- the point was that .create did the init too xD
<Tetralux>
I really shouldn't be doing this while tired XD
<Tetralux>
A simple thing we could do right now though is just have .create take an instance of T to initialize the memory to.
<Tetralux>
.. as was mentioned before.
<Tetralux>
var t = a.createUndefined(T).init(...); var t2 = a.create(T, T{...});
<mikdusan>
vs today:
<mikdusan>
`a.create(T).init(...)` and `a.create(T); a.* = T{...};`
<Tetralux>
The issue being that it's not clear that the result of .create is undefined.
<mikdusan>
with respect, that's not an issue for me. i'm ok with the contract/idiom
<Tetralux>
( .. Whereas the result of .init always is.)
<Tetralux>
Point is, it's a gotcha.
<Tetralux>
You can get used to it, sure.
<Tetralux>
But it's a gotcha. And it's uncessary.
<Tetralux>
Just call it .createUndefined and be done with it xD
<mikdusan>
.allocOne()
<mikdusan>
to be fair my naming is probably not a good idea... i don't account for what .destroy() does
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre1 has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
darithorn has joined #zig
brakmic_ has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic_ has quit [Read error: Connection reset by peer]
brakmic has joined #zig
<dimenus>
note to self, don't pass structs with opaque fields by address to c functions....
<dimenus>
or you're going to have a bad time
<Tetralux>
Oh? xD
IntoxicatedHippo has joined #zig
IntoxicatedHippo has quit [Client Quit]
very-mediocre1 has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
dawzon has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
ofelas has joined #zig
jjido has joined #zig
very-mediocre has quit [Read error: Connection reset by peer]
forgot-password has joined #zig
<forgot-password>
Why does Zig detect a dependency loop when importing objc/runtime.h?
fengb has quit [Ping timeout: 260 seconds]
darithorn has quit [Quit: Leaving]
very-mediocre1 has joined #zig
lunamn has quit [Quit: leaving]
Flaminator has quit [Disconnected by services]
ltr- has joined #zig
<nifker>
The thumbv7m ELF I compiled yesterday and converted using arm-none-eabi to a binary did not really work - it just results in an empty binary with 0Bytes
very-mediocre1 has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
dawzon has quit [Remote host closed the connection]
<mq32>
nifker, do you use symbol garbage collection in linker step?
<nifker>
do you mean in the linker script?
<mq32>
no, in the linker invocation
<mq32>
-Wl,--gc-sections
<nifker>
not that I know of
<andrewrk>
gc-sections is on by default. but that is fine if you export your entry points
<andrewrk>
use the export keyword or @export builtin function
forgot-password has quit [Read error: Connection reset by peer]
<andrewrk>
that code snippet would also need the definition of PERIPHERALS to be useful. I suspect that is a bad deref
<Tetralux>
Also, I think line 18 is meant to be `var in: u8 = KEY_1.*`
darithorn has quit [Quit: Leaving]
<nifker>
so whats the difference between ptr.* and *ptr?
<hryx>
andrewrk: regarding #2569, anything I can do to investigate or provide more info? As it stands I'm not sure next steps to solve the build failure
<hryx>
also I know it's not high priority, so if you want to leave it on hold for the time being that's fine with me
<andrewrk>
hryx, I had a brief look and determined that this is relatively difficult compared to other PRs, so I'll come back to it in a bit
<andrewrk>
I'm currently on #2509
<hryx>
cool, no problem
<hryx>
meantime I'll try to tackle some smaller ones
<andrewrk>
yeah thanks for that \u{}, good stuff
<andrewrk>
love it when I can just press the big green button
<hryx>
(^_^)_b
<nifker>
I finally got it compile again and my outcoming binary is still 0Bytes big
<andrewrk>
nifker, what happened when you tried my advice last time you asked this question?
rjtobin has joined #zig
<nifker>
you mean the "extern"?
<andrewrk>
please read my answer again, it looks like you did not read it correctly
very-mediocre has quit [Read error: Connection reset by peer]
<nifker>
hmm
avoidr has quit [Quit: leaving]
avoidr has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nifker>
idk
very-mediocre has joined #zig
very-mediocre has left #zig [#zig]
avoidr has quit [Client Quit]
avoidr has joined #zig
<andrewrk>
nifker, OK. beginners are more than welcome here, but I need you to try a little harder, both to be more polite, and to be more respectful of people's time who are giving help. can you do that? yes or no.
<nifker>
I think so
nifker was banned on #zig by ChanServ [*!*@x4e31abc4.dyn.telefonica.de]
nifker was kicked from #zig by ChanServ [Banned: disrespect !T 1w]
<andrewrk>
I said yes or no. you can try again in 1 week.
brakmic has quit [Read error: Connection reset by peer]
dawzon has joined #zig
marler8997_ has quit [Ping timeout: 244 seconds]
Ichorio has joined #zig
brakmic has joined #zig
andersfr has joined #zig
<andersfr>
how can I become a contributor to the Zig project?
<andersfr>
I did a port of the murmur hash and cityhash algorithms and wanted to add them to std.hash
Akuli has quit [Quit: Leaving]
<andersfr>
I happened to need better hashing algorithms for a set implementation on a hobby project
fengb has joined #zig
<hryx>
oh, cool. I'm not sure what the criteria would be when deciding whether that would get merged into the standard library. At the very least you should add a link to your project on the wiki: https://github.com/ziglang/zig/wiki/External-Projects
<andrewrk>
andersfr, I think those would be welcome in std, at least until package manager is available and we decide which code will stay in std and what should be extracted to become separate packages
<andersfr>
I hadn't spotted the open issue yet but thx for pointing it out
<andersfr>
I happen to also be a c++ programmer with LLVM experience but I think it is better to go for native Zig first. Otherwise I have to reimplement everything later or keep maintaining c++ code...
<andrewrk>
I don't think you need to interact with LLVM, but the c++ compiler code is the only thing that has an implementation of analyzing zig source code, so you'd be doing at least some of that work
<andrewrk>
you might be able to get a good chunk of things working relatively quickly, but to truly have correct language understanding you'd need a full comptime / semantic analysis implementation
<andrewrk>
which is why my plan for this is to integrate it into the self hosted compiler
<andersfr>
I agree completely
<andrewrk>
a competing zig implementation would be amazing
<andersfr>
worst case I would have to contribute some analysis code to the self hosted compiler ;-)
<andrewrk>
someone who makes significant progress on such a project would have a lot of clout as far as their proposals & discussion on existing proposals because they would be very well informed on the details
<andrewrk>
I would also be willing to start working on the language specification if that were the case
<andersfr>
lets hope that I manage to make good progress. It is by no means an easy task
<andrewrk>
agreed
jjido has joined #zig
<andrewrk>
andersfr, one of the goals of this release cycle is redoing coroutines so that we can have nice async/await syntax. I think this will help a lot for servers in general, including LSP
<andrewrk>
it helps code model a pipeline
<mq32>
andrewrk, btw: thumbs up for the endeavor to unify async/blocking APIs
<andersfr>
for now I am mostly focused on the parsing part but it will indeed be the obvious solution for an LSP server
<mq32>
that's something that is bad in almost any lang with async
<andrewrk>
mq32, we'll see! it's a really ambitious project, but I definitely think it's worth a try
<andrewrk>
you can thank daurnimator for convincing me to try to do it
<mq32>
yes, for sure!
<andrewrk>
andersfr, oh, you should probably use the tokenizer/parser from the std lib, did you know about that?
<andrewrk>
the self-hosted tokenizer and parser is done already
<andersfr>
I know and have used them
<andersfr>
but the parser suffers from the first-error quits everything problem
<andrewrk>
ahh for integration with IDEs
<andersfr>
I have to do a lot of error recovery etc which needs a different model
<andrewrk>
right. one more piece of information, btw, zig has line-independent tokenization
<andrewrk>
so when you see a \n you can reset the tokenizer state
<andersfr>
I wrote an independent table based tokeniser already just for lols
<andrewrk>
andersfr, also, it's planned for bad indentation to be a compile error, so you can also use that to recover from mismatched braces and stuff. https://github.com/ziglang/zig/issues/35
supereti has joined #zig
andersfr has left #zig [#zig]
laaron- has joined #zig
laaron has quit [Remote host closed the connection]
brakmic_ has joined #zig
brakmic_ has quit [Read error: Connection reset by peer]
brakmic_ has joined #zig
brakmic has quit [Read error: Connection reset by peer]
<dawzon>
New user question: Is there any documentation on where Zig looks for C header files for linkSystemLibrary()? I couldn't find anything in the main docs. (I'm using 0.4.0 on Windows)
<andrewrk>
dawzon, currently, nowhere; you'll have to explicitly provide all the search directories manually
<hryx>
I'll read that one and see if it would be redundant to open a new proposal
<hryx>
thanks
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<supereti>
Hi! I'm trying to use `zig build` to do static linking with C project that uses raylib. I want to do the equivalent of `clang -framework CoreVideo -framework IOKit -framework Cocoa -framework GLUT -framework OpenGL libraylib.a game.c -o game` in build.zig file. Here's the build.zig work in progress: https://pastebin.com/rTU6LarJ and here's the er
<andrewrk>
supereti, one recommendation I would make would be to use master branch rather than 0.4.0
<andrewrk>
I believe homebrew has an arg for that
<hryx>
andrewrk: your last comment in 732 is well written. I won't open a new proposal because your comment already addressed the reasoning
<hryx>
it's very helpful to have justification for accept/reject recorded in an issue like that
<fengb>
Would it be difficult to maintain a list of major changes of master vs last stable release?
<andrewrk>
hryx, agreed
<andrewrk>
fengb, I do that with the release notes
<andrewrk>
it could potentially be useful to do the release notes during the release cycle rather than at the end, which I think is what you're suggesting
<andrewrk>
personally it's easier to motivate myself to do them when the release is imminent
<fengb>
Yeah, doesn't have to be comprehensive
<fengb>
I can understand that. Nobody really likes documenting :P
<supereti>
andrewrk: error output using zig 0.4.0+9471f16c https://pastebin.com/hy0CsN4e Maybe I shouldn't be using `--object foo.a` (via `lib.addObjectFile("foo.a")`) to specify the lib?
<andrewrk>
that should be ok
<andrewrk>
in your paste earlier, it looks like the zig compiler is crashing
<andrewrk>
ah, yes in this new paste, zig is crashing in the linker
<andrewrk>
supereti, I'm going to tell you about a secret feature to help figure out why this is happening
<andrewrk>
no, it's due to a lack of interest by relevant parties
<fengb>
Nobody at Apple works on lld?
<emekankurumeh[m]>
llvm's mach-o is unmaintained, tcc doesn't have a mach-o backend
<emekankurumeh[m]>
it's like mach-o is the plague
<supereti>
andrewrk, that looks like it almost did the trick. I'm getting an "undefined symbols" error for the raylib functions so it probably can't find the header file.
<emekankurumeh[m]>
what about swift?
<andrewrk>
fengb, correct
<andrewrk>
supereti, undefined symbols means you're missing objects/libraries on the linker line, should not be affected by .h files
<supereti>
can you manually add linker flags via build.zig?
<andrewrk>
to debug the linker line you can use --verbose-link
<andrewrk>
emekankurumeh[m], <supereti> andrewrk: error output using zig 0.4.0+9471f16c https://pastebin.com/hy0CsN4e
<andrewrk>
supereti, ok I'm pretty sure this is a name collision with libraylib.a
<andrewrk>
why do you have that raylib.addObjectFile("libraylib.a"); there? is it produced by a makefile or some other part of the build process?
<supereti>
So the `libraylib.a` in the game dir is conflicting with the `libraylib.a` in a system dir? I put the addObjectFile thing in there manually. Trial and error. I'm trying to use the librarylib.a in the game dir, but maybe that's a bad idea?
<supereti>
`zig build-exe --c-source -std=c99 /path/to/game/main.c --library c --object /path/to/game/zig-cache/o/zg-nWwYdUXY_etMH0AARbU_eOhLsMHTDn197R32r1jwa_bxYwCw1WQn0MOjtIhB5/libraylib.a --cache-dir /path/to/game/zig-cache --name game -isystem /path/to/game/zig-cache/o/zg-nWwYdUXY_etMH0AARbU_eOhLsMHTDn197R32r1jwa_bxYwCw1WQn0MOjtIhB5 -framework OpenGL -fra
<andrewrk>
supereti, sorry, actually I think there is no name conflict, it should be fine. but I do see a problem in the build-exe command: the libraylib.a that you have attempted to manually add is missing
<andrewrk>
which points to a bug in zig build not correctly passing the arg to build-exe
<supereti>
andrewrk, Hmm, I also see the following waring amidst a ton of `ld: warning: text-based stub file /... and library file /... are out of sync. Falling back to library file for linking.` warnings: `ld: warning: ignoring file /path/to/game/zig-cache/o/zg-nWwYdUXY_etMH0AARbU_eOhLsMHTDn197R32r1jwa_bxYwCw1WQn0MOjtIhB5/libraylib.a, file was built for arch
<supereti>
ive which is not the architecture being linked (x86_64): /path/to/game/zig-cache/o/zg-nWwYdUXY_etMH0AARbU_eOhLsMHTDn197R32r1jwa_bxYwCw1WQn0MOjtIhB5/libraylib.a`
brakmic_ has quit []
<andrewrk>
oh, oh, oh. you're linking a .a file into another .a file. is that even allowed? I'm not sure, maybe
<andrewrk>
but the build-exe line is fine, because the one .a file is in the other one
<andrewrk>
so this warning you're getting seems pertinent. it souds like the .a file you are trying to manually add to the linker line is no good
<andrewrk>
how did you get it?
<supereti>
I'm probably doing something dumb in build.zig. Maybe the whole `b.addStaticLibrary` thing is a bad idea.
<supereti>
I built raylib manually. Also tried using the one created by homebrew.
<andrewrk>
addStaticLibrary is for when you're trying to produce a .a file
<andrewrk>
which I don't think you are. you're just trying to build your game
<supereti>
right. facepalm.
<supereti>
okay, that works! thanks andrewrk!
<andrewrk>
zig package manager will make all this stuff "just work". no worries.
<andrewrk>
until then people will have all kinds of fun fiddling with their builds
shritesh has quit [Ping timeout: 252 seconds]
<supereti>
documenting the whole zig build system would be great too, though I assume that's lower priority understandably.
<programisto>
hi. went rhough the docs and didn't see the answer. how do I get around "x does not support field acess" for a c type? I'm guessing some kind of cast