On 2016-Apr-2, at 3:59 PM, Mark Millard <markmi at dsl-only.net> wrote: > [My testing for the likes of the below does not yet extend outside powerpc64 contexts.] > > For the likes of self-hosted powerpc64-xtoolchain-gcc/powerpc64-gcc use with, say, gcc49 materials as the so-called "host" compiler tools I have not yet found a way around using the workaround: > >> # ls -l /usr/lib/libstdc++.* >> lrwxr-xr-x 1 root wheel 17 Feb 23 00:09 /usr/lib/libstdc++.a -> /usr/lib/libc++.a >> lrwxr-xr-x 1 root wheel 18 Feb 23 00:09 /usr/lib/libstdc++.so -> /usr/lib/libc++.so > > > > But I appear to now have a src.conf (or a family of them) that avoids needing workarounds in /usr/local/include and /usr/local/lib for filename conflicts. This is based on CC/CXX ("HOST") and XCC/XCXX ("CROSS") in src.conf being the likes of: > > "HOST" (CC/CXX): >> CC=env C_INCLUDE_PATH=/usr/include /usr/local/bin/gcc49 -L/usr/lib >> CXX=env C_INCLUDE_PATH=/usr/include CPLUS_INCLUDE_PATH=/usr/include/c++/v1 /usr/local/bin/g++49 -std=c++11 -nostdinc++ -L/usr/lib > > and. . . > > "CROSS" (XCC/XCXX): >> TO_TYPE=powerpc64 >> TOOLS_TO_TYPE=${TO_TYPE} >> . . . >> VERSION_CONTEXT=11.0 >> . . . >> XCC=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gcc >> XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g++ > > In other words: CROSS use is already handled for /usr/local/. . . just given the compiler paths but some special src.conf adjustments beyond compiler paths were needed for HOST. > > So far it appears that gcc49 materials can be used in "CROSS" and/or powerpc64-gcc materials can be used in "HOST" via just appropriate compiler-path editing. (I have jumped to testing -r297514 but am still doing various build tests. So this aspect is subject to updates.) It appears to be possible to use just one compiler/tool family --but in the 2 different ways-- instead of using a mix of 2 compiler/tool families. > > Historically I've not gotten gcc variants to make a working lib32 for powerpc64 and I've yet to retest this: So no claims about the lib32 status are implied here. (The problem was code in crtbeginS that arbitrarily used R30 in a way that the context was not set up for and so crtbeginS code was dereferencing arbitrary addresses.) I probably knew this someplace in the back of my head but gcc49 does not handle -fformat-extensions (quoting the script log): > --- accf_data.o --- > env /usr/local/bin/gcc49 -isystem /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib --sysroot=/usr/obj/xtoolchain/powerpc.powerp > c64/usr/src/tmp -B/usr/local/powerpc64-portbld-freebsd11.0/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG/opt_global.h -I. -I/usr/src/sys -fno-common -g -mlongcall -fno-omit-frame-pointer -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG -MD -MF.depend.accf_data.o -MTaccf_data.o -mno-altivec -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=inline -Wno-error=enum-compare -Wno-error=unused-but-set-variable -Wno-error=aggressive-loop-optimizations -Wno-error=maybe-uninitialized -Wno-error=array-bounds -Wno-error=address -Wno-error=cast-qual -Wno-error=sequence-point -Wno-error=attributes -Wno-error=strict-overflow -Wno-error=overflow -v -finline-limit=15000 -fms-extensions --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -mcall-aixdesc -std=iso9899:1999 -c /usr/src/sys/modules/accf_data/../../netinet/accf_data.c -o accf_data.o > Using built-in specs. > COLLECT_GCC=/usr/local/bin/gcc49 > gcc49: error: unrecognized command line option '-fformat-extensions' > Target: powerpc64-portbld-freebsd11.0 > Configured with: ./../gcc-4.9-20160210/configure --disable-multilib --disable-bootstrap --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --disable-libgcj --enable-languages=c,c++,objc,fortran --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc49 --build=powerpc64-portbld-freebsd11.0 > Thread model: posix > gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection) > *** [accf_data.o] Error code 1 So my > it appears that gcc49 materials can be used in "CROSS" is just false for gcc49, gcc5, and the like. I had hoped such would work with TARGET_ARCH=powerpc because there is no powerpc-gcc port predefined and clang 3.8.0 is still insufficient for this context. === Mark Millard markmi at dsl-only.net On 2016-Apr-1, at 4:35 PM, Mark Millard <markmi at dsl-only.net> wrote: > > [Just a top-post showing what powerpc64-xtoolchain-gcc/powerpc64-gcc has for the default include search places:] > > powerpc64-xtoolchain-gcc/powerpc64-gcc also looks in /usr/local/include before /usr/include : see below. > >> # portmaster --list-origins >> . . . >> devel/powerpc64-xtoolchain-gcc >> . . . >> >> # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc --version >> powerpc64-portbld-freebsd11.0-gcc (FreeBSD Ports Collection for powerpc64) 5.3.0 >> Copyright (C) 2015 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> # echo '' |/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -v -x c++ - -o /dev/null >> . . . >> ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0" >> ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0/powerpc64-portbld-freebsd11.0" >> ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0/backward" >> ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerpc64-portbld-freebsd11.0/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include >> /usr/local/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed >> /usr/include >> End of search list. >> . . . > > > === > Mark Millard > markmi at dsl-only.net > On 2016-Apr-1, at 7:25 AM, Warner Losh <imp at bsdimp.com> wrote: > > > > On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric <dim_at_freebsd.org> wrote: > On 01 Apr 2016, at 00:44, Warner Losh <imp_at_bsdimp.com> wrote: >> >>> On Mar 31, 2016, at 4:34 PM, Bryan Drewery <bdrewery_at_freebsd.org> 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. > > WarnerReceived on Sun Apr 03 2016 - 05:02:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:03 UTC