GNU bug report logs - #74194
compilation error: 'S_MAGIC_BCACHEFS' undeclared

Previous Next

Package: coreutils;

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-coreutils <at> gnu.org
Subject: compilation error: 'S_MAGIC_BCACHEFS' undeclared
Date: Mon, 04 Nov 2024 00:14:16 +0100
[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):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>, 74194 <at> debbugs.gnu.org
Subject: Re: bug#74194: compilation error: 'S_MAGIC_BCACHEFS' undeclared
Date: Sun, 3 Nov 2024 15:53:12 -0800
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.