On 2007-07-30 09:24, Tom Evans <[EMAIL PROTECTED]> wrote: >On Sat, 2007-07-28 at 17:55 +1000, Peter Jeremy wrote: >> On 2007-Jul-27 17:32:35 +0100, Tom Evans <[EMAIL PROTECTED]> wrote: >> >gcc on amd64 is capable of generating i386 code, but ld on amd64 is >> >incapable of linking i386 code together without serious amounts of work. >> >> Can you elaborate on what you mean by "incapable of linking i386 code"? >> The stock ld can definitely link i386 code: >> turion% ld -V >> GNU ld version 2.15 [FreeBSD] 2004-05-23 >> Supported emulations: >> elf_i386_fbsd >> elf_x86_64_fbsd >> turion% >> >> There is a problem that the 32-bit pathnames on FreeBSD/amd64 are >> different to the 32-bit pathnames on FreeBSD/i386 (ie an i386 >> executable built on amd64 will point to /libexec/ld-elf32.so.1, >> rather than /libexec/ld-elf.so.1) so the result won't execute on a >> FreeBSD/i386 box - but I don't see that as a problem with ld, rather >> the configuration. > > Sure. By 'incapable of linking i386 code' I mean that the default > toolchain of gcc invoking ld to assemble libraries and object files > into executables is incapable of doing so when compiling i386 code. I > say without serious amounts of work because, as you point out, it is > possible to do.
The default toolchain can link 32-bit code with -B /usr/lib32 path options. This should work fine for the base system binaries. I expect ports compiled without -B will not cooperate very 'smoothly' with 32-bit port builds, but that's a different thing from being completely incapable, I guess. > Any other english sentences you need explaining? That's a bit too harsh. The FreeBSD people are known for their civilized manners, so can we tone things down a bit everyone? :-) _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"