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. :-} > -- > Regards, > Bryan Drewery > Thanks! :-) Peace, david -- David H. Wolfskill david_at_catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC