ahmed_elgabri has quit [Ping timeout: 240 seconds]
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nix-darwin
andremedeiros has quit [Read error: Connection reset by peer]
andremedeiros has joined #nix-darwin
ahmed_elgabri has joined #nix-darwin
ahmed_elgabri has quit [Ping timeout: 272 seconds]
LnL has quit [Quit: exit 1]
ahmed_elgabri has joined #nix-darwin
ahmed_elgabri has quit [Ping timeout: 260 seconds]
andremedeiros has quit [Read error: Connection reset by peer]
andremedeiros has joined #nix-darwin
andremedeiros has quit [Read error: Connection reset by peer]
andremedeiros has joined #nix-darwin
ahmed_elgabri has joined #nix-darwin
ahmed_elgabri has quit [Ping timeout: 244 seconds]
andremedeiros has quit [Read error: Connection reset by peer]
andremedeiros has joined #nix-darwin
heywoodlh has quit [Ping timeout: 265 seconds]
LnL has joined #nix-darwin
ahmed_elgabri has joined #nix-darwin
ahmed_elgabri has quit [Ping timeout: 272 seconds]
heywoodlh has joined #nix-darwin
<emily>
so I updated to Big Sur and my C/C++ nixpkgs toolchain seems to have broken ("ld: file not found: /usr/lib/system/libcache.dylib for architecture x86_64", https://github.com/NixOS/nixpkgs/issues/91748)... is this an expected issue still on current master or is my setup broken somehow?
<{^_^}>
#91748 (by sycured, 38 weeks ago, closed): impossible to link (ld / clang) liboping on macOS Big Sur 11 Beta
<emily>
even `nix-shell -p --run 'clang foo.c'` fails on a simple hello world
ahmed_elgabri has joined #nix-darwin
Chiliparrot has joined #nix-darwin
<thefloweringash>
emily: not expected on current master, or any master since late 2020
<emily>
something isn't right then >_> guess I'll poke at it more and try and figure out what's up
Chiliparrot has quit [Ping timeout: 260 seconds]
<emily>
gosh, maybe my nix channels are broken and I'm not getting nixpkgs updates at all?? I'll investigate more tomorrow
__monty__ has joined #nix-darwin
Mic92 has quit [Quit: WeeChat 3.1]
Mic92 has joined #nix-darwin
andremedeiros has quit [Read error: Connection reset by peer]
andremedeiros has joined #nix-darwin
philr_ has quit [Ping timeout: 264 seconds]
ahmed_elgabri has quit [Ping timeout: 244 seconds]
ahmed_elgabri has joined #nix-darwin
ahmed_elgabri has quit [Ping timeout: 264 seconds]
oliver85 has joined #nix-darwin
oliver85 has quit [Quit: Connection closed]
<LnL>
yeah, sounds like an old revision you can check by looking for Libsystem in otool -L <binary>
eraserhd2 has joined #nix-darwin
eraserhd has quit [Ping timeout: 240 seconds]
eraserhd3 has joined #nix-darwin
eraserhd2 has quit [Ping timeout: 265 seconds]
ahmed_elgabri has joined #nix-darwin
ahmed_elgabri has quit [Ping timeout: 264 seconds]
ahmed_elgabri has joined #nix-darwin
<__monty__>
LnL: So I'm looking into the stdenv again. Should I not allow `add-aliases.sh` to run when generating stubs? I get errors re creating existing symlinks in the stubs store directory. https://gist.github.com/toonn/2dfb04d075db4bdaedb0504339a74046
<__monty__>
Maybe thefloweringash knows more ^ ?
<LnL>
yeah I haven't actually used the stub tooling yet, he probably knows more
<LnL>
but my initial suggestion was to just replace one file in the existing stubs tarball
<supersandro2000>
btw siraben asked if he could join the darwin maintainers team :)
<supersandro2000>
thought I re-ask this question while someone of them is oneline
<__monty__>
LnL: Oh right. I'm not sure how to generate just a single stub tbh, because it's a recursive process. I think I've found this little issue though.
<LnL>
you mean the NixOS/darwin-maintainers group?
<__monty__>
The use of darwin-stubs in the darwin stdenv was trying to create the aliases it needs. I guess `add-aliases.sh` was added afterwards and that change hasn't made it to stdenv yet.
<LnL>
I don't remember exactly but I think you just call tapi with a library as it's argument
<LnL>
as long as it's not an umbrella library like libSystem.B.dylib that should be enough to replace a stub file
ahmedelgabri has joined #nix-darwin
<LnL>
actually maybe even that's fine, all of the postprocessing happens in the stdenv since we need to know $out for that
ahmed_elgabri has quit [Ping timeout: 272 seconds]
<supersandro2000>
LnL: yeah
<LnL>
I think only somebody with org permissions can do that
<__monty__>
LnL: I guess I'm not clear on which problems only stubbing a single library solves?
<__monty__>
Next error I'm running into is the bootstrap compiler being unable to create executables, which seems bizarre. https://git.io/JmxTi
<LnL>
I there's a very good chance that futimens is the only import symbol that's missing
<supersandro2000>
LnL: we will find someone that can do that but would it be okay if he joined?
<LnL>
if you do that libSystem.tbd probably won't exist which will cause lots of problems :)
<__monty__>
LnL: Still, shouldn't an SDK bump include all the new stubs anyway?
<LnL>
yeah if we bump the minvers
<__monty__>
Only if that's bumped? As I understood it so far the stubs should be in sync with the SDK and then specifying the deployment target affects which parts are allowed to be linked to and possibly behavior of the parts that can be linked to?
<LnL>
supersandro2000: it's just the group, as far as I know it doesn't give any special permissions so sure anybody can join if they want as far as I'm concerned
eraserhd3 has quit [Quit: WeeChat 3.1]
eraserhd has joined #nix-darwin
<LnL>
__monty__: the exact boundary between those is a bit vague, we've always just kept them in sync
<__monty__>
I want to possibly stop doing that.
<__monty__>
It's unfortunate to stop supporting darwin versions just because the SDK is bumped, since the packages more likely than not haven't changed.
<LnL>
not sure that's a good idea
<LnL>
well, as you can see you can't just bump the sdk without also changing the available symbols (ie minversion)
<__monty__>
That's why I brought up being able to override the deployment target per-package. Whenever we find a package doesn't support as far back as 10.12 we can just override.
<__monty__>
I don't see that actually. Could you clarify?
<LnL>
in theory the deployment target keeps things compatibe, but in practice we enforce compatibility by limiting the available symbols for libraries
<LnL>
the reason futimens isn't available because calling it on a 10.12 machine would break
<__monty__>
Yes, essentially obviating the deployment target mechanism.
<__monty__>
But only packages that actually need functions like _futimens would require an override of the deployment target.
<LnL>
so what you're doing right now to work around it implies that 10.12 wouldn't work anymore
<__monty__>
Shouldn't it still by keeping the deployment target at 10.12 as a default?
<LnL>
lots of projects, especially unix stuff tries to discover available symbols so it will detect that it's available on the build host
<LnL>
only very specific things would maybe work
<LnL>
if you really want that I'd rather make minvers overridable so you can make a custom local build for a specific project
<LnL>
however that also falls down quite quickly if anything in the build environment isn't compatible
<__monty__>
Relaxing the deployment target after the fact isn't useful imo. That entails rebuilding the world. Which is what I wanted to avoid by keeping the deployment target at what is currently supported.
<__monty__>
But you're saying things like configure would look at stubs to determine which functions are present?
<__monty__>
Do only apple tools like Xcode and xcbuild respect the deployment target?
<LnL>
yeah, not only xcode but as far as I know the deployment is a header only thing
<LnL>
and we don't hard enforce it either so builds can just ignore it completely
<__monty__>
As in, it doesn't limit the use of functions added to existing headers. Just the use of newly introduced headers?
<LnL>
as for minvers, I think that's just a flag in the binary which blocks execution nothing more
<LnL>
extra headers or using plain externs to discover symbols which I think is pretty common in configure scripts
<__monty__>
It goes through your code and picks up all the extern declarations as symbols that must exist somewhere? (I'm not very familiar with C or configure.)
<LnL>
it's the tradeoff we make between using a single platform for all os versions to enable sharing vs one for each version allowing things to use new features
<LnL>
I don't know exactly how autoconf works, but from what I understand it tries to bunch a bunch of small int main() { return 0; } programs with various small features
<LnL>
hmm, kind of weird that I can link against futimens in a shell
<LnL>
n/m it fails in a proper shell
<__monty__>
LnL: There's a -Wpartial-availability compiler option. I assume for clang. Could we not force this option and turn warnings into errors to detect which packages would need a deployment target bump?
<LnL>
heh, fixing all warnings doesn't sound like a fun project :D
<__monty__>
How about disabling all warnings but that one and maybe -Wunguarded-availability and then promoting warnings to errors?
<__monty__>
You're making it sound like the only way to support as many macs as possible while still supporting very new software is to package every SDK (starting at 10.12 for practical reasons).
<__monty__>
Please say it ain't so : )
<LnL>
none of the options that you're suggesting are impossible, but it's all going to be lots of work I think
<LnL>
I'd start out with updating like regular and once most of that's done maybe take a look at how much broke with this bump
<LnL>
if we're lucky some stuff still works if we only keep minvers lower
<__monty__>
Would as usual involve only regenerating the necessary stubs or all of them as I'm currently doing?
<LnL>
yeah, alltho I'm a bit surprised you're hitting problems with that already
<__monty__>
Wait, yeah the former or yeah the latter?
philr_ has joined #nix-darwin
<LnL>
ah
<LnL>
all of them at some point for consitency, but just a few is most likely enough to get rolling for now
copumpkin has quit [Remote host closed the connection]