Re: 11.0 -r297369: _el_fn_sh_complete missing in buildworld; /usr/obj/. . ./lib/libedit/ has no filecomplete.*
On 3/29/16 6:35 PM, Mark Millard wrote: > Going from 11.0-CURRENT -r297048 to -r297369: buildworld after svnlite update: > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/. . . ends up with no > filecomplete.* > but the build tries to use what would be some of its contents > (_el_fn_sh_complete) > > The details. . . FYI this was fixed in r297435. -- Regards, Bryan Drewery ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andricwrote: > On 01 Apr 2016, at 00:44, Warner Losh wrote: > > > >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery > wrote: > >> I didn't realize the ports compiler was defaulting /usr/local/include > >> into the search path now. It does not have /usr/local/lib in the > >> default library path as far as I can tell. It's also broken for its > >> -rpath (noted in its pkg-message). So having a default > >> /usr/local/include path seems odd. > > > > It has for a while now. It’s one of the maddening inconsistencies that > abound in this > > area. I took a poll a while ago and there seemed to be widespread > support for adding > > it to the base compiler. > > This was the main reason /usr/local/include was *not* included in the > base compiler, otherwise it would unpredictably pick up headers in > /usr/local/include during builds. You can never know which conflicting > headers a certain user has installed in /usr/local/include... :) That's why it shouldn't be *FIRST*, not why it shouldn't be there at all. >> Adding -isystem /usr/include to fix this is probably possible but > >> there's a risk someone will remove it as redundant. In this case I wish > >> /usr/include was first but I'm not sure what impact that would have on > >> consumers expecting /usr/local/include (and /usr/local/lib) overrides to > >> work, though they would need to pass a -L /usr/local/lib anyhow and > >> would likely be passing -I /usr/local/lib too. > > > > /usr/include should be first. But it isn’t. That’s another inconsistency > that was found > > when we looked at /usr/local stuff. Someone recently added > /usr/local/bin to the path, > > if I recall correctly. > > Isn't that a bit of a bikeshed? I guess some people would just as well > prefer /usr/local/include to be first, just like some people prefer > /usr/local/bin before /usr/bin in their PATH. > Sigh. No. /usr/local is moving into many different things in the base and ports. We should do it in a consistent way. What we have now is not consistent and somewhat brittle. > In any case, if such paths are added to external compilers, we better > make sure almost everything in buildworld uses -nostdinc, and specifying > exactly the include directories we need, and no others. Cumbersome, but > maybe for a good cause. That's the non-brittle solution here. An over-reliance on defaults makes it difficult to ensure other compilers will work, especially ones we don't tightly control the defaults for. Warner ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
On 01 Apr 2016, at 00:44, Warner Loshwrote: > >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery wrote: >> I didn't realize the ports compiler was defaulting /usr/local/include >> into the search path now. It does not have /usr/local/lib in the >> default library path as far as I can tell. It's also broken for its >> -rpath (noted in its pkg-message). So having a default >> /usr/local/include path seems odd. > > It has for a while now. It’s one of the maddening inconsistencies that abound > in this > area. I took a poll a while ago and there seemed to be widespread support for > adding > it to the base compiler. This was the main reason /usr/local/include was *not* included in the base compiler, otherwise it would unpredictably pick up headers in /usr/local/include during builds. You can never know which conflicting headers a certain user has installed in /usr/local/include... :) >> Adding -isystem /usr/include to fix this is probably possible but >> there's a risk someone will remove it as redundant. In this case I wish >> /usr/include was first but I'm not sure what impact that would have on >> consumers expecting /usr/local/include (and /usr/local/lib) overrides to >> work, though they would need to pass a -L /usr/local/lib anyhow and >> would likely be passing -I /usr/local/lib too. > > /usr/include should be first. But it isn’t. That’s another inconsistency that > was found > when we looked at /usr/local stuff. Someone recently added /usr/local/bin to > the path, > if I recall correctly. Isn't that a bit of a bikeshed? I guess some people would just as well prefer /usr/local/include to be first, just like some people prefer /usr/local/bin before /usr/bin in their PATH. In any case, if such paths are added to external compilers, we better make sure almost everything in buildworld uses -nostdinc, and specifying exactly the include directories we need, and no others. Cumbersome, but maybe for a good cause. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail