GNU bug report logs -
#74194
compilation error: 'S_MAGIC_BCACHEFS' undeclared
Previous Next
Reported by: Bruno Haible <bruno <at> clisp.org>
Date: Sun, 3 Nov 2024 23:15:01 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74194 in the body.
You can then email your comments to 74194 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#74194
; Package
coreutils
.
(Sun, 03 Nov 2024 23:15:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Bruno Haible <bruno <at> clisp.org>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Sun, 03 Nov 2024 23:15:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
Building coreutils from source, today, I encountered this compilation error:
CC src/stat.o
../src/stat.c: In function 'human_fstype':
../src/stat.c:304:10: error: 'S_MAGIC_BCACHEFS' undeclared (first use in this function); did you mean 'S_MAGIC_TRACEFS'?
304 | case S_MAGIC_BCACHEFS: /* 0xCA451A4E local */
| ^~~~~~~~~~~~~~~~
| S_MAGIC_TRACEFS
../src/stat.c:304:10: note: each undeclared identifier is reported only once for each function it appears in
../src/stat.c:378:10: error: 'S_MAGIC_FUSE' undeclared (first use in this function); did you mean 'S_MAGIC_UFS'?
378 | case S_MAGIC_FUSE: /* 0x65735546 remote */
| ^~~~~~~~~~~~
| S_MAGIC_UFS
../src/stat.c:463:10: error: 'S_MAGIC_PID_FS' undeclared (first use in this function); did you mean 'S_MAGIC_PRL_FS'?
463 | case S_MAGIC_PID_FS: /* 0x50494446 local */
| ^~~~~~~~~~~~~~
| S_MAGIC_PRL_FS
make[2]: *** [Makefile:12874: src/stat.o] Error 1
I understand that the list of S_* macros is meant to be defined in src/fs.h,
which is meant to be autogenerated from src/stat.c.
History:
- In July I had apparently built coreutils in this checkout.
- Now I did a 'git pull', 'make -k distclean', then
built in a subdir 'build-64' (VPATH build).
The files that I have in this checkout at this point:
$ ls -l src/fs.h src/fs-is-local.h
-r--r--r-- 1 bruno bruno 4755 Jul 21 18:15 src/fs.h
-r--r--r-- 1 bruno bruno 5157 Jul 21 18:15 src/fs-is-local.h
$ ls -l src/stat.c
-rw-rw-r-- 1 bruno bruno 57973 Aug 14 14:38 src/stat.c
I tried this:
$ ./configure; make distclean
$ ls -l src/fs.h src/fs-is-local.h
-r--r--r-- 1 bruno bruno 4755 Jul 21 18:15 src/fs.h
-r--r--r-- 1 bruno bruno 5157 Jul 21 18:15 src/fs-is-local.h
This is normal: since src/fs.h and src/fs-is-local.h are contained in the
tarball, "make distclean" does not remove them.
Now I try a non-VPATH build:
$ ./configure; make
$ ls -l src/fs.h src/fs-is-local.h
-r--r--r-- 1 bruno bruno 4824 Nov 3 23:39 src/fs.h
-r--r--r-- 1 bruno bruno 5230 Nov 3 23:39 src/fs-is-local.h
This one succeeded, because src/fs.h was regenerated now.
The question thus is: Why was src/fs.h not regenerated in the VPATH build
earlier?
To reproduce this, I
- remove the 3 entries from src/fs.h,
- $ touch -d 'Jul 21 18:15' src/fs.h
- $ mkdir build-64; cd build-64; ../configure; make
What I see is:
1) build-64/src/fs.h has been created, and it contains the 3 entries.
2) In the compilation command, -Isrc occurs before -I../src.
gcc -I. -I.. -I./lib -Ilib -I../lib -Isrc -I../src -Wall -g -O2 -c -o src/stat.o ../src/stat.c
Use of option -E shows that despite this ordering of -I options,
../src/fs.h gets included. Apparently because it sits in the same
directory as ../src/stat.c.
So the bug is that fs.h was created in the build directory, not in
the source directory. The GNU Coding Standards
<https://www.gnu.org/prep/standards/html_node/Makefile-Basics.html>
say that the file should be generated in the source directory:
"GNU distributions usually contain some files which are not source
files—for example, Info files, and the output from Autoconf, Automake,
Bison or Flex. Since these files normally appear in the source
directory, they should always appear in the source directory,
not in the build directory. So Makefile rules to update them should
put the updated files in the source directory."
The attached patch fixes this GCS violation and thus fixes the compilation
error.
[0001-build-Regenerate-distributed-built-files-in-top_srcd.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#74194
; Package
coreutils
.
(Sun, 03 Nov 2024 23:54:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 74194 <at> debbugs.gnu.org (full text, mbox):
Thanks, I installed that patch.
bug closed, send any further explanations to
74194 <at> debbugs.gnu.org and Bruno Haible <bruno <at> clisp.org>
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Sun, 16 Feb 2025 06:59:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 16 Mar 2025 11:24:33 GMT)
Full text and
rfc822 format available.
This bug report was last modified 93 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.