Warner Losh wrote:
> You'll need to do this for all binutils as well.
I already build binutils with multi-architecture support. On alpha,
I have "CROSS_TOOLS= i386 m68k" in my /etc/make.conf and at the
end of a make world I have one ld that knows all the formats. Only
gas is a special case, so I have "as" (the alpha ELF one), as_i386
(the cross ELF assembler) and as_m68k. At the moment the FreeBSD
build drops the extra two in /usr/libexec/elf, which is wrong for
egcs.
> That would preclude us from porting to an architecture named "ftpd" or
> any other program that is in /usr/libexec. I think you want to put a
> /arch/ before the ${TARGET}, if you go down this path...
Ah, yes, point taken.
> Also, I think that your notion of running
> make world INCLUDE_THESE_OTHER_TARGETS="mips m68k"
> and then building the world (somehow) with these cross tools differs
> from my world view. In my world view (which may be wrong, but was
> what I arrived at after many false starts down other paths), one would
> build the entire system with make buildworld. I do see the utility in
> being able to do it other ways. But it would require more than just
> programs to make it work.
You're concentrating on porting FreeBSD. I'm trying to improve my
cross-compilation environment for my third-party code. In particular,
I still use VxWorks targeted to m68k (and also alpha). I will get a
faster build if I do it on i386 rather than my slower Alpha OSF/1
machine.
To build VxWorks stuff cross compiled under OSF/1, I set:
GCC_EXEC_PREFIX=/usr/opt/VXW310/bin/gnu/lib/
CPU=MC68020
AR=ar68k
CC=cc68k
LD=ld68k
and include /usr/opt/VXW310/bin/gnu in PATH.
These are the names and paths that DEC and Wind River use for the
VxWorks product that DEC sells (or did before being absorbed into Compaq).
To cross build FreeBSD code one one architecture for another should
be no more difficult once the Makefiles have been massaged.
> I suspect that /usr/libexec/${TARGET} will prove to be too limited to
> work in practice, especially for an entire buildworld (although I can
> see how it could be made to work for kernel builds). I think we'd
> need to have a /usr/cross/${TARGET}-${TARGET_ARCH}/ tree where the
> libraries needed for linking, the include files that are specific to
> each port, etc live. Then one could just set one's path to have
> /usr/cross/${TARGET}-${TARGET_ARCH}/bin in your path and then make
> from there anything you'd like. That would also allow us to have as
> many different binaries as we need to build the world and we'd be
> decoupled from any hacks to make binutils work. While this approach
> would work well for kernel development, I don't see how it would work
> well for development where libc is linked in.
I was referring to TARGET=elf32-i386, for example. In a cross build mode,
setting DESTDIR would be required rather than optional, but that
path can't be in PATH because it contains only files in the target
format, not tools that run on the host.
> P.S. /usr/cross is what OpenBSD uses, but I'm not married to that
> name.
Does OpenBSD use /usr/cross for the location of the cross _tools_,
or as the root of the target specific DESTDIR? I guess it is for the
tools.
--
John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
