svn commit: r266553 - head/release/scripts

[Konstantin Belousov]

On Wed, May 28, 2014 at 01:53:28PM -0600, Warner Losh wrote:
> 
> On May 28, 2014, at 9:47 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> > On Wed, May 28, 2014 at 09:35:27AM -0600, Warner Losh wrote:
> >> 
> >> On May 28, 2014, at 9:28 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> >> 
> >>> On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote:
> >>>> 
> >>>> Then we disagree on this point. However, the disagreement here is
> >>>> kinda foundational: to build a set of libraries or sys root, you have
> >>>> to have a MACHINE_ARCH to make it work. Even in our current system, we
> >>>> set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries
> >>>> (note: we don?t do this for mips). This means that if we do grow x32
> >>>> support, we?ll need to grow a MACHINE_ARCH for it. That?s my point:
> >>>> all ABIs have MACHINE_ARCH associated with them, and those are the
> >>>> names users are used to specifying, and are the ones that are the most
> >>>> natural for script writers to use. With nathan?s patches, we?re to the
> >>>> point where those are used, though there?s also the option of using
> >>>> the non-standard names if you want (e.g. amd64:32 instead of x32).
> >>>> 
> >>> 
> >>> I am not sure if this comment would add anything to the discussion,
> >>> but other build systems do not require MACHINE_ARCH.  In our terms,
> >>> other build systems are happy to build:
> >>> i386 binary when MACHINE is amd64 and CFLAGS contains -m32;
> >>> x32 binary when MACHINE is amd64 and CFLAGS contains -mx32.
> >>> 
> >>> For HEAD and stable/10 we finally reached the point where -m32 works,
> >>> on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least
> >>> this is true for dependencies limited to the base system, and not to the
> >>> ports (the later is since ports do not know about multiarch).
> >>> 
> >>> It is limitation of our build that we require MACHINE_ARCH to build
> >>> other natively supported ABI binary on the host. Ideally, the hacks that
> >>> treat lib32 build as the cross-compilation would go away eventually.
> >> 
> >> I doubt it. The MACHINE_ARCH is used to select which files to build.
> > Do I understand you right that the comment references e.g. a selection
> > of arch-specific subdir in lib/libc or libexec/rtld-elf for inclusion
> > into the build ? If yes, I cannot disagree with the statement.
> 
> As far as I can tell, that?s the only reason we?re doing it..  But it is a critically important reason...
> 
> > My note was about our build system which currently requires
> > full-fledged cross-build to even create i386 binary on amd64 vs. other
> > builds which consider this as a (often minor) variations of the host
> > target. Sure, some variances must be allowed, e.g. to select proper .S
> > file for the ABI, but we do not need cross-build to get i386 on amd64.
> 
> lib32 uses -m32 and some other flags to achieve its ends. So it doesn?t create a full i386 compiler, etc. It just uses the amd64 one with special flags/args. So I don?t think it requires a full-fledged cross-build environment, or I misunderstand what you mean by that phrase.

We install the headers for the MACHINE_ARCH into the compat32 build tree,
and use them instead of the target MACHINE headers.  The fact that
<toolchain> -m32 works as the cross-compiler just saves the build
time.

> 
> But none of this changes the fact that we have a unique MACHINE_ARCH value per ABI.
> 
> Warner


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140529/7cc2b536/attachment.sig>