Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 24, 2014, at 8:43 AM, Glen Barber wrote: > Trimmed CC a bit. > > On Mon, Jun 23, 2014 at 11:42:20PM -0600, Warner Losh wrote: >> On Jun 23, 2014, at 8:24 PM, Glen Barber wrote: >>> I sort of typed what I meant a bit backwards from what I intended to >>> write. What I meant (sort of) is, "I would like to discuss our forward >>> thinking on backward-compatibility." >>> >>> I fully understand forward-compatibility is not feasible. >> >> We already build current back to the stable/8 branch. 7.x is no longer >> feasible, supported or tested. stable/10 is the only one that is required, >> but enough people use stable/9 machines it will work. stable/8 has one >> customer that is keeping it going, so I suspect it will stop working in the >> coming years, maybe before 11 is branched. >> > > To be clear, I am talking about the other direction. Meaning, being > able to "reliably" build N-2 from head/, without needing to do silliness > like 'make make buildworld', or "not using -jN.” Yea, that’s never been officially supported, but generally works. In fact, in the past, you were required to have exactly the same version on the host as you were building a release for to ensure nothing weird happening. Having the full release process work across multiple major versions and have it produce identical results to the exact version built release is not well tested and caused all kinds of problems back in the day. To make it work, you’ll need to make it work. And you’ll need to keep it working as people break it. We focus on the project as “I’m updating from version X to version Y, where X < Y” in all our make infrastructure. While we could add bits where X > Y, and for the release, there are likely several items that will need to be fixed to get there. You are currently hitting this turbulence with cross-version races in multiple job builds. By all means fix them, but since this is an unusual use case (from a historical perspective), expect there to be bumps, and expect there to need to be fixes to make it work (and also from a historical perspective, expect people will break it innocently). >>> I hate to even suggest this, but the ports tree (ab)uses the notion of >>> using the kern.osreldate for certain things. This, however, requires >>> proper bumping of __FreeBSD_version when needed, and maintenance of the >>> Makefiles for the kern.osreldate-specific things. >> >> We already do that. It mostly works most of the time, so long as the delta >> isn’t too great, and we don’t have high compiler/tools/make velocity… Except >> we don’t use the kernel version, but rather the installed tools version as >> indicated by a .h file. That’s more robust. >> > > True. Thank you for the sanity check. > >>> The benefit to this is that it would help prevent pissing off ports >>> developers and make their lives a bit easier when userland / kernel >>> things change. It would, however, (expectedly) is that it would force >>> src committers to do the right thing. Win-win, IMHO. >> >> What should we do we aren’t doing today? >> > > There have been a number of times where changes that should deem > a __FreeBSD_version bump necessary either 1) do not bump > __FreeBSD_version at all, or 2) bump __FreeBSD_version several days (or > longer) later. So, we're left with a window of time where something is > "different enough", but there is no corresponding version change to > reference. > > This is somewhat tangential to my original annoyance here though. :) With -current, a few days is more than enough granularity. There are bumps, and this is one of them. >>> Personally, and no I won't discuss more on this, I'm in the camp of "I >>> don't really see clang as a feature." It caused our ports developers >>> and maintainers a mountain of headache to convert to the "invisibly new >>> great thing", it increases our overall buildworld by a non-insignificant >>> amount of time, and it has personally caused me headaches (still >>> ongoing) trying to figure out what the correct incantation of evil to >>> wish over the cauldron to get BeagleBone images to build. (They're >>> failing because gcc is not being installed on both head/ and stable/10/, >>> and despite the game of "musical KNOBS" I've been playing over the past >>> few days, I'm running out of hair to pull out of my head.) >> >> Yea, if you are using crochet, that’s because crochet uses xdev rather than >> a ports compiler (which in all fairness didn’t exist when it started) to >> build u-boot, which basically requires gcc. >> >> The compiler rework in head is still a work in progress. What’s there now is >> better than before, but still isn’t quite right. I do plan on fixing that >> before summer is out. >> > > It isn't just head that is a problem with crochet, though. stable/10 > has been a problem since, as far as I can tell, roughly early May. Building release 9 on 10 falls under the X > Y category above. If if breaks, and you
Re: Problems building FreeBSD 9.2 on FreeBSD 10
Trimmed CC a bit. On Mon, Jun 23, 2014 at 11:42:20PM -0600, Warner Losh wrote: > On Jun 23, 2014, at 8:24 PM, Glen Barber wrote: > > I sort of typed what I meant a bit backwards from what I intended to > > write. What I meant (sort of) is, "I would like to discuss our forward > > thinking on backward-compatibility." > > > > I fully understand forward-compatibility is not feasible. > > We already build current back to the stable/8 branch. 7.x is no longer > feasible, supported or tested. stable/10 is the only one that is required, > but enough people use stable/9 machines it will work. stable/8 has one > customer that is keeping it going, so I suspect it will stop working in the > coming years, maybe before 11 is branched. > To be clear, I am talking about the other direction. Meaning, being able to "reliably" build N-2 from head/, without needing to do silliness like 'make make buildworld', or "not using -jN." > > I hate to even suggest this, but the ports tree (ab)uses the notion of > > using the kern.osreldate for certain things. This, however, requires > > proper bumping of __FreeBSD_version when needed, and maintenance of the > > Makefiles for the kern.osreldate-specific things. > > We already do that. It mostly works most of the time, so long as the delta > isn’t too great, and we don’t have high compiler/tools/make velocity… Except > we don’t use the kernel version, but rather the installed tools version as > indicated by a .h file. That’s more robust. > True. Thank you for the sanity check. > > The benefit to this is that it would help prevent pissing off ports > > developers and make their lives a bit easier when userland / kernel > > things change. It would, however, (expectedly) is that it would force > > src committers to do the right thing. Win-win, IMHO. > > What should we do we aren’t doing today? > There have been a number of times where changes that should deem a __FreeBSD_version bump necessary either 1) do not bump __FreeBSD_version at all, or 2) bump __FreeBSD_version several days (or longer) later. So, we're left with a window of time where something is "different enough", but there is no corresponding version change to reference. This is somewhat tangential to my original annoyance here though. :) > > Personally, and no I won't discuss more on this, I'm in the camp of "I > > don't really see clang as a feature." It caused our ports developers > > and maintainers a mountain of headache to convert to the "invisibly new > > great thing", it increases our overall buildworld by a non-insignificant > > amount of time, and it has personally caused me headaches (still > > ongoing) trying to figure out what the correct incantation of evil to > > wish over the cauldron to get BeagleBone images to build. (They're > > failing because gcc is not being installed on both head/ and stable/10/, > > and despite the game of "musical KNOBS" I've been playing over the past > > few days, I'm running out of hair to pull out of my head.) > > Yea, if you are using crochet, that’s because crochet uses xdev rather than a > ports compiler (which in all fairness didn’t exist when it started) to build > u-boot, which basically requires gcc. > > The compiler rework in head is still a work in progress. What’s there now is > better than before, but still isn’t quite right. I do plan on fixing that > before summer is out. > It isn't just head that is a problem with crochet, though. stable/10 has been a problem since, as far as I can tell, roughly early May. > >> But 9.2 will never build on head because it is broken with bmake, which is > >> now standard for head. Since 9.2 cannot be changed, and since we’ve > >> removed (or nearly) fmake in current, chances are quite good it will never > >> build on head again without some special handling. > >> > >> In summary, good luck! there’s a lot of use cases here, and it will take > >> time and effort of multiple people over the long haul to keep it working. > >> Best effort may be larger than you estimate… I won’t stand in your way, > >> but I’m afraid my time available to help is limited. > >> > > > > As Ozzy once sang: > > > >"I'm just a dreamer > >I dream my life away > >I'm just a dreamer > >Who dreams of better days” > > Since I was commenting on the opposite problem of what you were wanting > comments on, my harshness is justified. > My comment wasn't a comment on your comment. :-) > What you want though, we largely already do, though maybe with a few more > warts than necessary (which we should try to fix). Most of the warts are due > to gcc/clang division being done badly and unsustainable initially and the > cleanup taking a bit of time, not specific version issues. > > Back to your basic point, the issue becomes a testability one: not all > committers can reasonable be expected to have 8 or 9 systems to test every > change. Having a 10.x system to test changes is a bit of a stretch as it i
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 23, 2014, at 8:24 PM, Glen Barber wrote: > On Mon, Jun 23, 2014 at 07:42:27PM -0600, Warner Losh wrote: >> >> On Jun 23, 2014, at 7:12 PM, Glen Barber wrote: >> >>> On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote: On Jun 23, 2014, at 6:15 PM, Craig Rodrigues wrote: > So, I guess that stable/9 can build properly on a stable/10 box. > For FreeBSD 9.2, there is no easy way out. You’ll have to back port the patch then. We don’t guarantee forward compatibility like this since 9.2 is frozen in time now. >>> >>> I'd really like to discuss rethinking our forward-compatibility >>> policies, since we have (now) 3 active stable/ branches, plus head/. >> >> Generally, in the past, the rule has been “head will build from the last >> stable branch tip.” This was extended, for a while, to “last stable branch >> point” when Ruslan made sure that worked. While -stable has generally built >> on -head, this was never part of the contract. It usually did, but is very >> very hard to guarantee given the nature of head’s tools changing in ways >> that are allowed for head, but that break prior branches. >> > > I sort of typed what I meant a bit backwards from what I intended to > write. What I meant (sort of) is, "I would like to discuss our forward > thinking on backward-compatibility." > > I fully understand forward-compatibility is not feasible. We already build current back to the stable/8 branch. 7.x is no longer feasible, supported or tested. stable/10 is the only one that is required, but enough people use stable/9 machines it will work. stable/8 has one customer that is keeping it going, so I suspect it will stop working in the coming years, maybe before 11 is branched. >>> What I would like to see, with my RE hat on, is a "best effort" >>> backwards compatibility to being able to build the lowest-numbered >>> supported stable/ branch on head/. >> >> I think, that as in the past, this will generally work. However, it won’t >> always work. Things break in this area a lot. More than you might think, >> especially with the huge amount of churn we’ve had wrt compilers, make, etc. >> I suspect that new imports of clang will break this every time, since every >> import of clang has required changes to the tree to either disable warnings, >> or to fix newly flagged things. I suspect there will be a lot of churn here, >> and releases will go stale the fastest… With -current starting to support >> building multiple versions of clang (and gcc), there’s hope for the future, >> but back-porting this code is beyond what I have the time to do. That’s >> going to make things increasingly difficult as we march forward. >> > > I hate to even suggest this, but the ports tree (ab)uses the notion of > using the kern.osreldate for certain things. This, however, requires > proper bumping of __FreeBSD_version when needed, and maintenance of the > Makefiles for the kern.osreldate-specific things. We already do that. It mostly works most of the time, so long as the delta isn’t too great, and we don’t have high compiler/tools/make velocity… Except we don’t use the kernel version, but rather the installed tools version as indicated by a .h file. That’s more robust. > The benefit to this is that it would help prevent pissing off ports > developers and make their lives a bit easier when userland / kernel > things change. It would, however, (expectedly) is that it would force > src committers to do the right thing. Win-win, IMHO. What should we do we aren’t doing today? >> This isn’t even getting into cross build scenarios…. >> >> Or building releases, which is a whole different set of lightly tested code >> that is mostly host independent, but sometimes isn’t as much as you’d had >> hoped... >> >>> Sure, this won't always work, but "best effort" is better than "no >>> effort", which the latter is why we do not have stable/8 snapshot >>> builds, to be honest. I won't spend the time on the stable/8/release/ >>> code nor the snapshot build scripts to waste the time. Building >>> stable/9 on head/ is annoying alone. >> >> stable/9 builds on head. If there’s a race, that needs to be fixed in >> stable/9. That’s quasi supported because people do it. The “best effort” >> involves people that are interested in the bugs being fixed fixing them, or >> convincing others to fix them. For me, this scenario is outside the area I >> care about, have the ability to test, or have time for. >> >> So “best effort” involves more than me making an effort. I may or I may not. >> It all depends on my time and inclination. If it is going to work, bugs need >> to be fixed in stable/9 that prevents it from building on head, while not >> breaking the ability to build on 9. So there’s a lot of heavy lifting that >> will be needed in short order to keep this working once the clang folks can >> figure out how to get past the angst of the upgrade path and push fo
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Mon, Jun 23, 2014 at 07:42:27PM -0600, Warner Losh wrote: > > On Jun 23, 2014, at 7:12 PM, Glen Barber wrote: > > > On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote: > >> On Jun 23, 2014, at 6:15 PM, Craig Rodrigues wrote: > >>> So, I guess that stable/9 can build properly on a stable/10 box. > >>> For FreeBSD 9.2, there is no easy way out. > >> > >> You’ll have to back port the patch then. We don’t guarantee forward > >> compatibility like this since 9.2 is frozen in time now. > >> > > > > I'd really like to discuss rethinking our forward-compatibility > > policies, since we have (now) 3 active stable/ branches, plus head/. > > Generally, in the past, the rule has been “head will build from the last > stable branch tip.” This was extended, for a while, to “last stable branch > point” when Ruslan made sure that worked. While -stable has generally built > on -head, this was never part of the contract. It usually did, but is very > very hard to guarantee given the nature of head’s tools changing in ways that > are allowed for head, but that break prior branches. > I sort of typed what I meant a bit backwards from what I intended to write. What I meant (sort of) is, "I would like to discuss our forward thinking on backward-compatibility." I fully understand forward-compatibility is not feasible. > > What I would like to see, with my RE hat on, is a "best effort" > > backwards compatibility to being able to build the lowest-numbered > > supported stable/ branch on head/. > > I think, that as in the past, this will generally work. However, it won’t > always work. Things break in this area a lot. More than you might think, > especially with the huge amount of churn we’ve had wrt compilers, make, etc. > I suspect that new imports of clang will break this every time, since every > import of clang has required changes to the tree to either disable warnings, > or to fix newly flagged things. I suspect there will be a lot of churn here, > and releases will go stale the fastest… With -current starting to support > building multiple versions of clang (and gcc), there’s hope for the future, > but back-porting this code is beyond what I have the time to do. That’s going > to make things increasingly difficult as we march forward. > I hate to even suggest this, but the ports tree (ab)uses the notion of using the kern.osreldate for certain things. This, however, requires proper bumping of __FreeBSD_version when needed, and maintenance of the Makefiles for the kern.osreldate-specific things. The benefit to this is that it would help prevent pissing off ports developers and make their lives a bit easier when userland / kernel things change. It would, however, (expectedly) is that it would force src committers to do the right thing. Win-win, IMHO. > This isn’t even getting into cross build scenarios…. > > Or building releases, which is a whole different set of lightly tested code > that is mostly host independent, but sometimes isn’t as much as you’d had > hoped... > > > Sure, this won't always work, but "best effort" is better than "no > > effort", which the latter is why we do not have stable/8 snapshot > > builds, to be honest. I won't spend the time on the stable/8/release/ > > code nor the snapshot build scripts to waste the time. Building > > stable/9 on head/ is annoying alone. > > stable/9 builds on head. If there’s a race, that needs to be fixed in > stable/9. That’s quasi supported because people do it. The “best effort” > involves people that are interested in the bugs being fixed fixing them, or > convincing others to fix them. For me, this scenario is outside the area I > care about, have the ability to test, or have time for. > > So “best effort” involves more than me making an effort. I may or I may not. > It all depends on my time and inclination. If it is going to work, bugs need > to be fixed in stable/9 that prevents it from building on head, while not > breaking the ability to build on 9. So there’s a lot of heavy lifting that > will be needed in short order to keep this working once the clang folks can > figure out how to get past the angst of the upgrade path and push forward to > 3.5. Some architectures will break when that happens, no doubt. > Personally, and no I won't discuss more on this, I'm in the camp of "I don't really see clang as a feature." It caused our ports developers and maintainers a mountain of headache to convert to the "invisibly new great thing", it increases our overall buildworld by a non-insignificant amount of time, and it has personally caused me headaches (still ongoing) trying to figure out what the correct incantation of evil to wish over the cauldron to get BeagleBone images to build. (They're failing because gcc is not being installed on both head/ and stable/10/, and despite the game of "musical KNOBS" I've been playing over the past few days, I'm running out of hair to pull out of my head.) > But 9.2
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 23, 2014, at 7:12 PM, Glen Barber wrote: > On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote: >> On Jun 23, 2014, at 6:15 PM, Craig Rodrigues wrote: >>> So, I guess that stable/9 can build properly on a stable/10 box. >>> For FreeBSD 9.2, there is no easy way out. >> >> You’ll have to back port the patch then. We don’t guarantee forward >> compatibility like this since 9.2 is frozen in time now. >> > > I'd really like to discuss rethinking our forward-compatibility > policies, since we have (now) 3 active stable/ branches, plus head/. Generally, in the past, the rule has been “head will build from the last stable branch tip.” This was extended, for a while, to “last stable branch point” when Ruslan made sure that worked. While -stable has generally built on -head, this was never part of the contract. It usually did, but is very very hard to guarantee given the nature of head’s tools changing in ways that are allowed for head, but that break prior branches. > What I would like to see, with my RE hat on, is a "best effort" > backwards compatibility to being able to build the lowest-numbered > supported stable/ branch on head/. I think, that as in the past, this will generally work. However, it won’t always work. Things break in this area a lot. More than you might think, especially with the huge amount of churn we’ve had wrt compilers, make, etc. I suspect that new imports of clang will break this every time, since every import of clang has required changes to the tree to either disable warnings, or to fix newly flagged things. I suspect there will be a lot of churn here, and releases will go stale the fastest… With -current starting to support building multiple versions of clang (and gcc), there’s hope for the future, but back-porting this code is beyond what I have the time to do. That’s going to make things increasingly difficult as we march forward. This isn’t even getting into cross build scenarios…. Or building releases, which is a whole different set of lightly tested code that is mostly host independent, but sometimes isn’t as much as you’d had hoped... > Sure, this won't always work, but "best effort" is better than "no > effort", which the latter is why we do not have stable/8 snapshot > builds, to be honest. I won't spend the time on the stable/8/release/ > code nor the snapshot build scripts to waste the time. Building > stable/9 on head/ is annoying alone. stable/9 builds on head. If there’s a race, that needs to be fixed in stable/9. That’s quasi supported because people do it. The “best effort” involves people that are interested in the bugs being fixed fixing them, or convincing others to fix them. For me, this scenario is outside the area I care about, have the ability to test, or have time for. So “best effort” involves more than me making an effort. I may or I may not. It all depends on my time and inclination. If it is going to work, bugs need to be fixed in stable/9 that prevents it from building on head, while not breaking the ability to build on 9. So there’s a lot of heavy lifting that will be needed in short order to keep this working once the clang folks can figure out how to get past the angst of the upgrade path and push forward to 3.5. Some architectures will break when that happens, no doubt. But 9.2 will never build on head because it is broken with bmake, which is now standard for head. Since 9.2 cannot be changed, and since we’ve removed (or nearly) fmake in current, chances are quite good it will never build on head again without some special handling. In summary, good luck! there’s a lot of use cases here, and it will take time and effort of multiple people over the long haul to keep it working. Best effort may be larger than you estimate… I won’t stand in your way, but I’m afraid my time available to help is limited. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote: > On Jun 23, 2014, at 6:15 PM, Craig Rodrigues wrote: > > So, I guess that stable/9 can build properly on a stable/10 box. > > For FreeBSD 9.2, there is no easy way out. > > You’ll have to back port the patch then. We don’t guarantee forward > compatibility like this since 9.2 is frozen in time now. > I'd really like to discuss rethinking our forward-compatibility policies, since we have (now) 3 active stable/ branches, plus head/. What I would like to see, with my RE hat on, is a "best effort" backwards compatibility to being able to build the lowest-numbered supported stable/ branch on head/. Sure, this won't always work, but "best effort" is better than "no effort", which the latter is why we do not have stable/8 snapshot builds, to be honest. I won't spend the time on the stable/8/release/ code nor the snapshot build scripts to waste the time. Building stable/9 on head/ is annoying alone. Glen pgpVo1iO5DLks.pgp Description: PGP signature
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 23, 2014, at 6:15 PM, Craig Rodrigues wrote:
> Hi,
>
> OK, I think I see the issue. I looked here:
>
> http://svnweb.freebsd.org/base/stable/9/share/mk/bsd.prog.mk?view=log
>
> and saw that dim@ MFC'd his EARLY_BUILD stuff in r257812.
>
> That is why you can build stable/9 on a stable/10 host.
>
> I am building FreeBSD 9.2 which doesn't have that change.
>
>
> bsd.prog.mk in stable/9
> ==
>
> .if defined(PROG_CXX) && !defined(EARLY_BUILD)
>
> .if !empty(CXXFLAGS:M-stdlib=libc++)
>
> echo ${PROG}: ${LIBCPLUSPLUS} >> ${DEPENDFILE}
>
> .else
>
> echo ${PROG}: ${LIBSTDCPLUSPLUS} >> ${DEPENDFILE}
>
> .endif
> .endif
>
>
> bsd.prog.mk in 9.2
>
> .if defined(PROG_CXX)
> .if !empty(CXXFLAGS:M-stdlib=libc++)
> echo ${PROG}: ${LIBCPLUSPLUS} >> ${DEPENDFILE}
> .else
> echo ${PROG}: ${LIBSTDCPLUSPLUS} >> ${DEPENDFILE}
> .endif
> .endif
>
>
> bsd.prog.mk in CURRENT
>
> .if defined(PROG_CXX)
> .if ${COMPILER_TYPE} == "clang" && empty(CXXFLAGS:M-stdlib=libstdc++)
> echo ${PROG}: ${LIBCPLUSPLUS} >> ${DEPENDFILE}
> .else
> echo ${PROG}: ${LIBSTDCPLUSPLUS} >> ${DEPENDFILE}
> .endif
> .endif
>
>
>
> So, I guess that stable/9 can build properly on a stable/10 box.
> For FreeBSD 9.2, there is no easy way out.
You’ll have to back port the patch then. We don’t guarantee forward
compatibility like this since 9.2 is frozen in time now.
stable/9 builds fine on both stable/10 and current hosts.
Warner
> --
> Craig
>
>
>
>
>
> On Mon, Jun 23, 2014 at 4:23 PM, Warner Losh wrote:
>
> On Jun 23, 2014, at 5:19 PM, Craig Rodrigues wrote:
>
> >
> >
> >
> > On Mon, Jun 23, 2014 at 4:13 PM, Warner Losh wrote:
> >
> > Which bombing out are you seeing (two or three have been sighted in this
> > thread)? And is this a nanobsd build, or a straight buildworld?
> >
> > When building FreeNAS, with a hacked the nanobsd
> > script to does "make make buildworld", and the make.conf which I posted, I
> > am seeing this:
> >
> > --
> > >>> stage 1.2: bootstrap tools
> > --
> > cd /zroot/build/r/freenas2/FreeBSD/src;
> > MAKEOBJDIRPREFIX=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp
> > INSTALL="sh /zroot/build/r/freenas2/FreeBSD/src/tools/install.sh"
> > PATH=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/sbin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/bin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/games:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
> >
> > WORLDTMP=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp
> > VERSION="9.3-ALPHA" MAKEFLAGS="-m
> > /zroot/build/r/freenas2/FreeBSD/src/tools/build/mk -j 9
> > .MAKE.LEVEL.ENV=MAKELEVEL NO_CLEAN=1 SRCCONF=/dev/null
> > __MAKE_CONF=/zroot/build/r/freenas2/os-base/amd64/make.conf.build -m
> > /zroot/build/r/freenas2/FreeBSD/src/share/mk TARGET=amd64
> > TARGET_ARCH=amd64" COMPILER_TYPE=clang
> > /zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/make.amd64/make
> > -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1100022 SSP_CFLAGS=
> > -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC
> > -DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF
> > -DEARLY_BUILD bootstrap-tools
> > ===> gnu/usr.bin/gperf (obj,depend,all,install)
> > ===> gnu/usr.bin/gperf/doc (obj)
> > ===> gnu/usr.bin/gperf/doc (depend)
> > make: don't know how to make /usr/lib/libstdc++.a. Stop
> > *** [bootstrap-tools] Error code 2
> > 1 error
> > *** [_bootstrap-tools] Error code 2
> > 1 error
> > *** [buildworld] Error code 2
> >
> > make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src
> > 1 error
> >
> > make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src
> > ===
> > ERROR: build FAILED; see above or log file here:
> > /zroot/build/r/freenas2/os-base/amd64/_.bw
> > *** Error code 2
> >
> > Stop.
> > make: stopped in /zroot/build/r/freenas2
> >
> >
> >
> >
> >
> > And I specifically was doing my testing on -current, not 10.x. I haven’t
> > back ported much of anything I’ve done to the build system, and if anybody
> > else has, then it is on them to make it work in the 10.x environment. While
> > it has usually worked, 9 on 10 isn’t in the supported matrix we’ve
> > traditionally had in this project.
> >
> > I reproduced the same problem using a CURRENT build host ( 11.0-CURRENT
> > FreeBSD 11.0-CURRENT #1 r267305 ).
> >
>
> I wonder how this could possibly happen on stable-10, since EARLY_BUILD is
> still there to preclude the line being added.
>
> I’ll have to re-run my test WITHOUT_CLANG. I ju
Re: Problems building FreeBSD 9.2 on FreeBSD 10
Hi,
OK, I think I see the issue. I looked here:
http://svnweb.freebsd.org/base/stable/9/share/mk/bsd.prog.mk?view=log
and saw that dim@ MFC'd his EARLY_BUILD stuff in r257812.
That is why you can build stable/9 on a stable/10 host.
I am building FreeBSD 9.2 which doesn't have that change.
bsd.prog.mk in stable/9
==
.if defined(PROG_CXX) && !defined(EARLY_BUILD)
.if !empty(CXXFLAGS:M-stdlib=libc++)
echo ${PROG}: ${LIBCPLUSPLUS} >> ${DEPENDFILE}
.else
echo ${PROG}: ${LIBSTDCPLUSPLUS} >> ${DEPENDFILE}
.endif
.endif
bsd.prog.mk in 9.2
.if defined(PROG_CXX)
.if !empty(CXXFLAGS:M-stdlib=libc++)
echo ${PROG}: ${LIBCPLUSPLUS} >> ${DEPENDFILE}
.else
echo ${PROG}: ${LIBSTDCPLUSPLUS} >> ${DEPENDFILE}
.endif
.endif
bsd.prog.mk in CURRENT
.if defined(PROG_CXX)
.if ${COMPILER_TYPE} == "clang" && empty(CXXFLAGS:M-stdlib=libstdc++)
echo ${PROG}: ${LIBCPLUSPLUS} >> ${DEPENDFILE}
.else
echo ${PROG}: ${LIBSTDCPLUSPLUS} >> ${DEPENDFILE}
.endif
.endif
So, I guess that stable/9 can build properly on a stable/10 box.
For FreeBSD 9.2, there is no easy way out.
--
Craig
On Mon, Jun 23, 2014 at 4:23 PM, Warner Losh wrote:
>
> On Jun 23, 2014, at 5:19 PM, Craig Rodrigues wrote:
>
> >
> >
> >
> > On Mon, Jun 23, 2014 at 4:13 PM, Warner Losh wrote:
> >
> > Which bombing out are you seeing (two or three have been sighted in this
> thread)? And is this a nanobsd build, or a straight buildworld?
> >
> > When building FreeNAS, with a hacked the nanobsd
> > script to does "make make buildworld", and the make.conf which I posted,
> I
> > am seeing this:
> >
> > --
> > >>> stage 1.2: bootstrap tools
> > --
> > cd /zroot/build/r/freenas2/FreeBSD/src;
> MAKEOBJDIRPREFIX=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp
> INSTALL="sh /zroot/build/r/freenas2/FreeBSD/src/tools/install.sh"
>
> PATH=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/sbin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/bin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/games:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
>
> WORLDTMP=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp
> VERSION="9.3-ALPHA" MAKEFLAGS="-m
> /zroot/build/r/freenas2/FreeBSD/src/tools/build/mk -j 9
> .MAKE.LEVEL.ENV=MAKELEVEL NO_CLEAN=1 SRCCONF=/dev/null
> __MAKE_CONF=/zroot/build/r/freenas2/os-base/amd64/make.conf.build -m
> /zroot/build/r/freenas2/FreeBSD/src/share/mk TARGET=amd64
> TARGET_ARCH=amd64" COMPILER_TYPE=clang
> /zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/make.amd64/make
> -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1100022 SSP_CFLAGS=
> -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC
> -DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF
> -DEARLY_BUILD bootstrap-tools
> > ===> gnu/usr.bin/gperf (obj,depend,all,install)
> > ===> gnu/usr.bin/gperf/doc (obj)
> > ===> gnu/usr.bin/gperf/doc (depend)
> > make: don't know how to make /usr/lib/libstdc++.a. Stop
> > *** [bootstrap-tools] Error code 2
> > 1 error
> > *** [_bootstrap-tools] Error code 2
> > 1 error
> > *** [buildworld] Error code 2
> >
> > make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src
> > 1 error
> >
> > make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src
> > ===
> > ERROR: build FAILED; see above or log file here:
> /zroot/build/r/freenas2/os-base/amd64/_.bw
> > *** Error code 2
> >
> > Stop.
> > make: stopped in /zroot/build/r/freenas2
> >
> >
> >
> >
> >
> > And I specifically was doing my testing on -current, not 10.x. I haven't
> back ported much of anything I've done to the build system, and if anybody
> else has, then it is on them to make it work in the 10.x environment. While
> it has usually worked, 9 on 10 isn't in the supported matrix we've
> traditionally had in this project.
> >
> > I reproduced the same problem using a CURRENT build host ( 11.0-CURRENT
> FreeBSD 11.0-CURRENT #1 r267305 ).
> >
>
> I wonder how this could possibly happen on stable-10, since EARLY_BUILD is
> still there to preclude the line being added.
>
> I'll have to re-run my test WITHOUT_CLANG. I just used the defaults.
>
> Any chance you can narrow the number of options required to trigger this?
>
> Warner
>
>
___
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: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 23, 2014, at 5:19 PM, Craig Rodrigues wrote: > > > > On Mon, Jun 23, 2014 at 4:13 PM, Warner Losh wrote: > > Which bombing out are you seeing (two or three have been sighted in this > thread)? And is this a nanobsd build, or a straight buildworld? > > When building FreeNAS, with a hacked the nanobsd > script to does "make make buildworld", and the make.conf which I posted, I > am seeing this: > > -- > >>> stage 1.2: bootstrap tools > -- > cd /zroot/build/r/freenas2/FreeBSD/src; > MAKEOBJDIRPREFIX=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp > INSTALL="sh /zroot/build/r/freenas2/FreeBSD/src/tools/install.sh" > PATH=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/sbin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/bin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/games:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin > > WORLDTMP=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp > VERSION="9.3-ALPHA" MAKEFLAGS="-m > /zroot/build/r/freenas2/FreeBSD/src/tools/build/mk -j 9 > .MAKE.LEVEL.ENV=MAKELEVEL NO_CLEAN=1 SRCCONF=/dev/null > __MAKE_CONF=/zroot/build/r/freenas2/os-base/amd64/make.conf.build -m > /zroot/build/r/freenas2/FreeBSD/src/share/mk TARGET=amd64 TARGET_ARCH=amd64" > COMPILER_TYPE=clang > /zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/make.amd64/make > -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1100022 SSP_CFLAGS= > -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC > -DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF > -DEARLY_BUILD bootstrap-tools > ===> gnu/usr.bin/gperf (obj,depend,all,install) > ===> gnu/usr.bin/gperf/doc (obj) > ===> gnu/usr.bin/gperf/doc (depend) > make: don't know how to make /usr/lib/libstdc++.a. Stop > *** [bootstrap-tools] Error code 2 > 1 error > *** [_bootstrap-tools] Error code 2 > 1 error > *** [buildworld] Error code 2 > > make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src > 1 error > > make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src > === > ERROR: build FAILED; see above or log file here: > /zroot/build/r/freenas2/os-base/amd64/_.bw > *** Error code 2 > > Stop. > make: stopped in /zroot/build/r/freenas2 > > > > > > And I specifically was doing my testing on -current, not 10.x. I haven’t back > ported much of anything I’ve done to the build system, and if anybody else > has, then it is on them to make it work in the 10.x environment. While it has > usually worked, 9 on 10 isn’t in the supported matrix we’ve traditionally had > in this project. > > I reproduced the same problem using a CURRENT build host ( 11.0-CURRENT > FreeBSD 11.0-CURRENT #1 r267305 ). > I wonder how this could possibly happen on stable-10, since EARLY_BUILD is still there to preclude the line being added. I’ll have to re-run my test WITHOUT_CLANG. I just used the defaults. Any chance you can narrow the number of options required to trigger this? Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Mon, Jun 23, 2014 at 4:13 PM, Warner Losh wrote: > > Which bombing out are you seeing (two or three have been sighted in this > thread)? And is this a nanobsd build, or a straight buildworld? > When building FreeNAS, with a hacked the nanobsd script to does "make make buildworld", and the make.conf which I posted, I am seeing this: -- >>> stage 1.2: bootstrap tools -- cd /zroot/build/r/freenas2/FreeBSD/src; MAKEOBJDIRPREFIX=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp INSTALL="sh /zroot/build/r/freenas2/FreeBSD/src/tools/install.sh" PATH=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/sbin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/bin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/games:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp VERSION="9.3-ALPHA" MAKEFLAGS="-m /zroot/build/r/freenas2/FreeBSD/src/tools/build/mk -j 9 .MAKE.LEVEL.ENV=MAKELEVEL NO_CLEAN=1 SRCCONF=/dev/null __MAKE_CONF=/zroot/build/r/freenas2/os-base/amd64/make.conf.build -m /zroot/build/r/freenas2/FreeBSD/src/share/mk TARGET=amd64 TARGET_ARCH=amd64" COMPILER_TYPE=clang /zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/make.amd64/make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1100022 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD bootstrap-tools ===> gnu/usr.bin/gperf (obj,depend,all,install) ===> gnu/usr.bin/gperf/doc (obj) ===> gnu/usr.bin/gperf/doc (depend) make: don't know how to make /usr/lib/libstdc++.a. Stop *** [bootstrap-tools] Error code 2 1 error *** [_bootstrap-tools] Error code 2 1 error *** [buildworld] Error code 2 make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src 1 error make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src === ERROR: build FAILED; see above or log file here: /zroot/build/r/freenas2/os-base/amd64/_.bw *** Error code 2 Stop. make: stopped in /zroot/build/r/freenas2 > > And I specifically was doing my testing on -current, not 10.x. I haven't > back ported much of anything I've done to the build system, and if anybody > else has, then it is on them to make it work in the 10.x environment. While > it has usually worked, 9 on 10 isn't in the supported matrix we've > traditionally had in this project. > I reproduced the same problem using a CURRENT build host ( 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r267305 ). -- Craig ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 23, 2014, at 5:02 PM, Craig Rodrigues wrote: > > > > On Thu, Jun 19, 2014 at 9:00 PM, Warner Losh wrote: > OK. I must be daft, or maybe just missing something. But I can build 9.3 > almost branch point on a current jail running on a 10.x system (to simulate > the 9 on current case). I don’t see the problem being talked about at all. As > for 9 on 10, I was also able to do a build, but my 10.x system may not have > been pristine. > > > I was able to reproduce the problem by building FreeNAS/master branch > (which uses FreeBSD 9.2-ish sources) > on a FreeBSD 10 host, using "make make buildworld" > as suggested by Glen. > > The FreeNAS build generates is following make.conf file and uses > that to build FreeBSD 9.2. It works fine on a FreeBSD-9 host, but bombs > out on a FreeBSD 10 host. Which bombing out are you seeing (two or three have been sighted in this thread)? And is this a nanobsd build, or a straight buildworld? And I specifically was doing my testing on -current, not 10.x. I haven’t back ported much of anything I’ve done to the build system, and if anybody else has, then it is on them to make it work in the 10.x environment. While it has usually worked, 9 on 10 isn’t in the supported matrix we’ve traditionally had in this project. Warner > = > #WITHOUT_ACPI=true > WITHOUT_ATM=true > WITHOUT_BIND_DNSSEC=true > WITHOUT_BIND_ETC=true > WITHOUT_BIND_LIBS_LWRES=true > WITHOUT_BIND_NAMED=true > WITHOUT_BLUETOOTH=true > WITHOUT_CALENDAR=true > WITHOUT_CTM=true > WITHOUT_CVS=true > WITHOUT_DICT=true > WITHOUT_EXAMPLES=true > WITHOUT_FORTRAN=true > WITHOUT_FREEBSD_UPDATE=yes > WITHOUT_GAMES=true > WITHOUT_GCOV=true > WITHOUT_GPIB=true > WITHOUT_HTML=true > WITHOUT_I4B=true > WITHOUT_IPFILTER=true > WITHOUT_IPX=true > WITHOUT_LIB32=true > WITHOUT_LIBKSE=true > # Required for proper terminal locale > #WITHOUT_LOCALES=true > WITHOUT_LPR=true > WITHOUT_MAN=true > WITHOUT_NDIS=true > WITHOUT_NLS=true > WITHOUT_NS_CACHING=true > WITHOUT_OBJC=true > WITHOUT_PORTSNAP=true > WITHOUT_PPP=true > WITHOUT_PROFILE=true > WITHOUT_RCMDS=true > WITHOUT_SENDMAIL=true > # Knob needs to be fixed on systems that don't have the docs stuff > # preinstalled, e.g. 9.x bsdinstall images. > #WITHOUT_SHAREDOCS=true > WITHOUT_SYSINSTALL=true > # Telnet's a useful tool to have on the remote box. > #WITHOUT_TELNET=true > WITHOUT_WIRELESS=true > WITHOUT_WPA_SUPPLICANT_EAPOL=true > > DEFAULT_VERSIONS=python=2.7 > > NOPORTDOCS=true > > LOCAL_DIRS= > > > > WITHOUT_CLANG=true > WITHOUT_SSP=true You might have to (bogusly IMHO) define WITHOUT_CLANG_IS_CC=true as well for things to work. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Thu, Jun 19, 2014 at 9:00 PM, Warner Losh wrote: > OK. I must be daft, or maybe just missing something. But I can build 9.3 > almost branch point on a current jail running on a 10.x system (to simulate > the 9 on current case). I don't see the problem being talked about at all. > As for 9 on 10, I was also able to do a build, but my 10.x system may not > have been pristine. > > I was able to reproduce the problem by building FreeNAS/master branch (which uses FreeBSD 9.2-ish sources) on a FreeBSD 10 host, using "make make buildworld" as suggested by Glen. The FreeNAS build generates is following make.conf file and uses that to build FreeBSD 9.2. It works fine on a FreeBSD-9 host, but bombs out on a FreeBSD 10 host. = #WITHOUT_ACPI=true WITHOUT_ATM=true WITHOUT_BIND_DNSSEC=true WITHOUT_BIND_ETC=true WITHOUT_BIND_LIBS_LWRES=true WITHOUT_BIND_NAMED=true WITHOUT_BLUETOOTH=true WITHOUT_CALENDAR=true WITHOUT_CTM=true WITHOUT_CVS=true WITHOUT_DICT=true WITHOUT_EXAMPLES=true WITHOUT_FORTRAN=true WITHOUT_FREEBSD_UPDATE=yes WITHOUT_GAMES=true WITHOUT_GCOV=true WITHOUT_GPIB=true WITHOUT_HTML=true WITHOUT_I4B=true WITHOUT_IPFILTER=true WITHOUT_IPX=true WITHOUT_LIB32=true WITHOUT_LIBKSE=true # Required for proper terminal locale #WITHOUT_LOCALES=true WITHOUT_LPR=true WITHOUT_MAN=true WITHOUT_NDIS=true WITHOUT_NLS=true WITHOUT_NS_CACHING=true WITHOUT_OBJC=true WITHOUT_PORTSNAP=true WITHOUT_PPP=true WITHOUT_PROFILE=true WITHOUT_RCMDS=true WITHOUT_SENDMAIL=true # Knob needs to be fixed on systems that don't have the docs stuff # preinstalled, e.g. 9.x bsdinstall images. #WITHOUT_SHAREDOCS=true WITHOUT_SYSINSTALL=true # Telnet's a useful tool to have on the remote box. #WITHOUT_TELNET=true WITHOUT_WIRELESS=true WITHOUT_WPA_SUPPLICANT_EAPOL=true DEFAULT_VERSIONS=python=2.7 NOPORTDOCS=true LOCAL_DIRS= WITHOUT_CLANG=true WITHOUT_SSP=true = -- Craig ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
On Sat, 21 Jun 2014 18:55:40 -0400, Glen Barber writes: >> make make && make -j8 -DNO_CLEAN buildworld > >This is, IMHO, the worst solution I've heard on this topic so far. I didn't say it was a good solution - but if you want -j you may not have a choice (unless you fix src/Makefile). ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
>Removal of EARLY_BUILD is not the issue here, I have no idea where the >hell the came into play. > >It is a race in the chain with what make(1) gets built for the stable/9 >userland. It is why the 'make make buildworld' thing I mentioned works. IIRC all the fixes I put into src/Makefile to ensure correct [bf]make was built prior to anything like buildworld were only in head. I think Warner has now removed at least the fmake bits from head, but stable/10 has it all. I think this fixed a number of races. make make buildworld should work, though if you want to use -j a separate invocation would be a good idea (absent the fixes from stable/10): make make && make -j8 -DNO_CLEAN buildworld ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
On Sat, Jun 21, 2014 at 03:05:05PM -0700, Simon J. Gerraty wrote: > >Removal of EARLY_BUILD is not the issue here, I have no idea where the > >hell the came into play. > > > >It is a race in the chain with what make(1) gets built for the stable/9 > >userland. It is why the 'make make buildworld' thing I mentioned works. > > IIRC all the fixes I put into src/Makefile to ensure correct [bf]make > was built prior to anything like buildworld were only in head. > I think Warner has now removed at least the fmake bits from head, but > stable/10 has it all. I think this fixed a number of races. > > make make buildworld > > should work, though if you want to use -j a separate invocation would be > a good idea (absent the fixes from stable/10): > > make make && make -j8 -DNO_CLEAN buildworld This is, IMHO, the worst solution I've heard on this topic so far. Glen pgpRuNnCck_p8.pgp Description: PGP signature
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Thu, Jun 19, 2014 at 10:00:03PM -0600, Warner Losh wrote: > > On Jun 18, 2014, at 4:32 PM, Craig Rodrigues wrote: > > > On Tue, Jun 17, 2014 at 11:59 PM, Dimitry Andric wrote: > >> > >> See r257658 which had fixed this, but it was reverted by Warner, > >> unfortunately. This was one of the uses of the EARLY_BUILD flag which > >> was *not* redundant. :-/ > > > > > > Warner, > > > > Is there a way to bring back the behavior of r257658 but without > > the way it was implemented with the EARLY_BUILD flag? > > It would be handy, as we can see by this thread discussion. > > OK. I must be daft, or maybe just missing something. But I can build 9.3 > almost branch point on a current jail running on a 10.x system (to simulate > the 9 on current case). I don’t see the problem being talked about at all. As > for 9 on 10, I was also able to do a build, but my 10.x system may not have > been pristine. > Removal of EARLY_BUILD is not the issue here, I have no idea where the hell the came into play. It is a race in the chain with what make(1) gets built for the stable/9 userland. It is why the 'make make buildworld' thing I mentioned works. Glen pgpYeCFRFGObO.pgp Description: PGP signature
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 18, 2014, at 4:32 PM, Craig Rodrigues wrote: > On Tue, Jun 17, 2014 at 11:59 PM, Dimitry Andric wrote: >> >> See r257658 which had fixed this, but it was reverted by Warner, >> unfortunately. This was one of the uses of the EARLY_BUILD flag which >> was *not* redundant. :-/ > > > Warner, > > Is there a way to bring back the behavior of r257658 but without > the way it was implemented with the EARLY_BUILD flag? > It would be handy, as we can see by this thread discussion. OK. I must be daft, or maybe just missing something. But I can build 9.3 almost branch point on a current jail running on a 10.x system (to simulate the 9 on current case). I don’t see the problem being talked about at all. As for 9 on 10, I was also able to do a build, but my 10.x system may not have been pristine. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On 6/18/14, 4:05 AM, Simon J. Gerraty wrote: On Tue, 17 Jun 2014 11:35:42 -0700, Craig Rodrigues writes: Do you know if there is some sort of patch that can be applied to FreeBSD stable/9 sources so that it can be built on a FreeBSD 10/stable, or FreeBSD CURRENT host with bmake? You would likely need to apply many of the changes made in 10. IIRC stable/9 has just enough bmake support to be able to build/install bmake itself, so that ports can use it. I'm not sure how many people would appreciate making such changes to stable/9 at this point. I just populate a jail with 9.0 binaries from the DVD image. I'm trying to build a FreeBSD stable/9 jail on a FreeBSD 10/stable host, so th at I can build ports inside the jail with poudriere. Why not use fmake in that scenario? ___ 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" ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 18, 2014, at 4:32 PM, Craig Rodrigues wrote: > On Tue, Jun 17, 2014 at 11:59 PM, Dimitry Andric wrote: >> >> See r257658 which had fixed this, but it was reverted by Warner, >> unfortunately. This was one of the uses of the EARLY_BUILD flag which >> was *not* redundant. :-/ > > > Warner, > > Is there a way to bring back the behavior of r257658 but without > the way it was implemented with the EARLY_BUILD flag? > It would be handy, as we can see by this thread discussion. The EARLY_BUILD flag tightly coupled the bsd.*.mk files to the build system, so I’l like to see it stay dead. 9.x assumes that by defining it, it can affect the system installed .mk files in a specific way. This is an unwise assumption, as this thread demonstrates. The real problem, imho, is that the construct in bsd.prog.mk is generating a dependency on the wrong C++ standard library. Why is it generating for the g++ library when the compiler is clang? That seems like the real bug here. I’ll also note that building release X-2 on head isn’t generally supported by the project, but having said that, I’ll see what I can do. Surprisingly, I don’t have a good -current environment setup on my fast build boxes, so I’ll setup a quick jail and see if I can recreate. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 18, 2014, at 12:59 AM, Dimitry Andric wrote: > On 18 Jun 2014, at 01:33, Craig Rodrigues wrote: >> On Tue, Jun 17, 2014 at 2:54 PM, Craig Rodrigues wrote: >>> On Tue, Jun 17, 2014 at 2:14 PM, Glen Barber wrote: For what it is worth, I'm working around this problem by running: # make make buildworld -jN [...] Note the extra 'make', which rather than relying on the bootstrap-tools to determine which make to build, I am specifically telling it to build fmake. >>> >>> >>> Nice! That works! >>> Thanks. >>> >>> -- >>> Craig >> >> >> Oops, that got me a bit farther, but further along, things failed for me >> with: > ... >> echo gperf: /usr/lib/libstdc++.a >> .depend >> ===> gnu/usr.bin/gperf/doc (depend) >> make: don't know how to make /usr/lib/libstdc++.a. Stop > > See r257658 which had fixed this, but it was reverted by Warner, > unfortunately. This was one of the uses of the EARLY_BUILD flag which > was *not* redundant. :-/ Really? I thought I’d prevent to myself that it was redundant in all cases, at least in -current. I didn’t think I’d merged back any of the early_build stuff into 10... I’ll take a look at this though... Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Tue, Jun 17, 2014 at 11:59 PM, Dimitry Andric wrote: > > See r257658 which had fixed this, but it was reverted by Warner, > unfortunately. This was one of the uses of the EARLY_BUILD flag which > was *not* redundant. :-/ Warner, Is there a way to bring back the behavior of r257658 but without the way it was implemented with the EARLY_BUILD flag? It would be handy, as we can see by this thread discussion. -- Craig ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
On 18 Jun 2014, at 01:33, Craig Rodrigues wrote: > On Tue, Jun 17, 2014 at 2:54 PM, Craig Rodrigues wrote: >> On Tue, Jun 17, 2014 at 2:14 PM, Glen Barber wrote: >>> >>> For what it is worth, I'm working around this problem by running: >>> >>># make make buildworld -jN [...] >>> >>> Note the extra 'make', which rather than relying on the bootstrap-tools >>> to determine which make to build, I am specifically telling it to build >>> fmake. >> >> >> Nice! That works! >> Thanks. >> >> -- >> Craig > > > Oops, that got me a bit farther, but further along, things failed for me with: ... > echo gperf: /usr/lib/libstdc++.a >> .depend > ===> gnu/usr.bin/gperf/doc (depend) > make: don't know how to make /usr/lib/libstdc++.a. Stop See r257658 which had fixed this, but it was reverted by Warner, unfortunately. This was one of the uses of the EARLY_BUILD flag which was *not* redundant. :-/ -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Tue, Jun 17, 2014 at 04:33:11PM -0700, Craig Rodrigues wrote: > On Tue, Jun 17, 2014 at 2:54 PM, Craig Rodrigues wrote: > > On Tue, Jun 17, 2014 at 2:14 PM, Glen Barber wrote: > >> > >> For what it is worth, I'm working around this problem by running: > >> > >> # make make buildworld -jN [...] > >> > >> Note the extra 'make', which rather than relying on the bootstrap-tools > >> to determine which make to build, I am specifically telling it to build > >> fmake. > > > > > > Nice! That works! > > Thanks. > > > > -- > > Craig > > > Oops, that got me a bit farther, but further along, things failed for me with: > > -- > >>> stage 1.2: bootstrap tools > -- > [...] > >> .depend > echo gperf: /usr/lib/libstdc++.a >> .depend > ===> gnu/usr.bin/gperf/doc (depend) > make: don't know how to make /usr/lib/libstdc++.a. Stop > *** [bootstrap-tools] Error code 2 > 1 error > *** [_bootstrap-tools] Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error > > > > Oh well. This is because the build is (wrongly) using the host libstdc++ instead of creating one within the build environment. I thought this was fixed a while back, but the snapshot builder tracks head/, not stable/10 now. A "fix" would be to build the builder userland with WITH_GNUCXX (and other WITH_FOOs needed for gcc to be a usable compiler again), coexisting with clang. Unfortunately... Glen pgpEXhzzmW7qv.pgp Description: PGP signature
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Tue, Jun 17, 2014 at 2:54 PM, Craig Rodrigues wrote: > On Tue, Jun 17, 2014 at 2:14 PM, Glen Barber wrote: >> >> For what it is worth, I'm working around this problem by running: >> >> # make make buildworld -jN [...] >> >> Note the extra 'make', which rather than relying on the bootstrap-tools >> to determine which make to build, I am specifically telling it to build >> fmake. > > > Nice! That works! > Thanks. > > -- > Craig Oops, that got me a bit farther, but further along, things failed for me with: -- >>> stage 1.2: bootstrap tools -- cd /zroot/build/r/freenas2/FreeBSD/src; MAKEOBJDIRPREFIX=/usr/obj/zroot/build/r/freenas2/FreeBSD/src/tmp INSTALL="sh /zroot/build/r/freenas2/FreeBSD/src/tools/install.sh" PATH=/usr/obj/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/sbin:/usr/obj/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/bin:/usr/obj/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/games:/usr/obj/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/zroot/build/r/freenas2/FreeBSD/src/tmp VERSION="FreeBSD 11.0-CURRENT amd64 1100022" MAKEFLAGS="-m /zroot/build/r/freenas2/FreeBSD/src/tools/build/mk -j 9 SRCCONF=/dev/null __MAKE_CONF=/zroot/build/r/freenas2/os-base/amd64/make.conf.build NO_CLEAN=1 -m /zroot/build/r/freenas2/FreeBSD/src/share/mk TARGET=amd64 TARGET_ARCH=amd64" COMPILER_TYPE=clang /usr/obj/zroot/build/r/freenas2/FreeBSD/src/make.amd64/make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1100022 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD bootstrap-tools ===> gnu/usr.bin/gperf (obj,depend,all,install) /usr/obj/zroot/build/r/freenas2/FreeBSD/src/tmp/zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf created for /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf ===> gnu/usr.bin/gperf/doc (obj) /usr/obj/zroot/build/r/freenas2/FreeBSD/src/tmp/zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/doc created for /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/doc rm -f .depend mkdep -f .depend -a -I/usr/obj/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/include -I/zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/input.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword-list.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/positions.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc /zroot/build/r/freenas2/FreeBSD/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc echo gperf: /usr/lib/libc.a /usr/obj/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/lib/libegacy.a >> .depend echo gperf: /usr/lib/libstdc++.a >> .depend ===> gnu/usr.bin/gperf/doc (depend) make: don't know how to make /usr/lib/libstdc++.a. Stop *** [bootstrap-tools] Error code 2 1 error *** [_bootstrap-tools] Error code 2 1 error *** [buildworld] Error code 2 1 error Oh well. -- Craig ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
>> Why not use fmake in that scenario? > >That might work. Is using the devel/fmake port sufficient for using fmake? So long as it is recent enough to have :tu and :tl I would expect so. >If I typed "make something", is there a way inside the make environment to >detect if bmake or fmake was invoked, and error out appropriately? You can test for bmake with .if defined(.PARSEDIR) lack of that means fmake. ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
Sorry, I didn't speak to the problem you hit... On Tue, 17 Jun 2014 11:35:42 -0700, Craig Rodrigues writes: >> If I build like this: >> >> env TARGET=amd64 TARGET_ARCH=amd64 make -j 9 SRCCONF=/dev/null >> __MAKE_CONF=/opt/local/branches/freenas/os-base/amd64/make.conf.build >> NO_CLEAN=1 buildworld >> >> I get this error: >> >> --- upgrade_checks --- >> A failure has been detected in another branch of the parallel make >> So earlier in your build there will be another error that is actual issue, that's the more interesting thing to look at. >> make[1]: stopped in /opt/local/branches/freenas/FreeBSD/src >> *** [upgrade_checks] Error code 2 >> >> make: stopped in /opt/local/branches/freenas/FreeBSD/src >> 1 error >> If I remove the "-j 9", then I can get the build to work properly. That's a good indication of a race condition. Note the recent work someone did to add .WAIT to subdir handling which is an effort to reduce races. ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
On Tue, Jun 17, 2014 at 2:14 PM, Glen Barber wrote: > > For what it is worth, I'm working around this problem by running: > > # make make buildworld -jN [...] > > Note the extra 'make', which rather than relying on the bootstrap-tools > to determine which make to build, I am specifically telling it to build > fmake. Nice! That works! Thanks. -- Craig ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 17, 2014, at 3:14 PM, Glen Barber wrote: > On Tue, Jun 17, 2014 at 01:43:55PM -0700, Craig Rodrigues wrote: >> On Tue, Jun 17, 2014 at 1:05 PM, Simon J. Gerraty wrote: >>> Why not use fmake in that scenario? >> >> That might work. Is using the devel/fmake port sufficient for using fmake? >> If I typed "make something", is there a way inside the make environment to >> detect if bmake or fmake was invoked, and error out appropriately? >> > > For what it is worth, I'm working around this problem by running: > ># make make buildworld -jN [...] > > Note the extra 'make', which rather than relying on the bootstrap-tools > to determine which make to build, I am specifically telling it to build > fmake. I hit this issue as well, but worked around it by installing fmake (from src) and typing fmake buildworld. Since the testing I was doing was limited, this worked. It also worked when I hit the converse (building 10 on 9). Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Tue, Jun 17, 2014 at 01:43:55PM -0700, Craig Rodrigues wrote: > On Tue, Jun 17, 2014 at 1:05 PM, Simon J. Gerraty wrote: > > Why not use fmake in that scenario? > > That might work. Is using the devel/fmake port sufficient for using fmake? > If I typed "make something", is there a way inside the make environment to > detect if bmake or fmake was invoked, and error out appropriately? > For what it is worth, I'm working around this problem by running: # make make buildworld -jN [...] Note the extra 'make', which rather than relying on the bootstrap-tools to determine which make to build, I am specifically telling it to build fmake. Glen pgpXtrf3JW_Vm.pgp Description: PGP signature
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Tue, Jun 17, 2014 at 8:35 PM, Craig Rodrigues wrote: > Simon, > > Do you know if there is some sort of patch that can be applied to > FreeBSD stable/9 sources so that it can be built on a FreeBSD > 10/stable, or FreeBSD CURRENT > host with bmake? > > I'm trying to build a FreeBSD stable/9 jail on a FreeBSD 10/stable host, > so that > I can build ports inside the jail with poudriere. > i had recently a build failure similar to the one you see below, and it seemed to be due to some (unclear which) missing dependencies that caused two failures: - toolchain fails, and it requires 'buildworld' to properly build a cross environment - races with "make -j X ..." with high X. I ended up doing a sequential build. cheers luigi ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
Craig Rodrigues writes: > On Tue, Jun 17, 2014 at 1:05 PM, Simon J. Gerraty wrote: >> >> On Tue, 17 Jun 2014 11:35:42 -0700, Craig Rodrigues writes: >>>Do you know if there is some sort of patch that can be applied to >>>FreeBSD stable/9 sources so that it can be built on a FreeBSD >>>10/stable, or FreeBSD CURRENT >>>host with bmake? >> >> You would likely need to apply many of the changes made in 10. >> IIRC stable/9 has just enough bmake support to be able to build/install >> bmake itself, so that ports can use it. >> >> I'm not sure how many people would appreciate making such changes to >> stable/9 at this point. > > Most users would not care about building stable/9 on a stable/10 host. > There are only a few people care about being able to do that. > People who use poudriere to build a jail to build ports would care. Couldn't they just build the base in that same jail? ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
On Tue, Jun 17, 2014 at 1:05 PM, Simon J. Gerraty wrote: > > On Tue, 17 Jun 2014 11:35:42 -0700, Craig Rodrigues writes: >>Do you know if there is some sort of patch that can be applied to >>FreeBSD stable/9 sources so that it can be built on a FreeBSD >>10/stable, or FreeBSD CURRENT >>host with bmake? > > You would likely need to apply many of the changes made in 10. > IIRC stable/9 has just enough bmake support to be able to build/install > bmake itself, so that ports can use it. > > I'm not sure how many people would appreciate making such changes to > stable/9 at this point. Most users would not care about building stable/9 on a stable/10 host. There are only a few people care about being able to do that. People who use poudriere to build a jail to build ports would care. People who are building products base on stable/9, but need to use a stable/10 (or newer) host would care, but that number of people is small. > >>I'm trying to build a FreeBSD stable/9 jail on a FreeBSD 10/stable host, so th >>at >>I can build ports inside the jail with poudriere. > > Why not use fmake in that scenario? That might work. Is using the devel/fmake port sufficient for using fmake? If I typed "make something", is there a way inside the make environment to detect if bmake or fmake was invoked, and error out appropriately? -- Craig ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
On Tue, 17 Jun 2014 11:35:42 -0700, Craig Rodrigues writes: >Do you know if there is some sort of patch that can be applied to >FreeBSD stable/9 sources so that it can be built on a FreeBSD >10/stable, or FreeBSD CURRENT >host with bmake? You would likely need to apply many of the changes made in 10. IIRC stable/9 has just enough bmake support to be able to build/install bmake itself, so that ports can use it. I'm not sure how many people would appreciate making such changes to stable/9 at this point. >I'm trying to build a FreeBSD stable/9 jail on a FreeBSD 10/stable host, so th >at >I can build ports inside the jail with poudriere. Why not use fmake in that scenario? ___ 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: Problems building FreeBSD 9.2 on FreeBSD 10
Simon, Do you know if there is some sort of patch that can be applied to FreeBSD stable/9 sources so that it can be built on a FreeBSD 10/stable, or FreeBSD CURRENT host with bmake? I'm trying to build a FreeBSD stable/9 jail on a FreeBSD 10/stable host, so that I can build ports inside the jail with poudriere. Thanks. -- Craig On Mon, May 19, 2014 at 10:18 AM, Craig Rodrigues wrote: > Hi, > > On a FreeBSD 10 host, I am trying to build this: > > https://github.com/trueos/trueos > > which is derived from FreeBSD 9.2. > > > If I build like this: > > env TARGET=amd64 TARGET_ARCH=amd64 make -j 9 SRCCONF=/dev/null > __MAKE_CONF=/opt/local/branches/freenas/os-base/amd64/make.conf.build > NO_CLEAN=1 buildworld > > I get this error: > > --- upgrade_checks --- > A failure has been detected in another branch of the parallel make > > make[1]: stopped in /opt/local/branches/freenas/FreeBSD/src > *** [upgrade_checks] Error code 2 > > make: stopped in /opt/local/branches/freenas/FreeBSD/src > 1 error > > > If I remove the "-j 9", then I can get the build to work properly. > > Does anyone know what fixes I can pull in from stable/9 or > HEAD so that I can get this to build successfully with the "-j 9" flag without > failing? > > I saw similar problems reported in these discussion threads, but I > didn't see what the solution to the problem was: > > http://lists.freebsd.org/pipermail/freebsd-stable/2014-January/077142.html > http://lists.freebsd.org/pipermail/freebsd-stable/2013-November/075773.html > > > -- > Craig ___ 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"
