lib/libgcc_s fails on make all after make world succeeds

[Ian Lepore]

On Sun, 2019-05-19 at 23:54 +0200, Dimitry Andric wrote:
> On 19 May 2019, at 23:29, Julian H. Stacey <jhs at berklix.com> wrote:
> > 
> > Hi current at freebsd.org
> > On current src/ on 2 boxes, I have seen the same break for a week
> > or 2,
> > lib/libgcc_s fails on make all after make world succeeds,
> > Anyone else seen it or got ideas please ? Notes below the sample.
> > 
> > ===> lib/libgcc_s (all)
> > building shared library libgcc_s.so.1
> > cc  -nodefaultlibs -Wl,--version-
> > script=/usr/src/lib/libgcc_s/Version.map
> > -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o \
> > libgcc_s.so.1.full -Wl,-soname,libgcc_s.so.1
> 
> ...
> > -L/usr/obj/usr/src/amd64.amd64/lib/libc -lc \
> > ld: error: can't create dynamic relocation R_X86_64_32S \
> > against symbol: __je_sz_size2index_tab in readonly segment; \
> > recompile object files with -fPIC or pass '-Wl,-z,notext' \
> > to allow text relocations in the output
> > > > > defined in
> > > > > /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_sz.o)
> 
> It looks like for some reason, it chooses to link with libc.a instead
> of
> libc.so here.  Maybe your libc.so is not getting built at all,
> because
> of your environment?
> 
> Or maybe you are hitting some build race where libc.a is done, but
> libc.so is still being built, while at the same time, libgcc_s.so.1
> is
> being linked?
> 
> There are some difficult-to-reproduce races with libgcc_s, which are
> sometimes also hit by CI (I think Li-Wen mentioned them multiple
> times
> now).  But usually I would expect this to be "solved" by simply
> re-running buildworld, as the race window is very small, and you have
> to be quite lucky (or unlucky, depending on your point of view :) to
> hit
> it.
> 
> -Dimitry
> 

There is definitely something racy going on here.  I ran into 

  /usr/bin/ld: error: unable to find library -lgcc_s

Just a couple minutes into a build with an empty /usr/obj.  I killed
it, re-emptied /usr/obj, and started it again, and it didn't repeat the
problem.

Also, I noticed that libgcc_eh and libgcc_s seem to be getting built
twice in parallel here (this is about 2 minutes into a build of 12-
stable on a 12-stable system) with -j16, so all of these libs started
building together...

--------------------------------------------------------------
>>> stage 4.2: building libraries
--------------------------------------------------------------
===> lib/libcompiler_rt (obj,all,install)
===> gnu/lib/libssp/libssp_nonshared (obj,all,install)
===> lib/libgcc_eh (obj,all,install)
===> lib/libgcc_s (obj,all,install)
===> gnu/lib/csu (obj,all,install)
===> lib/libcompiler_rt (obj,all,install)
===> lib/csu (obj,all,install)
===> lib/libc_nonshared (obj,all,install)
===> lib/libc (obj,all,install)
===> lib/libgcc_eh (obj,all,install)
===> lib/csu/amd64 (all)
===> lib/csu/amd64 (install)
===> lib/libgcc_s (obj,all,install)
===> lib/libcxxrt (obj,all,install)

I've seen some bad things happen in the past when parallel jobs try to
build in the same directory.

-- Ian