lix-project/lix

Fork 54

“‘FILE’ does not name a type” with gcc and -Denable-pch-std=false #410

New issue

Closed

opened 2024-06-23 11:36:54 +00:00 by delan · 5 comments

delan commented

2024-06-23 11:36:54 +00:00

src/libcmd/repl.cc fails to compile under the default shell, but compiles ok under the native-clangStdenvPackages shell. not sure why this doesn’t happen in ci, which also uses the gcc-based shell.

Steps To Reproduce

nix develop or nix-shell
just clean
meson setup build --prefix="$PWD/outputs/out" $mesonFlags (not just setup!)
just install

`nix --version` output

nix (Nix) 2.18.1

Additional context

error below; adding #include <cstdio> to the top of the offending file fixes the problem for me.

[170/467] Compiling C++ object src/libcmd/liblixcmd.so.p/repl.cc.o
FAILED: src/libcmd/liblixcmd.so.p/repl.cc.o
g++ -Isrc/libcmd/liblixcmd.so.p -Isrc/libcmd -I../src/libcmd -Isrc/libutil -I../src/libutil -Isrc/libstore -I../src/libstore -Isrc/libexpr -I../src/libexpr -Isrc/libfetchers -I../src/libfetchers -Isrc/libmain -I../src/libmain -I/nix/store/givfqzc5vc4rqk64qghj7592z0msbl2c-boehm-gc-8.2.6-dev/include -I/nix/store/n1ddcimbjkxiiissmqqrh07ncj5xgaj4-editline-1.17.1-dev/include -I/nix/store/zij437icdrq28cdhq179rpy8xxanax4n-lowdown-1.1.0-dev/include -I/nix/store/mafwrbrcqq4i92lq5ypgq3mka0wwn9vp-nlohmann_json-3.11.3/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++2a -O2 -g -include config.h -Wno-deprecated-declarations -Wimplicit-fallthrough -Werror=switch -Werror=switch-enum -Wdeprecated-copy -Wignored-qualifiers -D_GLIBCXX_ASSERTIONS=1 -fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error -ffile-prefix-map=../src=src -fPIC -MD -MQ src/libcmd/liblixcmd.so.p/repl.cc.o -MF src/libcmd/liblixcmd.so.p/repl.cc.o.d -o src/libcmd/liblixcmd.so.p/repl.cc.o -c ../src/libcmd/repl.cc
In file included from ../src/libcmd/repl.cc:1:
/nix/store/n1ddcimbjkxiiissmqqrh07ncj5xgaj4-editline-1.17.1-dev/include/editline.h:87:8: error: ‘FILE’ does not name a type
   87 | extern FILE       *rl_instream;  /* The stdio stream from which input is read. Defaults to stdin if NULL - Not supported yet! */
      |        ^~~~
/nix/store/n1ddcimbjkxiiissmqqrh07ncj5xgaj4-editline-1.17.1-dev/include/editline.h:1:1: note: ‘FILE’ is defined in header ‘<cstdio>’; did you forget to ‘#include <cstdio>’?
  +++ |+#include <cstdio>
    1 | /*
/nix/store/n1ddcimbjkxiiissmqqrh07ncj5xgaj4-editline-1.17.1-dev/include/editline.h:88:8: error: ‘FILE’ does not name a type
   88 | extern FILE       *rl_outstream; /* The stdio stream to which output is flushed. Defaults to stdout if NULL - Not supported yet! */
      |        ^~~~
/nix/store/n1ddcimbjkxiiissmqqrh07ncj5xgaj4-editline-1.17.1-dev/include/editline.h:88:8: note: ‘FILE’ is defined in header ‘<cstdio>’; did you forget to ‘#include <cstdio>’?
[203/467] Compiling C++ object src/nix/nix.p/develop.cc.o
ninja: build stopped: subcommand failed.

src/libcmd/repl.cc fails to compile under the default shell, but compiles ok under the native-clangStdenvPackages shell. not sure why this doesn’t happen in ci, which also uses the gcc-based shell. ## Steps To Reproduce 1. `nix develop` or `nix-shell` 2. `just clean` 3. `meson setup build --prefix="$PWD/outputs/out" $mesonFlags` (not `just setup`!) 4. `just install` ## `nix --version` output nix (Nix) 2.18.1 ## Additional context error below; adding `#include <cstdio>` to the top of the offending file fixes the problem for me. ``` [170/467] Compiling C++ object src/libcmd/liblixcmd.so.p/repl.cc.o FAILED: src/libcmd/liblixcmd.so.p/repl.cc.o g++ -Isrc/libcmd/liblixcmd.so.p -Isrc/libcmd -I../src/libcmd -Isrc/libutil -I../src/libutil -Isrc/libstore -I../src/libstore -Isrc/libexpr -I../src/libexpr -Isrc/libfetchers -I../src/libfetchers -Isrc/libmain -I../src/libmain -I/nix/store/givfqzc5vc4rqk64qghj7592z0msbl2c-boehm-gc-8.2.6-dev/include -I/nix/store/n1ddcimbjkxiiissmqqrh07ncj5xgaj4-editline-1.17.1-dev/include -I/nix/store/zij437icdrq28cdhq179rpy8xxanax4n-lowdown-1.1.0-dev/include -I/nix/store/mafwrbrcqq4i92lq5ypgq3mka0wwn9vp-nlohmann_json-3.11.3/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++2a -O2 -g -include config.h -Wno-deprecated-declarations -Wimplicit-fallthrough -Werror=switch -Werror=switch-enum -Wdeprecated-copy -Wignored-qualifiers -D_GLIBCXX_ASSERTIONS=1 -fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error -ffile-prefix-map=../src=src -fPIC -MD -MQ src/libcmd/liblixcmd.so.p/repl.cc.o -MF src/libcmd/liblixcmd.so.p/repl.cc.o.d -o src/libcmd/liblixcmd.so.p/repl.cc.o -c ../src/libcmd/repl.cc In file included from ../src/libcmd/repl.cc:1: /nix/store/n1ddcimbjkxiiissmqqrh07ncj5xgaj4-editline-1.17.1-dev/include/editline.h:87:8: error: ‘FILE’ does not name a type 87 | extern FILE *rl_instream; /* The stdio stream from which input is read. Defaults to stdin if NULL - Not supported yet! */ | ^~~~ /nix/store/n1ddcimbjkxiiissmqqrh07ncj5xgaj4-editline-1.17.1-dev/include/editline.h:1:1: note: ‘FILE’ is defined in header ‘<cstdio>’; did you forget to ‘#include <cstdio>’? +++ |+#include <cstdio> 1 | /* /nix/store/n1ddcimbjkxiiissmqqrh07ncj5xgaj4-editline-1.17.1-dev/include/editline.h:88:8: error: ‘FILE’ does not name a type 88 | extern FILE *rl_outstream; /* The stdio stream to which output is flushed. Defaults to stdout if NULL - Not supported yet! */ | ^~~~ /nix/store/n1ddcimbjkxiiissmqqrh07ncj5xgaj4-editline-1.17.1-dev/include/editline.h:88:8: note: ‘FILE’ is defined in header ‘<cstdio>’; did you forget to ‘#include <cstdio>’? [203/467] Compiling C++ object src/nix/nix.p/develop.cc.o ninja: build stopped: subcommand failed. ```

delan added the

bug

label

2024-06-23 11:36:54 +00:00

pennae commented

2024-06-23 14:27:58 +00:00

Owner

that's very strange. we've never seen this happen even with gcc shells. can you give more details on your setup?

(this looks like it's an editline bug more than a lix bug, perhaps there's some platform weirdness goin on that ci doesn't have?)

that's very strange. we've never seen this happen even with gcc shells. can you give more details on your setup? (this looks like it's an editline bug more than a lix bug, perhaps there's some platform weirdness goin on that ci doesn't have?)

jade commented

2024-06-23 16:01:31 +00:00

Owner

could this be covered over somehow by our pch implementation which is disabled in gcc dev shells by default? if so that's busted of course. not saying it is for sure but that's my shot in the dark.

could this be covered over somehow by our pch implementation which is disabled in gcc dev shells by default? if so that's *busted* of course. not saying it is for sure but that's my shot in the dark.

delan commented

2024-06-24 04:21:13 +00:00

Author

can you give more details on your setup?

i’m currently on nixos 23.11 (46397778ef1f7) with nix 2.18.1, but my original repro was incorrect, because i retconned it from the manual meson setup command we had in hacking.md to just setup… but it turns out that no longer passes the $mesonFlags generated by package.nix, and the error no longer occurs. i’ve updated the repro now.

could this be covered over somehow by our pch implementation which is disabled in gcc dev shells by default?

i think so! if i run meson setup with all of the $mesonFlags except -Denable-pch-std=false, the error goes away:

$ meson setup build --prefix="$PWD/outputs/out" -Dsandbox-shell=/nix/store/v35p0wxs6wkzs44wpndczh85qyw808am-busybox-static-x86_64-unknown-linux-musl-1.36.1/bin/busybox -Dinternal-api-docs=enabled -Denable-tests=true -Denable-docs=true

> can you give more details on your setup? i’m currently on nixos 23.11 ([46397778ef1f7](https://github.com/NixOS/nixpkgs/commit/46397778ef1f73414b03ed553a3368f0e7e33c2f)) with nix 2.18.1, but my original repro was incorrect, because i retconned it from the manual `meson setup` command we had [in hacking.md](https://git.lix.systems/lix-project/lix/src/commit/d477b34d1df3b471f8132525b0a008bbd03ddb6d/doc/manual/src/contributing/hacking.md#building-from-the-development-shell) to `just setup`… but it turns out that no longer passes the `$mesonFlags` generated by package.nix, and the error no longer occurs. i’ve updated the repro now. > could this be covered over somehow by our pch implementation which is disabled in gcc dev shells by default? i think so! if i run meson setup with all of the `$mesonFlags` except `-Denable-pch-std=false`, the error goes away: ``` $ meson setup build --prefix="$PWD/outputs/out" -Dsandbox-shell=/nix/store/v35p0wxs6wkzs44wpndczh85qyw808am-busybox-static-x86_64-unknown-linux-musl-1.36.1/bin/busybox -Dinternal-api-docs=enabled -Denable-tests=true -Denable-docs=true ```

delan changed title from ~~“‘FILE’ does not name a type” when building with gcc locally~~ to “‘FILE’ does not name a type” with gcc and -Denable-pch-std=false

2024-06-24 04:21:42 +00:00

delan commented

2024-06-24 04:26:56 +00:00

Author

fixed upstream in troglobit/editline#57, but their latest release is still 1.17.1 (and so is nixpkgs)

fixed upstream in [troglobit/editline#57](https://github.com/troglobit/editline/pull/57), but [their latest release](https://github.com/troglobit/editline/releases) is still 1.17.1 (and [so is nixpkgs](https://github.com/NixOS/nixpkgs/blob/f4d4d2ac340b7ede384bf0cf0a31ac174d64ce1b/pkgs/development/libraries/editline/default.nix))

delan referenced this issue

2024-06-24 04:36:33 +00:00

Build (also) with gcc devshell config in CI #412

lix-bot commented

2024-06-24 04:47:50 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/1512 ("Fix compile error under gcc with -Denable-pch-std=false")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/1512](https://gerrit.lix.systems/c/lix/+/1512) ("Fix compile error under gcc with -Denable-pch-std=false")