On 8/9/2017 12:35 PM, David Wolfskill wrote: > On Wed, Aug 09, 2017 at 12:22:20PM -0700, Bryan Drewery wrote: >>> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s >> ... >> >> This should fix it: >> https://people.freebsd.org/~bdrewery/patches/gcc_s-install-race.diff >> >> The problem has consistently been, from your reports, that gcc_s is >> being installed to WORLDTMP *while* something is trying to link to it. > > Yeah, that doesn't seem like something that's likely to have > deterministic results. > >> ... >>> --- lib/libc++__L --- >>> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s >>> >>> --- lib/libgcc_s__L ---^M >> ... >>> --- all_subdir_secure/lib/libcrypto/engines/libsureware ---^M >>> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s^M >> >> >> >> By default 'install' unlinks the file and then copies over the new file. >> Using PRECIOUSLIB we get the -S flag to install which is atomic in its >> installation. >> >> Note the patch is not what I will commit. At Isilon we changed our >> install to always use -S for library installation, but not to force schg >> on. I am considering making that change the default, to use -S for all >> libraries. > > From an (admittedly) naive perspective, it seems to me that enforcing > "atomic installation" for file system objects that are to be used > during the build (or install) makes more sense than firing and > hoping for the best. :-} > It also fixes some runtime crashes while concurrently running installworld to a live system. One that we ran into a lot was an NSS module being used for user lookup that another concurrent install would use while the module was being overwritten. It would see a bogus file during the install. >> -- >> Regards, >> Bryan Drewery >> > > Thanks! :-) > > Peace, > david > -- Regards, Bryan Drewery
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC