Re: Cross-compilation to i386

From: Ruslan Ermilov (ru_at_FreeBSD.org)
Date: 03/08/04

  • Next message: Andre Guibert de Bruet: "Re: Load average with CURRENT" 
    Date: Mon, 8 Mar 2004 11:11:37 +0200
To: Francois Tigeot <ftigeot@wolfpond.org>

    On Sun, Mar 07, 2004 at 06:58:53PM +0100, Francois Tigeot wrote:
    > [copy to -current since it may be of help to other freebsd ports]
    >
    > On Thu, Mar 04, 2004 at 06:51:03PM +0100, Francois Tigeot wrote:
    > >
    > > I'm currently running a 5.2.1-RELEASE/amd64 system and I'm trying to
    > > cross-build an i386 world with the following command :
    > >
    > > time nice make buildworld TARGET_ARCH=i386 DESTDIR=/itx
    > >
    > > This fails miserably with these error messages :
    > >
    > > cc -Os -march=c3 -fno-strict-aliasing -pipe -I/usr/src/sbin/gbde/../../sys -DRESCUE -Wsystem -headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer -arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /usr/src/sys/crypto/sha2/sha2.c
    > > {standard input}: Assembler messages:
    > > {standard input}:92: Error: bignum invalid
    > > {standard input}:93: Error: bignum invalid
    > > [more bignum invalid lines]
    >
    > I've managed to make it work.
    >
    > The 'bignum invalid' error is caused by this type of gcc-generated
    > assembly code :
    >
    > .quad 8158064640168781261
    > .quad -5349999486874862801
    >
    > For some reason, as doesn't like big negative numbers.
    >
    I use the attached patch to cross-compile world for 64-bit machines.

    > This is what I did :
    >
    > - I installed a stock copy of binutils compiled with
    > --target=i386-freebsd and --enable-64-bit-bfd
    >
    > - I initiated a buildworld to populate /usr/obj
    >
    > - After the first build failure, I replaced /usr/obj/i386/usr/src/amd64/usr/bin/as
    > with the new assembler, protecting it by a chflags command
    >
    > The world and kernel builds then completed succesfully. The new i386 kernel
    > boots on a diskless machine.
    >
    > Now, I understand a new binutils import was scheduled before 5.3-RELEASE.
    > Is there any reason not to compile it with the '--enable-64-bit-bfd'
    > option on 64-bit architectures ?
    >
    Nice to hear there are other options that do not require patching.
    David, any chance you can investigate the effect of enabling the
    --enable-64-bit-bfd knob?

    Cheers, 

    -- 
Ruslan Ermilov
FreeBSD committer
ru@FreeBSD.org

  • Next message: Andre Guibert de Bruet: "Re: Load average with CURRENT"

    Relevant Pages

    • Re: [PATCH] CodingStyle: add typedefs chapter
      ... The reason we have them for things like pte_t etc. is that there ... then by all means go ahead and use a typedef. ... New types which are identical to standard C99 types, ... covers RTL which is used frequently with assembly language in the kernel. ...
      (Linux-Kernel)
    • Re: Forth for Mac OS X Leopard (Intel) - what are the options?
      ... As I understand it even FreeBSD binaries are elf. ... If the .data section works for the kernel part of xina, ... The official way is to use linker scripts. ... For some reason a normal start address in linux32 is around ...
      (comp.lang.forth)
    • Re: SuSE: migrating tot linux software RAID?
      ... > third machine with a megaraid that crashed because of this kernel ... >> The reason that you had data loss at all... ... > I had backups and successfully restored the system after a full install. ...
      (alt.os.linux.suse)
    • Re: eradicating out of tree modules (was: : Linux Security *Module* Framework)
      ... reasons, won't ever be accepted into the mainline kernel tree, what you ... crashes of "the Linux kernel" caused by some binary-only driver. ... it's still a reason for fixing the real problem. ...
      (Linux-Kernel)
    • Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
      ... Upon completion, it actually frees enough memory that swap-prefetch _could_ help on some boxes, while the real issue is that they should first and foremost dump GNU locate. ... I'm not saying the kernel needs to fix the software itself, but the kernel should try and keep such software from hurting the rest of the system where it can. ... (reading this thread it sometimes seems like the downside is that updatedb shouldn't cause this problem and so if you fixed updatedb there wold be no legitimate benifit, or alturnatly this patch doesn't help updatedb so there's no legitimate benifit) ... it's not that they shouldn't have been swapped out, it's that the reason they were swapped out no longer exists. ...
      (Linux-Kernel)
    • Quantcast