This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v4] Fix Linux fcntl OFD locks for non-LFS architectures (BZ#20251)


On Tue, 26 Jun 2018, Adhemerval Zanella wrote:

> On 26/06/2018 18:43, Joseph Myers wrote:
> > On Tue, 26 Jun 2018, Adhemerval Zanella wrote:
> > 
> >> I will push it shortly.
> > 
> > The pushed commit includes a dubious change to 
> > sysdeps/mach/hurd/bits/errno.h.
> > 
> > Maybe parts of that change are correct in that they are in fact the 
> > results of regenerating that file, but if regenerating that file involves 
> > inserting a line saying 
> > "/home/azanella/Projects/glibc/build/i686-gnu/errnos.d", there is clearly 
> > a bug in the generation process; generated checked-in files should never 
> > depend on individual build paths like that.
> > 
> 
> This is clearly a mistake from my part, I will revert this change.  The
> i686-gnu build seems to change this source file for some reason.

The files in the source tree that may have makefile dependencies on other 
files in the source tree and so get regenerated during the build include 
at least configure and configure fragments, some preconfigure fragments, 
gperf-generated *-kw.h, INSTALL, sysdeps/gnu/errlist.c, 
sysdeps/mach/hurd/bits/errno.h, posix/testcases.h, posix/ptestcases.h, 
locale/C-translit.h, sysdeps/sparc/sparc32/{sdiv,udiv,rem,urem}.S.  
(There may be others I've missed.  Files such as po/libc.pot, with 
makefile dependencies but which don't get referenced during a normal 
build, aren't relevant for this purpose.)

Eventually it would be good for build-many-glibcs.py to touch all such 
files in fix_glibc_timestamps to ensure that no regeneration in the source 
tree takes place accidentally during a build (and given verification that 
this makes a read-only source tree with any timestamp ordering work for 
all supported configurations, build-many-glibcs.py could then stop copying 
the glibc source tree at all).  Of course that doesn't help so much when 
not using build-many-glibcs.py; maybe we should have an equivalent of 
GCC's contrib/gcc_update --touch that people could run during checkout 
(and then build-many-glibcs.py would just use that).

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]