Date: Tue, 30 Jul 2019 20:46:59 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 233769] Possible build race: ld: error: unable to find library -lgcc_s Message-ID: <bug-233769-227-nS6koyuUln@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-233769-227@https.bugs.freebsd.org/bugzilla/> References: <bug-233769-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233769 --- Comment #11 from Bryan Drewery <bdrewery@FreeBSD.org> --- Just passing through -S in tools/install.sh is not enough. 1. Maybe this tool is expected to work on Linux where -S does something different. 2. The symlink/hardlink support call ln(1) which are is atomic for symlinks= . It does unlink(2) followed by symlink(2). Reworking the build to avoid double installs here is possible but would be = more hackish IMO. We would need to muck with the SUBDIR lists for gnu/lib to fix this specific case so that it only installs during the right phase of buildworld (like we do for llvm kinda). But that's JUST gnu/lib. The same problem could come up for other libraries eventually given enough install-to-worldtmp threads. META_MODE+filemon may eventually learn how to avoid the double installs but= it has not yet. DIRDEPS_BUILD learned how. It's not hard to implement just ris= ky and needs time devoted to testing. Of course this then requires filemon whi= ch isn't the solution some people want to hear. The double install/relink issue isn't causing a problem beyond this race wh= ich is why I think we just need to make the install atomic rather than wack-a-m= ole with SUBDIR hacks. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233769-227-nS6koyuUln>