!OqhvaDMJdKYUicLDiE:nixos.org

Nixpkgs Stdenv

136 Members
49 Servers

Load older messages


SenderMessageTime
19 Jun 2024
@raitobezarius:matrix.orgraitobezarius Qyriad done 12:22:29
@zachcoyle:matrix.orgZach joined the room.21:24:55
20 Jun 2024
@yuka:yuka.dev@yuka:yuka.dev left the room.13:45:14
21 Jun 2024
@w4tsn:darmstadt.socialw4tsn joined the room.19:45:48
@w4tsn:darmstadt.socialw4tsn

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:matrix.orgArtturin
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:matrix.orgArtturinOr add the wrapper in tree20:02:32
@w4tsn:darmstadt.socialw4tsnThose 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 that20:20:31
@w4tsn:darmstadt.socialw4tsn

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:matrix.orgp14

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:matrix.orgvcunat Nit: checkPhase is too late. Looong after configurePhase. 11:42:01
@vcunat:matrix.orgvcunatSounds OK to me. Can't see why not, by default.11:48:06
@vcunat:matrix.orgvcunatThough 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@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:matrix.orgArtturin
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:matrix.orgp14
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:matrix.orgp14But could save a fair amount of pain there.13:12:02
@w4tsn:darmstadt.socialw4tsn
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
@p14:matrix.orgp14I just went through a round of 'configure phase fails with message buried in config.log', 'try to determine if compiler works', 'it seems to work', 'but actually doesn't work correctly in the stdenv', where if the stdenv had just refused to build with a clear message showing it can't build hello world main.c it would have saved a bunch of time.13:16:03
@p14:matrix.orgp14I guess from the implementation of the stdenv's builder this might not be trivial to achieve: https://github.com/NixOS/nixpkgs/blob/1eae5f88019f10beb0da370cc7d1726471ed11da/pkgs/stdenv/generic/builder.sh#L23-L24 Is it straight forward to 'drop into the stdenv we just built' at the end of that script and attempt to run the compiler?13:22:00
@artturin:matrix.orgArtturin
In reply to @p14:matrix.org

I guess from the implementation of the stdenv's builder this might not be trivial to achieve:
https://github.com/NixOS/nixpkgs/blob/1eae5f88019f10beb0da370cc7d1726471ed11da/pkgs/stdenv/generic/builder.sh#L23-L24

Is it straight forward to 'drop into the stdenv we just built' at the end of that script and attempt to run the compiler?

No, cc is added after the builder is built
13:22:46
@artturin:matrix.orgArtturinI think so do check13:23:30
@vcunat:matrix.orgvcunat

the idea was that the stdenv package itself gains a checkPhase

Oh, OK. Though an issue is that you can often break it by per-package stuff, e.g. NIX_CFLAGS_COMPILE.

14:12:36
@p14:matrix.orgp14
In reply to @vcunat:matrix.org

the idea was that the stdenv package itself gains a checkPhase

Oh, OK. Though an issue is that you can often break it by per-package stuff, e.g. NIX_CFLAGS_COMPILE.

Yeah; I realise that is also an issue. I am first considering just broken stdenv though. At least with a stdenv check you only pay for a trivial compile once for the stdenv and not for every package, which seems more bearable. A per package check might also be nice but obviously comes at a greater compute cost.
14:41:40
@p14:matrix.orgp14
In reply to @artturin:matrix.org
I think so do check
Not quite able to follow what you mean there by “after the builder”, what I see is that stdenv has a fairly trivial shell script which builds the stdenv and it has the cc passed into it. Unless I misunderstand…
14:43:17
29 Jun 2024
@mib:kanp.aimib 🥐 joined the room.22:25:02
4 Jul 2024
@philiptaron:matrix.orgPhilip Taron (UTC-8) left the room.15:46:23
@philiptaron:matrix.orgPhilip Taron (UTC-8) joined the room.15:54:09
@soispha:vhack.euBenedikt changed their display name from Soispha to Benedikt.19:10:28
7 Jul 2024
@dminca:matrix.orgdminca joined the room.09:39:05

Show newer messages


Back to Room ListRoom Version: 9