Re: Build failed in Jenkins: Build-UFS-image #599
On Dec 5, 2014, at 19:59, Garrett Cooper yaneurab...@gmail.com wrote: On Dec 5, 2014, at 16:52, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/job/Build-UFS-image/599/ I’m not entirely sure why the could not determine COMPILER_TYPE error popped up, but I have a couple of questions/concerns related to the makefile snippet. I looked at the error and the jenkins jobs a bit more and I think the real problem is that the FreeBSD_Head job is being run in parallel with the Build-UFS-image job, because the FreeBSD_Head job completes without issue and the Build-UFS-image job is not being run with -j anything. I know based on past experience if the tree is updated but not rebuilt with -DNO_CLEAN and installkernel/installworld is being run, sporadic build failures like this will occur, depending on whether or not something needs to be [re]built. One way to deal with this issue is to svn up a source tree, then rsync the checked out copy of the source tree to a unique memory disk, build from there, and install to a unique location as well. Using the jenkins job identifier should be enough… but I’m not sure what the best way with Jenkins is to do this, partly because I don’t know what plugins are installed on the Jenkins server. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Build failed in Jenkins: Build-UFS-image #599
On Sat, Dec 20, 2014 at 01:43:50PM -0800, Garrett Cooper wrote: One way to deal with this issue is to svn up a source tree, then rsync rsync? ITYM zfs clone :-) mcl ___ 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: Build failed in Jenkins: Build-UFS-image #599
On Dec 20, 2014, at 14:27, Mark Linimon lini...@lonesome.com wrote: On Sat, Dec 20, 2014 at 01:43:50PM -0800, Garrett Cooper wrote: One way to deal with this issue is to svn up a source tree, then rsync rsync? ITYM zfs clone :-) That’d work too. Sadly, zfs was a bit undesirable on older versions of FreeBSD, so rsync was the chosen solution... signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Build failed in Jenkins: Build-UFS-image #599
On Dec 6, 2014, at 8:57, Ian Lepore i...@freebsd.org wrote:
On Sat, 2014-12-06 at 16:01 +0100, Dimitry Andric wrote:
[trimmed CC list to -current]
On 06 Dec 2014, at 04:59, Garrett Cooper yaneurab...@gmail.com wrote:
On Dec 5, 2014, at 16:52, jenkins-ad...@freebsd.org wrote:
See https://jenkins.freebsd.org/job/Build-UFS-image/599/
I´m not entirely sure why the could not determine COMPILER_TYPE error
popped up, but I have a couple of questions/concerns related to the
makefile snippet.
1. Does it make sense to check CC when running make install?
Yes, of course it makes sense, if parts of the install depend on e.g.
COMPILER_TYPE. In some cases, you will have to run ${CC} to determine
what it is, specifically if it is just cc”.
Let me phrase it differently… do I need to run cc —version if I’m just going to
be running xinstall to install a bunch of binaries? Seems like a serious waste
of cycles to me.
2. Why isn´t this value determined once in Makefile.inc1 (per build
phase), then passed down from there
Because you are supposed to be able to build stuff in a subdirectory,
without invoking the full top-level Makefile infrastructure. The actual
infrastructure is in share/mk/bsd.*.mk, in fact.
Let me rephrase this as well: why isn’t the value cached once at the top-level
in a more intelligent way and passed down to bsd.compiler.mk? It was always
calculating ${CC} —version on my branch for instance, until I made this commit:
https://svnweb.freebsd.org/base/projects/building-blocks/share/mk/bsd.compiler.mk?r1=275556r2=275558
(which I’m going to merge back to head right now because it’s an unnecessary
fork/popen/whatever’s involved to get the value of a throwaway variable).
(I´ve already considered the scenario where someone explicitly sets CC in a
non-toplevel Makefile, which is a problem, but an outlier rather than the
norm)? AFAICT, it gets recomputed for every recursive make, which
contributes to useless forking for something that honestly doesn´t change
all that often/at all.
This is indeed a pity, and if you know a better solution, let's hear it,
please. :-)
From my perspective, the only place it makes sense for CC to change it during
cross-tools based on Makefile.inc1. Before that it should be value V.X, and
before that it should be value Y.Z, where V.X and Y.Z should be the same. So,
the value should be calculated once in the necessary sections, then passed down
appropriately.
At EMC/Isilon at least, we set CC/CXX=false when running make
distribute*/installkernel/installworld to catch logic errors with
rebuilding code. Should this be in FreeBSD?
Not sure what that is meant to achieve. If parts of the installation
depend on the value of CC, why would you want to set it to false? Just
so it can error out at those points?
I suspect it's to prevent building during the install phase, because
doing so is astonishing. I was astonished the other day when it
happened. I would be much happier if it had just errored out.
Yes. If dependencies changed, logically they shouldn’t be recompiled in the
install phase. This could cause additional unexpected/weird issues if say you
updated libc, it recompiled the shared library, but not the static library, and
then stuff blew up later on. That’s one thing Isilon was trying to avoid
because it reveals either bugs in the build process, or bugs in the build
environment, and it could result in weirdness with produced binaries later on
(especially if compat layers change, linked libraries change, etc).
Thanks!
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Build failed in Jenkins: Build-UFS-image #599
[trimmed CC list to -current]
On 06 Dec 2014, at 04:59, Garrett Cooper yaneurab...@gmail.com wrote:
On Dec 5, 2014, at 16:52, jenkins-ad...@freebsd.org wrote:
See https://jenkins.freebsd.org/job/Build-UFS-image/599/
I’m not entirely sure why the could not determine COMPILER_TYPE error
popped up, but I have a couple of questions/concerns related to the makefile
snippet.
1. Does it make sense to check CC when running make install?
Yes, of course it makes sense, if parts of the install depend on e.g.
COMPILER_TYPE. In some cases, you will have to run ${CC} to determine
what it is, specifically if it is just cc.
2. Why isn’t this value determined once in Makefile.inc1 (per build
phase), then passed down from there
Because you are supposed to be able to build stuff in a subdirectory,
without invoking the full top-level Makefile infrastructure. The actual
infrastructure is in share/mk/bsd.*.mk, in fact.
(I’ve already considered the scenario where someone explicitly sets CC in a
non-toplevel Makefile, which is a problem, but an outlier rather than the
norm)? AFAICT, it gets recomputed for every recursive make, which contributes
to useless forking for something that honestly doesn’t change all that
often/at all.
This is indeed a pity, and if you know a better solution, let's hear it,
please. :-)
At EMC/Isilon at least, we set CC/CXX=false when running make
distribute*/installkernel/installworld to catch logic errors with rebuilding
code. Should this be in FreeBSD?
Not sure what that is meant to achieve. If parts of the installation
depend on the value of CC, why would you want to set it to false? Just
so it can error out at those points?
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Build failed in Jenkins: Build-UFS-image #599
On Sat, Dec 06, 2014 at 04:01:26PM +0100, Dimitry Andric wrote: [trimmed CC list to -current] On 06 Dec 2014, at 04:59, Garrett Cooper yaneurab...@gmail.com wrote: 2. Why isn?t this value determined once in Makefile.inc1 (per build phase), then passed down from there Because you are supposed to be able to build stuff in a subdirectory, without invoking the full top-level Makefile infrastructure. The actual infrastructure is in share/mk/bsd.*.mk, in fact. (I?ve already considered the scenario where someone explicitly sets CC in a non-toplevel Makefile, which is a problem, but an outlier rather than the norm)? AFAICT, it gets recomputed for every recursive make, which contributes to useless forking for something that honestly doesn?t change all that often/at all. This is indeed a pity, and if you know a better solution, let's hear it, please. :-) Why not also put this information into some environment variables with known ugly names, in top-level. Then, the lower-level calls of infrastructure first check the vars, and recalculate the compiler specific info if vars are absent. Use information from vars if present. ___ 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: Build failed in Jenkins: Build-UFS-image #599
On Sat, 2014-12-06 at 16:01 +0100, Dimitry Andric wrote:
[trimmed CC list to -current]
On 06 Dec 2014, at 04:59, Garrett Cooper yaneurab...@gmail.com wrote:
On Dec 5, 2014, at 16:52, jenkins-ad...@freebsd.org wrote:
See https://jenkins.freebsd.org/job/Build-UFS-image/599/
I’m not entirely sure why the could not determine COMPILER_TYPE error
popped up, but I have a couple of questions/concerns related to the
makefile snippet.
1. Does it make sense to check CC when running make install?
Yes, of course it makes sense, if parts of the install depend on e.g.
COMPILER_TYPE. In some cases, you will have to run ${CC} to determine
what it is, specifically if it is just cc.
2. Why isn’t this value determined once in Makefile.inc1 (per build
phase), then passed down from there
Because you are supposed to be able to build stuff in a subdirectory,
without invoking the full top-level Makefile infrastructure. The actual
infrastructure is in share/mk/bsd.*.mk, in fact.
(I’ve already considered the scenario where someone explicitly sets CC in a
non-toplevel Makefile, which is a problem, but an outlier rather than the
norm)? AFAICT, it gets recomputed for every recursive make, which
contributes to useless forking for something that honestly doesn’t change
all that often/at all.
This is indeed a pity, and if you know a better solution, let's hear it,
please. :-)
At EMC/Isilon at least, we set CC/CXX=false when running make
distribute*/installkernel/installworld to catch logic errors with
rebuilding code. Should this be in FreeBSD?
Not sure what that is meant to achieve. If parts of the installation
depend on the value of CC, why would you want to set it to false? Just
so it can error out at those points?
-Dimitry
I suspect it's to prevent building during the install phase, because
doing so is astonishing. I was astonished the other day when it
happened. I would be much happier if it had just errored out.
-- Ian
___
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
Build failed in Jenkins: Build-UFS-image #599
See https://jenkins.freebsd.org/job/Build-UFS-image/599/ -- [...truncated 12194 lines...] install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/etc/make.conf https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/etc/make.conf install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/find_interface/Makefile https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/find_interface/Makefile install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/find_interface/README https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/find_interface/README install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/find_interface/find_interface.c https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/find_interface/find_interface.c install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/hast/ucarp.sh https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/hast/ucarp.sh install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/hast/ucarp_down.sh https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/hast/ucarp_down.sh install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/hast/ucarp_up.sh https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/hast/ucarp_up.sh install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/hast/vip-down.sh https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/hast/vip-down.sh install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/hast/vip-up.sh https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/hast/vip-up.sh install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/ibcs2/README https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/ibcs2/README install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/ibcs2/hello.uu https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/ibcs2/hello.uu install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/indent/indent.pro https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/indent/indent.pro install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/ipfw/change_rules.sh https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/ipfw/change_rules.sh install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/jails/README https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/jails/README install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/kld/Makefile https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/kld/Makefile install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/kld/cdev/Makefile https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/kld/cdev/Makefile install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/kld/cdev/README https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/kld/cdev/README install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/kld/cdev/module/Makefile https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/kld/cdev/module/Makefile install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/kld/cdev/module/cdev.c https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/kld/cdev/module/cdev.c install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/kld/cdev/module/cdev.h https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/kld/cdev/module/cdev.h install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/kld/cdev/module/cdevmod.c https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/kld/cdev/module/cdevmod.c install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/kld/cdev/test/Makefile https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/kld/cdev/test/Makefile install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/kld/cdev/test/testcdev.c https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/kld/cdev/test/testcdev.c install -o root -g wheel -m 444 /builds/FreeBSD_HEAD/share/examples/kld/dyn_sysctl/Makefile https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/examples/kld/dyn_sysctl/Makefile install -o root -g wheel -m 444
Re: Build failed in Jenkins: Build-UFS-image #599
On Dec 5, 2014, at 16:52, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/job/Build-UFS-image/599/ I’m not entirely sure why the could not determine COMPILER_TYPE error popped up, but I have a couple of questions/concerns related to the makefile snippet. 1. Does it make sense to check CC when running make install? 2. Why isn’t this value determined once in Makefile.inc1 (per build phase), then passed down from there (I’ve already considered the scenario where someone explicitly sets CC in a non-toplevel Makefile, which is a problem, but an outlier rather than the norm)? AFAICT, it gets recomputed for every recursive make, which contributes to useless forking for something that honestly doesn’t change all that often/at all. At EMC/Isilon at least, we set CC/CXX=false when running make distribute*/installkernel/installworld to catch logic errors with rebuilding code. Should this be in FreeBSD? Thanks! PS I filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195732 to track this issue and resolve the problem. signature.asc Description: Message signed with OpenPGP using GPGMail
