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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233769 --- 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 risky and needs time devoted to testing. Of course this then requires filemon which isn't the solution some people want to hear. The double install/relink issue isn't causing a problem beyond this race which is why I think we just need to make the install atomic rather than wack-a-mole with SUBDIR hacks. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233769-227-nS6koyuUln>