Date: Tue, 08 May 2018 22:47:57 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 227918] [PATCH] remove exists check for CROSS_BINUTILS_PREFIX for external clang builds on secondary arches Message-ID: <bug-227918-227-j1D2a53ktf@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-227918-227@https.bugs.freebsd.org/bugzilla/> References: <bug-227918-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=3D227918 --- Comment #10 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Kenneth Salerno from comment #9) The question for -B and finding binutils files when there are multiple -B's= is: which -B path ends up being used? In the lib32 failure example, the content= of the two places are not equivalent if I understand right. It appeared that t= he one with the wrong content for lib32 was used for lib32 at the failure poin= t, if I understand right. My understanding of -B is that it is primarily for finding binutils files files but (for gcc/g++) also has -L and -isystem consequences when it points to a directory (that is found), allowing such other types of files to be bundled with the binutils files in the directory structure. Sorry to hear that -mcpu=3Dpower9 has problems of its own. Nothing I've tes= ted is newer than an old PowerMac G5 so-called "Quad Core", so from 2006 or so. --=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-227918-227-j1D2a53ktf>