Re: lib/libgcc_s fails on make all after make world succeeds

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