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).
-Nathan
_______________________________________________
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"
