Peter Wemm wrote this message on Thu, Jan 23, 2014 at 14:48 -0800:
> On 1/23/14, 2:12 PM, John Baldwin wrote:
> > On Thursday, January 23, 2014 4:22:56 pm Bryan Drewery wrote:
> >> On Thu, Jan 23, 2014 at 03:03:42PM -0500, John Baldwin wrote:
> >>> On Thursday, January 23, 2014 2:48:41 pm Bryan Drewery wrote:
> >>>> On Thu, Jan 23, 2014 at 02:39:14PM -0500, John Baldwin wrote:
> >>>>> On Thursday, January 23, 2014 10:42:36 am David Chisnall wrote:
> >>>>>> On 22 Jan 2014, at 22:36, Glen Barber <g...@freebsd.org> wrote:
> >>>>>>
> >>>>>>> It needs to use the build host version, because using (for example)
> >>>>>>> powerpc resulting binary won't work on and amd64 system.
> >>>>>>
> >>>>>> If it's used as part of the build, then it should be part of the
> >>>>>> toolchain
> >>>>> target and we should be using the version built there.
> >>>>>
> >>>>> 'make distribute' is not a normal part of the build (it's not part of
> >>>>> buildworld or installworld). Both mergemaster and etcupdate only run it
> >>>>> after an installworld has been performed, in which case an up-to-date
> >>>>> services_mkdb should already be installed.
> >>>>>
> >>>>> Bryan, what are you running 'make distribute' for? Is this to populate
> >>>>> a new jail from a world build?
> >>>>
> >>>> Yes, poudriere uses this to create jails. It runs:
> >>>>
> >>>> export TARGET_ARCH=...
> >>>> make buildworld
> >>>> make installworld DESTDIR=...
> >>>> make distrib-dirs DESTDIR=... DB_FROM_SRC=1
> >>>> make distribution DESTDIR=...
> >>>>
> >>>>
> >>>> No mergemaster or etc-update is ran, we just install all of the
> >>>> defaults.
> >>>
> >>> Yes, but you are attemping to install a newer jail than the host, and
> >>> strictly
> >>> speaking that isn't supported. (Rather, we only guarantee that a jail
> >>> will work
> >>> so long as its world is older or equal in age to the host.)
> >>
> >> I am aware of *running* newer jails not being suppored, but *building*
> >> seems to be an absolute must to be supported. How else would you
> >> upgrade?
> >
> > A normal upgrade does 'installworld' followed by some sort of /etc updating
> > tool. It doesn't do 'make distribute'. Also, this is related to why one
> > is not guaranteed to be able to do an 'installworld' unless you've booted
> > into
> > the new kernel first (though it often works, and 'make distribute' also
> > often
> > works, but often != always).
> >
> > The thing is, there is no notion of cross-tools, etc. for things like
> > installworld and distribution. We have always expected the host to have
> > ITOOLS that work.
> >
> > Note that this exact situation has happened before back when cap_mkdb and
> > pwd_mkdb grew endianness flags for release cross-builds. The pwd_mkdb
> > flag and the change to enable it in etc/Makefile were both made on the same
> > day. (The cap_mkdb change was made earlier, but that appears to be more
> > a result of the testing cycle for cross-building releases than an
> > intentional delay.)
>
> FWIW, we do this at work and ran into the same problem. We do the same
> things that poudriere does, almost exactly.
>
> We added: "CAP_MKDB_ENDIAN= PWD_MKDB_ENDIAN=" to the "make DESTDIR=/stage
> distribution" phase. This currently works all the way back to stable/4.
>
> Is there a middle ground where we could only specify -l / -b in a cross
> build perhaps?
How about when current ARCH != TARGET_ARCH?
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
