Re: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
Bryan Drewery wrote: > I think the problem here is the use of -m for SUB_MAKE in /Makefile. > Specifying -m share/mk causes all of the issues I've seen (expected > including of /etc/src.conf), while not using -m does not include > /etc/src.conf even though the build is being done in a src dir. Sorry, the behavior here will vary depending on when /usr/bin/make was built. IIRC when I first put bmake in I made it use .../share/mk by default (during the original discussion at BSDCan about 4 years ago ensuring that "correct" src/share/mk used by default was stated as a goal - without need for env settings). Of course .../share/mk breaks POLA for those who expect /usr/share/mk to always be used, so that was backed out, but was more recently put back in ;-) Sooo unless you explicitly use -m or set MAKESYSPATH, we cannot say for sure whether you will get /usr/share/mk/sys.mk or $SRCTOP/share/mk/sys.mk when you run 'make' in a subdir, and the result wrt to src.conf depends on using $SRCTOP/share/mk/sys.mk ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
Bryan Drewery wrote: > 1: subdir make > src.conf: STRIP= > rescue/rescue% make all > -> make -f OBJDIR/rescue.mk > > STRIP= is not passed down into rescue.mk, resulting in 'strip rescue'. unless src.conf does .export STRIP, or submake reads src.conf for itself this isn't surprising. The result probably depends on whether /usr/share/mk or src/share/mk is used. > > 2. subdir make STRIP env override > rescue/rescue% make all STRIP= Setting STRIP= (or anything) like that causes vastly different behavior compared to env STRIP= make or setting STRIP= in a makefile (eg src.conf) When you do 'make STRIP=' the variable is handled differently, it is put into a special context CMD which has higest priority and is explicityl passed on to submakes via MAKEFLAGS. The goal is to treat the setting as immutable (to the extent possible) as required by posix. > STRIP= is passed down resulting in ' rescue'. > > 3: buildworld > STRIP= from src.conf is passed down, resulting in ' rescue'. buildworld tries to ensure that the tree's share/mk is used so src.sys.mk is used and /etc/src.conf likely to be read. ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On 7/28/15 2:58 PM, Bryan Drewery wrote:
> On 7/28/15 2:26 PM, Bryan Drewery wrote:
>> On 6/21/15 2:29 PM, Simon J. Gerraty wrote:
>>> Garrett Cooper wrote:
> Am I the only one who fails to build recent base/head (r284673) on
> pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs.
...
> CC=clang
> CXX=clang++
> CPP=clang-cpp
>>>
You need to remove these lines. They shouldn’t have been set before or
after the commits from projects/bmake .
>>>
>>> Note: both the grn's specified above are than r284598 which put the
>>> inlcude of make.conf back to its original spot, so the meta mode related
>>> changes should not be relevant.
>>>
>>
>> Regarding including /etc/make.conf, something is inconsistent with
>> buildworld vs subdir make.
>
> Correction: I have STRIP= in /etc/src.conf. The inclusion of it seems
> inconsistent between buildworld and subdir make. Note that after my fix
> in r285986 it is now named STRIPBIN.
>
> When building in rescue/rescue:
>
> OBJDIR/rescue.mk:
> STRIP? strip
> ...
> ${STRIP} rescue
>
> 1: subdir make
> src.conf: STRIP=
> rescue/rescue% make all
> -> make -f OBJDIR/rescue.mk
>
> STRIP= is not passed down into rescue.mk, resulting in 'strip rescue'.
>
> 2. subdir make STRIP env override
> rescue/rescue% make all STRIP=
>
> STRIP= is passed down resulting in ' rescue'.
>
> 3: buildworld
> STRIP= from src.conf is passed down, resulting in ' rescue'.
>
>>
>> Please see
>> https://lists.freebsd.org/pipermail/svn-src-all/2015-July/107910.html
>>
I think the problem here is the use of -m for SUB_MAKE in /Makefile.
Specifying -m share/mk causes all of the issues I've seen (expected
including of /etc/src.conf), while not using -m does not include
/etc/src.conf even though the build is being done in a src dir.
--
Regards,
Bryan Drewery
___
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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On 7/28/15 2:26 PM, Bryan Drewery wrote:
> On 6/21/15 2:29 PM, Simon J. Gerraty wrote:
>> Garrett Cooper wrote:
Am I the only one who fails to build recent base/head (r284673) on
pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs.
>>>
>>> ...
>>>
CC=clang
CXX=clang++
CPP=clang-cpp
>>
>>> You need to remove these lines. They shouldn’t have been set before or
>>> after the commits from projects/bmake .
>>
>> Note: both the grn's specified above are than r284598 which put the
>> inlcude of make.conf back to its original spot, so the meta mode related
>> changes should not be relevant.
>>
>
> Regarding including /etc/make.conf, something is inconsistent with
> buildworld vs subdir make.
Correction: I have STRIP= in /etc/src.conf. The inclusion of it seems
inconsistent between buildworld and subdir make. Note that after my fix
in r285986 it is now named STRIPBIN.
When building in rescue/rescue:
OBJDIR/rescue.mk:
STRIP? strip
...
${STRIP} rescue
1: subdir make
src.conf: STRIP=
rescue/rescue% make all
-> make -f OBJDIR/rescue.mk
STRIP= is not passed down into rescue.mk, resulting in 'strip rescue'.
2. subdir make STRIP env override
rescue/rescue% make all STRIP=
STRIP= is passed down resulting in ' rescue'.
3: buildworld
STRIP= from src.conf is passed down, resulting in ' rescue'.
>
> Please see
> https://lists.freebsd.org/pipermail/svn-src-all/2015-July/107910.html
>
> (Also note that the STRIP= rescue build failure has been identified and
> a fix is being made)
>
--
Regards,
Bryan Drewery
___
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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On 6/21/15 2:29 PM, Simon J. Gerraty wrote: > Garrett Cooper wrote: >>> Am I the only one who fails to build recent base/head (r284673) on >>> pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. >> >> ... >> >>> CC=clang >>> CXX=clang++ >>> CPP=clang-cpp > >> You need to remove these lines. They shouldn’t have been set before or >> after the commits from projects/bmake . > > Note: both the grn's specified above are than r284598 which put the > inlcude of make.conf back to its original spot, so the meta mode related > changes should not be relevant. > Regarding including /etc/make.conf, something is inconsistent with buildworld vs subdir make. Please see https://lists.freebsd.org/pipermail/svn-src-all/2015-July/107910.html (Also note that the STRIP= rescue build failure has been identified and a fix is being made) -- Regards, Bryan Drewery ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Mon, 22 Jun 2015 18:14-, Mark Johnston wrote: > On Mon, Jun 22, 2015 at 08:00:13PM +0200, Trond Endrestøl wrote: > > > > I concur. DTrace support is b0rken. > > > > I installed a fresh VM at work using Glen's recent base/head snapshot, > > 20150618 r284544. I created an /etc/src.conf file with only > > WITH_CTF=yes. I got hold of base/head r284678, started a -j4 > > buildworld + buildkernel, and immediately ctfconvert started > > complaining about nothing to do, i.e.: > > > > ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)] > > > > Same result with -j1. > > These warnings are benign and are the result of compiling with WITH_CTF > and without debug info. Compiling with WITH_DEBUG_FILES or > DEBUG_FLAGS=-g will allow CTF to be generated, but its absence shouldn't > cause any problems (aside from these annoying warnings). Thanks for clarifying. > > I probably forgot to mention earlier, after my problems began last > > week, I always wiped /usr/obj clean before building again. > > > > I haven't activated dtraceall.ko using /boot/loader.conf, but I guess > > those that dare, end up with a kernel panic. I certainly did that last > > week. > > Can you elaborate on this? There don't seem to be any reports of such a > panic, and I certainly dare to load dtraceall.ko on head. :) It was sometime last week. I probably got a bad build due to the use of my highly customised bash environment. The resulting world would take 5.51 times longer to build another clean world and kernel, and fail, with the norm being about one and a half hour on this hardware, i7-960 @ 3.2 GHz. Thus, I reverted to a BE running r284273 from earlier this month, and got away with that. I have now switched to standard FreeBSD csh enviroment, and r284703 doesn't not have a problem loading dtraceall.ko. Sorry for all the noise. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Mon, Jun 22, 2015 at 08:00:13PM +0200, Trond Endrestøl wrote: > On Mon, 22 Jun 2015 09:41-0700, Jason Evans wrote: > > > On Jun 21, 2015, at 1:05 PM, Garrett Cooper wrote: > > > On Jun 21, 2015, at 3:16, Trond Endrestøl > > > wrote: > > >> Am I the only one who fails to build recent base/head (r284673) on > > >> pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. > > > > > > ... > > > > > >> CC=clang > > >> CXX=clang++ > > >> CPP=clang-cpp > > > > > > You need to remove these lines. They shouldn?t have been set before or > > > after the commits from projects/bmake . > > > > I hit the same build failure, and I don't have any of those lines in my > > /etc/make.conf. Mine is: > > > > STRIP= > > > > # added by use.perl 2013-01-21 16:11:13 > > PERL_VERSION=5.12.4 > > WITH_PKGNG=yes > > > > The STRIP= definition appears to have no impact with regard to the build > > failure. > > > > I routinely do multiple buildworld/installworld cycles when updating, so I > > am pretty sure that this is a self bootstrap failure; > > buildworld/installworld succeeds the first time, but not the second time. > > r283923 does not have the problem, so this was introduced sometime in the > > past three weeks. > > I concur. DTrace support is b0rken. > > I installed a fresh VM at work using Glen's recent base/head snapshot, > 20150618 r284544. I created an /etc/src.conf file with only > WITH_CTF=yes. I got hold of base/head r284678, started a -j4 > buildworld + buildkernel, and immediately ctfconvert started > complaining about nothing to do, i.e.: > > ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)] > > Same result with -j1. These warnings are benign and are the result of compiling with WITH_CTF and without debug info. Compiling with WITH_DEBUG_FILES or DEBUG_FLAGS=-g will allow CTF to be generated, but its absence shouldn't cause any problems (aside from these annoying warnings). > > I probably forgot to mention earlier, after my problems began last > week, I always wiped /usr/obj clean before building again. > > I haven't activated dtraceall.ko using /boot/loader.conf, but I guess > those that dare, end up with a kernel panic. I certainly did that last > week. Can you elaborate on this? There don't seem to be any reports of such a panic, and I certainly dare to load dtraceall.ko on head. :) -Mark ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Mon, 22 Jun 2015 09:41-0700, Jason Evans wrote: > On Jun 21, 2015, at 1:05 PM, Garrett Cooper wrote: > > On Jun 21, 2015, at 3:16, Trond Endrestøl > > wrote: > >> Am I the only one who fails to build recent base/head (r284673) on > >> pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. > > > > ... > > > >> CC=clang > >> CXX=clang++ > >> CPP=clang-cpp > > > > You need to remove these lines. They shouldn?t have been set before or > > after the commits from projects/bmake . > > I hit the same build failure, and I don't have any of those lines in my > /etc/make.conf. Mine is: > > STRIP= > > # added by use.perl 2013-01-21 16:11:13 > PERL_VERSION=5.12.4 > WITH_PKGNG=yes > > The STRIP= definition appears to have no impact with regard to the build > failure. > > I routinely do multiple buildworld/installworld cycles when updating, so I am > pretty sure that this is a self bootstrap failure; buildworld/installworld > succeeds the first time, but not the second time. r283923 does not have the > problem, so this was introduced sometime in the past three weeks. I concur. DTrace support is b0rken. I installed a fresh VM at work using Glen's recent base/head snapshot, 20150618 r284544. I created an /etc/src.conf file with only WITH_CTF=yes. I got hold of base/head r284678, started a -j4 buildworld + buildkernel, and immediately ctfconvert started complaining about nothing to do, i.e.: ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)] Same result with -j1. I probably forgot to mention earlier, after my problems began last week, I always wiped /usr/obj clean before building again. I haven't activated dtraceall.ko using /boot/loader.conf, but I guess those that dare, end up with a kernel panic. I certainly did that last week. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Jun 21, 2015, at 1:05 PM, Garrett Cooper wrote: > On Jun 21, 2015, at 3:16, Trond Endrestøl > wrote: >> Am I the only one who fails to build recent base/head (r284673) on >> pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. > > ... > >> CC=clang >> CXX=clang++ >> CPP=clang-cpp > > You need to remove these lines. They shouldn’t have been set before or > after the commits from projects/bmake . I hit the same build failure, and I don't have any of those lines in my /etc/make.conf. Mine is: STRIP= # added by use.perl 2013-01-21 16:11:13 PERL_VERSION=5.12.4 WITH_PKGNG=yes The STRIP= definition appears to have no impact with regard to the build failure. I routinely do multiple buildworld/installworld cycles when updating, so I am pretty sure that this is a self bootstrap failure; buildworld/installworld succeeds the first time, but not the second time. r283923 does not have the problem, so this was introduced sometime in the past three weeks. Jason ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
Garrett Cooper wrote: > > Am I the only one who fails to build recent base/head (r284673) on > > pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. > > ... > > > CC=clang > > CXX=clang++ > > CPP=clang-cpp > You need to remove these lines. They shouldn’t have been set before or > after the commits from projects/bmake . Note: both the grn's specified above are than r284598 which put the inlcude of make.conf back to its original spot, so the meta mode related changes should not be relevant. ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
> wrote: > > > Hi, > >=20 > > Am I the only one who fails to build recent base/head (r284673) on > > pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. > > ... > > > CC=3Dclang > > CXX=3Dclang++ > > CPP=3Dclang-cpp > > Hi Trond, > You need to remove these lines. They shouldn=92t have been set = > before or after the commits from projects/bmake . > Thanks, In case it's of interest, I ran make world OK a few hours back with 284659 & no C directives in make.conf re compiler, (though I see I have /etc/src.conf : WITHOUT_ZFS= NO_WERROR= NO_WERROR.clang= ) Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Reply after previous text, like a play - Not before, which looses context. Indent previous text with "> " Insert new lines before 80 chars. Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64. ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Sun, 21 Jun 2015 13:05-0700, Garrett Cooper wrote: > > CC=clang > > CXX=clang++ > > CPP=clang-cpp > > Hi Trond, > You need to remove these lines. They shouldn?t have been set before or > after the commits from projects/bmake . > Thanks, Ah. That's good to know. Pilot error, indeed. They were probably leftovers from when we could choose between gcc and clang. I'll remove those lines and see what happens. Thanks. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: amd64 base/head r284673 fails to build on amd64 base/head r284639, pilot error?
On Jun 21, 2015, at 3:16, Trond Endrestøl wrote: > Hi, > > Am I the only one who fails to build recent base/head (r284673) on > pretty recent base/head (r284639)? This is on amd64 with ZFS and BEs. ... > CC=clang > CXX=clang++ > CPP=clang-cpp Hi Trond, You need to remove these lines. They shouldn’t have been set before or after the commits from projects/bmake . Thanks, signature.asc Description: Message signed with OpenPGP using GPGMail
