svn commit: r365889 - head/share/mk

Mark Johnston markj at freebsd.org
Fri Sep 18 21:23:36 UTC 2020


On Fri, Sep 18, 2020 at 02:10:13PM -0600, Ian Lepore wrote:
> On Fri, 2020-09-18 at 15:44 -0400, Mark Johnston wrote:
> > On Fri, Sep 18, 2020 at 01:27:23PM -0600, Ian Lepore wrote:
> > > On Fri, 2020-09-18 at 19:03 +0000, Mark Johnston wrote:
> > > > Author: markj
> > > > Date: Fri Sep 18 19:03:34 2020
> > > > New Revision: 365889
> > > > URL: https://svnweb.freebsd.org/changeset/base/365889
> > > > 
> > > > Log:
> > > >   Install library symlinks atomically.
> > > >   
> > > >   As we do for shared library binaries, pass -S to install(1) when
> > > >   installing symlinks.  Doing so helps avoid transient failures when
> > > >   libraries are being reinstalled, which seems to be the root cause
> > > > of
> > > >   spurious libgcc_s.so link failures during CI builds.
> > > >   
> > > 
> > > Actually, I believe this will just paper over the real problem, which
> > > is the fact that we're building and installing the same library
> > > multiple times during early build steps.  Nobody has yet been able to
> > > explain why we do that, and I haven't been able to figure out why by
> > > analyzing any differences in the generated files, but I'm not done
> > > trying.
> > 
> > Sorry, this deserved more commentary in the commit log.
> > 
> > Indeed, we install libgcc_s.so multiple times during buildworld.  As far
> > as I can see, it's intentional insofar as libgcc_s.so is listed in
> > multiple library targets: it's in both _prereq_libs and _startup_libs in
> > Makefile.inc1.  In particular, from scanning the log from a recent
> > instance of the failure, libgcc_s gets built once but installed multiple
> > times.
> > 
> > Why that's the case, or whether it's still necessary, is not clear to
> > me.  But adding -S seemed like a desirable change in general, so I went
> > forward with it.
> 
> Yeah, it has been listed in both prereq and startup list since it was
> first added by kan@ in 2007 or so.  I wonder if he remembers why (added
> to cc list)?

Digging a bit deeper, _prereq_libs are built with -DNO_PIC.  For
lib/libgcc_s this actually does nothing: libgcc_s/Makefile does not
define LIB so no static library gets built.  The problem seems to be
that libgcc_s gets built+installed for _startup_libs and then again as
part of _generic_libs.  Again, the constituent object files only get
built once, but the library binary and symlink get installed multiple
times into the worldtmp dir.  libc.so is not a symlink and was already
getting installed with -S, so despite also getting installed to worldtmp
multiple times it does not cause similar build failures.

So it seems that:
- libgcc_s can be dropped from _prereq_libs.
- _generic_libs revisits libraries that were built during earlier stages
  of the libraries target, i.e., the problem is not specific to
  libgcc_s.


More information about the svn-src-all mailing list