| 24 May 2024 |
 Philip Taron (UTC-8) | In reply to @tpw_rules:matrix.org
that's what the -z flag is for today I learned 🙇♂️ | 22:19:07 |
| 29 May 2024 |
|  raitobezarius changed their display name from raitobezarius to raitobezarius (DECT: 7248). | 17:10:36 |
| 2 Jun 2024 |
|  @aloisw:kde.org set a profile picture. | 18:01:48 |
| @aloisw:kde.org changed their profile picture. | 18:23:56 |
|  dadada changed their profile picture. | 23:02:55 |
| dadada changed their profile picture. | 23:04:32 |
| dadada changed their profile picture. | 23:09:27 |
| 4 Jun 2024 |
| raitobezarius changed their display name from raitobezarius (DECT: 7248) to raitobezarius. | 11:16:20 |
| 7 Jun 2024 |
 trofi | https://github.com/NixOS/nixpkgs/pull/317106: a few fixes to survive sourceRoot that starts with -. | 05:19:46 |
| 8 Jun 2024 |
 ris_ | https://github.com/NixOS/nixpkgs/pull/318256 | 14:23:25 |
| 16 Jun 2024 |
|  h7x4 joined the room. | 01:15:23 |
| 17 Jun 2024 |
 Qyriad | In reply to@philiptaron:matrix.org
stdenv folks: https://github.com/NixOS/nixpkgs/pull/310387 looks like it's hit the marks asked of it. Anything else, or should it be merged? I'd really love to get this merged too, so let me know if it needs anything else | 19:11:39 |
| 19 Jun 2024 |
| raitobezarius | Qyriad done | 12:22:29 |
|  Zach joined the room. | 21:24:55 |
| 20 Jun 2024 |
|  @yuka:yuka.dev left the room. | 13:45:14 |
| 21 Jun 2024 |
|  w4tsn joined the room. | 19:45:48 |
| w4tsn | Hey there! I'm building buildroot under nixos and while it does not need much from the host OS as it build most of it's cross-compile toolchain from very little I failed at a step where the build process tried to access c99 command. While this command of gcc is long gone (it's an option to gcc still) it appears that most "usual" distros still package a c99 wrapper for such cases. E.g. see arch*
* https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/commit/cacf18c7cd79fb00645a4bf367392b05ad2dc290
** https://gitlab.archlinux.org/archlinux/packaging/packages/gcc
So my question is should this also be done in the nix pkg?
It's not really a problem for me as I just added those wrappers in my shell env but still I'm wondering what you think.
My contribution to nix-community/nix-environments for reference: https://github.com/nix-community/nix-environments/pull/75
| 19:57:52 |
 Artturin | In reply to @w4tsn:darmstadt.social
Hey there! I'm building buildroot under nixos and while it does not need much from the host OS as it build most of it's cross-compile toolchain from very little I failed at a step where the build process tried to access c99 command. While this command of gcc is long gone (it's an option to gcc still) it appears that most "usual" distros still package a c99 wrapper for such cases. E.g. see arch*
* https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/commit/cacf18c7cd79fb00645a4bf367392b05ad2dc290
** https://gitlab.archlinux.org/archlinux/packaging/packages/gcc
So my question is should this also be done in the nix pkg?
It's not really a problem for me as I just added those wrappers in my shell env but still I'm wondering what you think.
My contribution to nix-community/nix-environments for reference: https://github.com/nix-community/nix-environments/pull/75
Why upstream doesn't just change the commands? | 20:02:17 |
| Artturin | Or add the wrapper in tree | 20:02:32 |
| w4tsn | Those are good questions and I don't have answers yet. I'll have to follow up on that.
My best guess is that distros do this to be POSIX compliant as the c99 command is specified in POSIX 1003.1-2001 (Single Unix v3) but gcc as a project itself is not obliged to follow that | 20:20:31 |
| w4tsn | In Section "XSI Shell and Utilities Conformance" in Chapter 2. Conformance it reads
The following requirements apply to the shell and utilities when the XSI option is supported:
[...]
- The C-language Development utility c99 shall be supported.
| 20:30:59 |
| 22 Jun 2024 |
 p14 | Crazy idea: what if the stdenv had a checkPhase step which, if there is a c compiler, checks that it can successfully build int main() and using printf/std::cout?
The benefit would be that a broken compiler would show up as failing to build an obvious test program rather than failing in random bits of configure script for other stuff you try to use downstream of constructing the stdenv.
| 11:20:38 |
 vcunat | Nit: checkPhase is too late. Looong after configurePhase. | 11:42:01 |
| vcunat | Sounds OK to me. Can't see why not, by default. | 11:48:06 |
| vcunat | Though note that you basically always have a C compiler, as it's included in the standard stdenv. So maybe there would be some edge cases where it isn't a good idea to do such a test. | 11:49:48 |
| @aloisw:kde.org | I think their idea was that the stdenv package itself gains a checkPhase which verifies that its C compiler works. | 12:19:46 |
| Artturin | In reply to @p14:matrix.org
Crazy idea: what if the stdenv had a checkPhase step which, if there is a c compiler, checks that it can successfully build int main() and using printf/std::cout?
The benefit would be that a broken compiler would show up as failing to build an obvious test program rather than failing in random bits of configure script for other stuff you try to use downstream of constructing the stdenv.
Well there is tests.stdenv and tests.cc-wrapper | 12:57:38 |
| p14 | In reply to @artturin:matrix.org
Well there is tests.stdenv and tests.cc-wrapper Yeah, aware of this, but the concept is to stop a build during development if the basic/essential compiler config is borked. The would mostly benefit exotic environments, people messing with compilers and standard libraries and those developing them. | 13:11:49 |
| p14 | But could save a fair amount of pain there. | 13:12:02 |
| w4tsn | In reply to @w4tsn:darmstadt.social
In Section "XSI Shell and Utilities Conformance" in Chapter 2. Conformance it reads
The following requirements apply to the shell and utilities when the XSI option is supported:
[...]
- The C-language Development utility c99 shall be supported.
An alternative to add the scripts to the gcc package could be to modify buildFHSUserEnv to provide these scripts if gcc is part of the env. If buildFHSUserEnv is designed to provide a POSIX compliant shell that is | 13:15:45 |
