Re: lib/libgcc_s fails on make all after make world succeeds
On Sun, 2019-05-19 at 23:54 +0200, Dimitry Andric wrote: > On 19 May 2019, at 23:29, Julian H. Stacey wrote: > > > > Hi curr...@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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lib/libgcc_s fails on make all after make world succeeds
> On 19 May 2019, at 23:29, Julian H. Stacey wrote:
> >
> > Hi curr...@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?
I've removed my environment variables & src.conf & make.conf,
& new test running.
> 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
Thanks Dimitry,
I'll re-read & consider but re. Race conditions, I hadnt thought
of that. I never use make [-j max_jobs] and ls -l ~jhs/.MAKE.JOBS
~root/.MAKE.JOBS # shows nothing
cd /usr/share/mk ; grep '\-j' *
bsd.cpu.mk:_CPUCFLAGS = -march=i686 -falign-functions=0 -falign-jumps=0
-falign-loops=0
bsd.info.mk:.if !empty(.MAKEFLAGS:M-j)
bsd.suffixes.mk:# XXX not -j safe
bsd.suffixes.mk:# XXX not -j safe
bsd.suffixes.mk:# XXX not -j safe
gendirdeps.mk: echo '# local dependencies - needed for -jN in clean tree'; \
meta.stage.mk:# for non-jobs mode the order here matters
cd /usr/src; grep '\-j' *
Makefile:# make universe -DMAKE_JUST_KERNELS JFLAG=-j${_jflag}
Makefile.inc1:echo "ncpu: $$(sysctl -n hw.ncpu)${.MAKE.JOBS:S/^/, make -j/}"
Makefile.inc1:.if ${.MAKEFLAGS:M-j}
Makefile.inc1:.error The buildenv target is incompatible with -j
Makefile.inc1:echo "ncpu: $$(sysctl -n hw.ncpu)${.MAKE.JOBS:S/^/, make -j/}"
Makefile.inc1: ${MAKE} -f Makefile.inc1 create-world-packages-jobs \
Makefile.inc1:.if make(create-world-packages-jobs)
Makefile.inc1:create-world-packages-jobs: .PHONY
Makefile.inc1:create-world-packages-jobs: create-world-package-${pkgname}
UPDATING: Avoid using make -j when upgrading. While generally safe,
there are
UPDATING: sometimes problems using -j to upgrade. If your upgrade fails
with
UPDATING: -j, please try again without -j. From time to time in the past
there
UPDATING: have been problems using -j with buildworld and/or
installworld. This
My 2 current hosts are old, a lot slower than I guess most developers use:
---
FreeBSD 13.0-CURRENT #14033: Sat May 11 18:48:02 CEST 2019
j...@blak.js.berklix.net:/usr/src/sys/amd64/compile/BLAK.small amd64
FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM
8.0.0)
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (3000.00-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x6fb Family=0x6 Model=0xf Stepping=11
Features=0xbfebfbff
Features2=0xe3fd
AMD Features=0x20100800
AMD Features2=0x1
VT-x: HLT,PAUSE
TSC: P-state invariant, performance statistics
real memory = 4294967296 (4096 MB)
avail memory = 4096159744 (3906 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
__stack_chk_init: WARNING: Initializing stack protection with non-random
cookies!
__stack_chk_init: WARNING: This severely limits the benefit of
-fstack-protector!
ioapic0: Changing APIC ID to 2
---
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #14033: Sat May 11 18:56:03 CEST 2019
j...@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small amd64
FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM
8.0.0)
VT(vga): resolution 640x480
module urndis already present!
module_register: cannot register pccard/wi from kernel; already loaded from
if_wi.ko
Module pccard/
Re: lib/libgcc_s fails on make all after make world succeeds
On 19 May 2019, at 23:29, Julian H. Stacey wrote: > > Hi curr...@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 signature.asc Description: Message signed with OpenPGP
lib/libgcc_s fails on make all after make world succeeds
Hi curr...@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 `NM='nm' NMFLAGS='' \ lorder absvdi2.pico absvsi2.pico absvti2.pico addvdi3.pico addvsi3.pico \ addvti3.pico apple_versioning.pico ashldi3.pico ashlti3.pico \ ashrdi3.pico ashrti3.pico clear_cache.pico clzdi2.pico clzsi2.pico \ clzti2.pico cmpdi2.pico cmpti2.pico ctzdi2.pico ctzsi2.pico ctzti2.pico \ divdc3.pico divdi3.pico divmoddi4.pico divmodsi4.pico divsc3.pico \ divsi3.pico divtc3.pico divti3.pico divxc3.pico enable_execute_stack.pico \ eprintf.pico extendhfsf2.pico ffsdi2.pico ffssi2.pico ffsti2.pico \ fixdfdi.pico fixdfti.pico fixsfdi.pico fixsfti.pico fixunsdfdi.pico \ fixunsdfsi.pico fixunsdfti.pico fixunssfdi.pico fixunssfsi.pico \ fixunssfti.pico fixunsxfdi.pico fixunsxfsi.pico fixunsxfti.pico \ fixxfdi.pico fixxfti.pico floatditf.pico floatsitf.pico floattidf.pico \ floattisf.pico floattixf.pico floatunditf.pico floatunsidf.pico \ floatunsisf.pico floatuntidf.pico floatuntisf.pico floatuntixf.pico \ gcc_personality_v0.pico int_util.pico lshrdi3.pico lshrti3.pico \ moddi3.pico modsi3.pico modti3.pico muldc3.pico muldi3.pico \ mulodi4.pico mulosi4.pico muloti4.pico mulsc3.pico multi3.pico \ mulvdi3.pico mulvsi3.pico mulvti3.pico multc3.pico mulxc3.pico \ negdf2.pico negdi2.pico negsf2.pico negti2.pico negvdi2.pico \ negvsi2.pico negvti2.pico paritydi2.pico paritysi2.pico parityti2.pico \ popcountdi2.pico popcountsi2.pico popcountti2.pico powidf2.pico \ powisf2.pico powitf2.pico powixf2.pico subvdi3.pico subvsi3.pico \ subvti3.pico trampoline_setup.pico truncdfhf2.pico truncsfhf2.pico \ ucmpdi2.pico ucmpti2.pico udivdi3.pico udivmoddi4.pico udivmodsi4.pico \ udivmodti4.pico udivsi3.pico udivti3.pico umoddi3.pico umodsi3.pico \ umodti3.pico floatdidf.pico floatdisf.pico floatdixf.pico \ floatundidf.pico floatundisf.pico floatundixf.pico cpu_model.pico \ adddf3.pico addsf3.pico divdf3.pico divsf3.pico extendsfdf2.pico \ fixdfsi.pico fixsfsi.pico floatsidf.pico floatsisf.pico muldf3.pico \ mulsf3.pico subdf3.pico subsf3.pico truncdfsf2.pico comparedf2.pico \ comparesf2.pico gcc_personality_v0.pico int_util.pico Unwind-EHABI.pico \ Unwind-sjlj.pico UnwindLevel1-gcc-ext.pico UnwindLevel1.pico \ UnwindRegistersRestore.pico UnwindRegistersSave.pico libunwind.pico \ s_fabs.pico s_fabsf.pico s_fabsl.pico s_fmax.pico s_fmaxf.pico \ s_logb.pico s_logbf.pico s_scalbn.pico s_scalbnf.pico s_fmaxl.pico \ s_logbl.pico s_scalbnl.pico | tsort -q` \ -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) >>> referenced by sz.h:0 \ (/usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:0) >>> jemalloc_jemalloc.o:(a0ialloc) in archive \ /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: error: can't create dynamic relocation R_X86_64_32 against local symbol \ 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_jemalloc.o) >>> referenced by mutex.h:144 \ (/usr/src/contrib/jemalloc/include/jemalloc/internal/mutex.h:144) >>> jemalloc_jemalloc.o:(a0ialloc) in archive \ /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a - First i thought it was my custom src/ but generic src/ breaks too. Then I did: /etc/src.conf Removed /etc/make.conf Removed env varsStripped to just PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin TERM=xterm TERMPATH=/etc/termcap:/usr/share/misc/termcap A new make buildworld is running on virgin generic src/ inside a script with cat .svn_revision 347964 cat .ctm_status src-cur 14046 That will take a while before I can report. Meantime I also have a 2nd box I can experiment on if people have ideas ? cat .svn_revision 347422 cat .ctm_status src-cur 14033 Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. ___ freebsd-current@f
