On Saturday, March 17, 2018 1:37:24 AM CET Bruno Haible wrote: > Kamil Dudka wrote: > > parse-datetime.c generated out of parse-datetime.y ends up in the source > > directory, instead of the build directory as one would expect. This was > > introduced by the following commit: > > > > http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6c680191 > > > > Neither the comment, nor the change log entry explains why it is desired. > > For gnulib, you sometimes need to look up in the mailing list archive to get > the complete discussion.
Ideally yes. But the commit contains no reference to that discussion and the discussion contains no reference to that commit. Are you expecting people to look it up by date and/or by names of the people who suggested it? > In this case, the essential mail was > https://lists.gnu.org/archive/html/bug-gnulib/2010-04/msg00488.html > which referenced > https://lists.gnu.org/archive/html/bug-gnulib/2009-05/msg00061.html > > > As far as I know, the build should work even if the source directory is > > on a read-only file system. > > ... *only* if the source directory contains a complete, unmodified tarballs > contents. But when a .y.c rule needs to be run, you must have modified the > .y file, or the timestamps are wrong. You can't build off a read-only source > directory in this case. OK. I did not realise that the distribution tarball already contained bison's output file. In fact, bison does not run during the build of coreutils in Fedora. But even if I touch lib/parse-datetime.y to force bison to run, it has no effect on the missing debuginfo. > The most important use-case of Makefiles are the developer's working > directory. The use-case with a read-only source directory is only a corner > case; in case of conflict with the important use-case, it's the important > use-case which wins. > > Moreover, this oddity seems to cause problems to the debug info extractor > > used by rpmbuild in Fedora: > > > > https://bugzilla.redhat.com/1555079 > > I don't know how the debug info extractor works, Nor do I. > but you make it sound like > it would ignore source files in $srcdir - which would not be right. Other source files are captured just fine. The only problem is that it expects parse-datetime.{c,y} to be in build directories, instead of the source directory. It could be confused by the #line directives that bison produces. A full build log is available at: https://kojipkgs.fedoraproject.org//packages/coreutils/8.29/6.fc29/data/logs/x86_64/build.log The related part looks like this: + /usr/lib/rpm/find-debuginfo.sh -j6 --strict-build-id -m -i --build-id-seed 8.29-6.fc29 --unique-debug-suffix -8.29-6.fc29.x86_64 --unique-debug-src-base coreutils-8.29-6.fc29.x86_64 --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 -S debugsourcefiles.list /builddir/build/BUILD/coreutils-8.29 extracting debug info from /builddir/build/BUILDROOT/coreutils-8.29-6.fc29.x86_64/usr/sbin/chroot extracting debug info from /builddir/build/BUILDROOT/coreutils-8.29-6.fc29.x86_64/usr/bin/coreutils.single extracting debug info from /builddir/build/BUILDROOT/coreutils-8.29-6.fc29.x86_64/usr/libexec/coreutils/libstdbuf.so extracting debug info from /builddir/build/BUILDROOT/coreutils-8.29-6.fc29.x86_64/usr/bin/stty extracting debug info from /builddir/build/BUILDROOT/coreutils-8.29-6.fc29.x86_64/usr/libexec/coreutils/libstdbuf.so.single [...] extracting debug info from /builddir/build/BUILDROOT/coreutils-8.29-6.fc29.x86_64/usr/bin/expand /usr/lib/rpm/sepdebugcrcfix: Updated 107 CRC32s, 0 CRC32s did match. cpio: separate/parse-datetime.c: Cannot stat: No such file or directory cpio: separate/parse-datetime.y: Cannot stat: No such file or directory cpio: single/parse-datetime.c: Cannot stat: No such file or directory cpio: single/parse-datetime.y: Cannot stat: No such file or directory 10371 blocks If I hard-link parse-datetime.{c,y} from the source directory to the build directories before the debug info extractor is started, it seems to work as expected. Those files are included in the debuginfo package and gdb is able to find them when the debuginfo package is installed. Kamil > Bruno
