On May 28, 2014, at 11:15 PM, Nathan Whitehorn <nwhiteh...@freebsd.org> wrote:
> On 05/28/14 18:53, Konstantin Belousov wrote: >> On Wed, May 28, 2014 at 01:53:28PM -0600, Warner Losh wrote: >>> On May 28, 2014, at 9:47 AM, Konstantin Belousov <kostik...@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 <kostik...@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. > > Ah, OK. That's probably pointless most of the time now. It was always > pointless on PowerPC and MIPS, since they share the same headers anyway, and > is probably also now unnecessary on x86 now that regular -m32 works. I don't > think ia64 builds lib32 (which would require a real cross-compiler). Yea, this is an area that can likely be cleaned up from the original gross hacks that were necessary before -m32 actually worked. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
