[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: parse-datetime.c generated in the source (instead of build) director

From: Kamil Dudka
Subject: Re: parse-datetime.c generated in the source (instead of build) directory
Date: Mon, 19 Mar 2018 18:57:54 +0100

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

A full build log is available at:

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 
extracting debug info from 
extracting debug info from 
extracting debug info from 
extracting debug info from 
extracting debug info from 
extracting debug info from 
/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.


> Bruno

reply via email to

[Prev in Thread] Current Thread [Next in Thread]