Re: toolchain target
Dimitry Andric wrote: > Hmm, is this still not fixed? This was broken by Simon's large > "meta-mode" commit r284345. but I would assume Baptiste's fixes after > that might have fixed it. I can't test this myself at the moment, due to > ENOTIME... I think https://reviews.freebsd.org/D2860 will fix this. It puts include of make.conf etc back where they were and introduces new early include. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: toolchain target
Andriy Gapon wrote: > > do you have anything interesting in /etc/make.conf? > > Thank you for the hint -- __MAKE_CONF=/dev/null SRC_CONF=/dev/null fix the > problem. > > Now I am trying to figure out what the problem is. The problem will be that I shifted the include of make.conf and etc to earlier in sys.mk so that they can provide pointer to external toolchains. > > My make.conf: > .if defined(CC) > .if ${CC} == gcc which will break all this - see the UPDATING entry. > CPUTYPE?=k8-sse3 > .else > CPUTYPE?=amdfam10 > .endif > .endif > CFLAGS+= -O2 -fno-strict-aliasing -pipe > CFLAGS+= -fno-omit-frame-pointer > CXXFLAGS+= -O2 -fno-strict-aliasing -pipe The root problem is that a global file like /etc/make.conf is a very fragile concept - makes it almost impossible to evolve the the build. Especially if you put anything in there more complex that setting global knobs. Any use of += etc, makes it sentitive to the point of inclusion. It is useful to include local.sys.mk (hence src.sys.mk) very early. So that they can do CC?= blah etc. before sys.mk does But the current semantic is that make.conf should be included first which means it needs to be included early .. which breaks everyone who has "interesting" stuff there. > And src.conf: > WITH_DEBUG_FILES=yes > WITH_CTF=yes What is perhaps really needed is yet another include that can happen early and another later during sys.mk processing We could then move include of make.conf back Will investigate... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: toolchain target
On 18/06/2015 09:22, Andriy Gapon wrote: > My make.conf: > .if defined(CC) > .if ${CC} == gcc > CPUTYPE?=k8-sse3 > .else > CPUTYPE?=amdfam10 > .endif > .endif > CFLAGS+= -O2 -fno-strict-aliasing -pipe > CFLAGS+= -fno-omit-frame-pointer > CXXFLAGS+= -O2 -fno-strict-aliasing -pipe > [snip] > Looks like my rather innocent manipulations of CFLAGS could be causing the > problem. > Without my make.conf: > mkdep -f .depend -a > -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/include > -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include > -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support > -I. > -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" > -I/usr/obj/usr/devel/svn2/head/tmp/legacy/usr/include -std=c++11 > -stdlib=libc++ > /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp > ... > > With my make.conf: > mkdep -f .depend -a -std=c++11 -stdlib=libc++ > /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp > ... > > All the preprocessor flags (-I, -D) are gone. > Or rather it's CXXFLAGS that is affected. Looks like now in my environment the initial value of CXXFLAGS is set by make.conf instead of being derived from CFLAGS in mk/sys.mk. This breaks expectation of many makefiles that flags added to CFLAGS will also be appear in CXXFLAGS. Apparently, this problem is documented in UPDATING 20150616, but it does not cover all possible variables affected by the change... So, I guess that I could just remove CXXFLAGS from my make.conf, because it is quite redundant, but in some cases people may still want to set it. Or I could copy the CXXFLAGS assignment line from mk/sys.mk to make.conf, but that's a slippery slope towards having to copy all of mk/sys.mk to make.conf. Or maybe the historic behavior could be restored and whatever prompted the change could be done in a different fashion? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: toolchain target
On 18 Jun 2015, at 08:24, Garrett Cooper wrote: > > On Jun 17, 2015, at 23:22, Andriy Gapon wrote: ... >> Looks like my rather innocent manipulations of CFLAGS could be causing the >> problem. >> Without my make.conf: >> mkdep -f .depend -a >> -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/include >> -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include >> -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support >> -I. >> -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include >> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS >> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" >> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" >> -I/usr/obj/usr/devel/svn2/head/tmp/legacy/usr/include -std=c++11 >> -stdlib=libc++ >> /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp >> ... >> >> With my make.conf: >> mkdep -f .depend -a -std=c++11 -stdlib=libc++ >> /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp >> ... >> >> All the preprocessor flags (-I, -D) are gone. > > Oh really…? This is going to break a _lot_ of peoples’ custom make.confs :(... Hmm, is this still not fixed? This was broken by Simon's large "meta-mode" commit r284345. but I would assume Baptiste's fixes after that might have fixed it. I can't test this myself at the moment, due to ENOTIME... -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: toolchain target
On Jun 17, 2015, at 23:22, Andriy Gapon wrote: > On 18/06/2015 02:26, Simon J. Gerraty wrote: >> Andriy Gapon wrote: Seems like there is some problem with 'toolchain' target in the latest head. Output of running `make toolchain TARGET=i386` on amd64 system can be found here: http://dpaste.com/3RD3C4V >>> >>> AFAICS, it still worked as of r283188. >> >> There has been a clang update since then. >> >> I just did make -j12 toolchain TARGET=i386 ok >> do you have anything interesting in /etc/make.conf? > > Thank you for the hint -- __MAKE_CONF=/dev/null SRC_CONF=/dev/null fix the > problem. > > Now I am trying to figure out what the problem is. > > My make.conf: > .if defined(CC) > .if ${CC} == gcc > CPUTYPE?=k8-sse3 > .else > CPUTYPE?=amdfam10 > .endif > .endif > CFLAGS+= -O2 -fno-strict-aliasing -pipe > CFLAGS+= -fno-omit-frame-pointer > CXXFLAGS+= -O2 -fno-strict-aliasing -pipe > > And src.conf: > WITH_DEBUG_FILES=yes > WITH_CTF=yes > WITHOUT_INET6=YES > WITHOUT_PROFILE=YES > WITHOUT_FORTRAN=YES > WITHOUT_I4B=YES > WITHOUT_IPFILTER=YES > WITHOUT_ATM=YES > WITHOUT_IPX=YES > WITHOUT_LPR=yes > WITHOUT_ZONEINFO=yes > MALLOC_PRODUCTION=yes > LOADER_BZIP2_SUPPORT=yes > LOADER_FIREWIRE_SUPPORT=yes > > > Looks like my rather innocent manipulations of CFLAGS could be causing the > problem. > Without my make.conf: > mkdep -f .depend -a > -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/include > -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include > -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support > -I. > -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" > -I/usr/obj/usr/devel/svn2/head/tmp/legacy/usr/include -std=c++11 > -stdlib=libc++ > /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp > ... > > With my make.conf: > mkdep -f .depend -a -std=c++11 -stdlib=libc++ > /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp > ... > > All the preprocessor flags (-I, -D) are gone. Oh really…? This is going to break a _lot_ of peoples’ custom make.confs :(... signature.asc Description: Message signed with OpenPGP using GPGMail
Re: toolchain target
On 18/06/2015 02:26, Simon J. Gerraty wrote: > Andriy Gapon wrote: >>> Seems like there is some problem with 'toolchain' target in the latest head. >>> Output of running `make toolchain TARGET=i386` on amd64 system can be found >>> here: http://dpaste.com/3RD3C4V >>> >> >> AFAICS, it still worked as of r283188. > > There has been a clang update since then. > > I just did make -j12 toolchain TARGET=i386 ok > do you have anything interesting in /etc/make.conf? Thank you for the hint -- __MAKE_CONF=/dev/null SRC_CONF=/dev/null fix the problem. Now I am trying to figure out what the problem is. My make.conf: .if defined(CC) .if ${CC} == gcc CPUTYPE?=k8-sse3 .else CPUTYPE?=amdfam10 .endif .endif CFLAGS+= -O2 -fno-strict-aliasing -pipe CFLAGS+= -fno-omit-frame-pointer CXXFLAGS+= -O2 -fno-strict-aliasing -pipe And src.conf: WITH_DEBUG_FILES=yes WITH_CTF=yes WITHOUT_INET6=YES WITHOUT_PROFILE=YES WITHOUT_FORTRAN=YES WITHOUT_I4B=YES WITHOUT_IPFILTER=YES WITHOUT_ATM=YES WITHOUT_IPX=YES WITHOUT_LPR=yes WITHOUT_ZONEINFO=yes MALLOC_PRODUCTION=yes LOADER_BZIP2_SUPPORT=yes LOADER_FIREWIRE_SUPPORT=yes Looks like my rather innocent manipulations of CFLAGS could be causing the problem. Without my make.conf: mkdep -f .depend -a -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -I/usr/obj/usr/devel/svn2/head/tmp/legacy/usr/include -std=c++11 -stdlib=libc++ /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp ... With my make.conf: mkdep -f .depend -a -std=c++11 -stdlib=libc++ /usr/devel/svn2/head/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp ... All the preprocessor flags (-I, -D) are gone. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: toolchain target
Andriy Gapon wrote: > > Seems like there is some problem with 'toolchain' target in the latest head. > > Output of running `make toolchain TARGET=i386` on amd64 system can be found > > here: http://dpaste.com/3RD3C4V > > > > AFAICS, it still worked as of r283188. There has been a clang update since then. I just did make -j12 toolchain TARGET=i386 ok do you have anything interesting in /etc/make.conf? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: toolchain target
On 17/06/2015 23:42, Andriy Gapon wrote: > > Seems like there is some problem with 'toolchain' target in the latest head. > Output of running `make toolchain TARGET=i386` on amd64 system can be found > here: http://dpaste.com/3RD3C4V > AFAICS, it still worked as of r283188. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"