Date: Wed, 15 Aug 2012 20:30:01 +0200 From: Mattia Rossi <mattia.rossi.mate@gmail.com> To: freebsd-arm@freebsd.org Subject: Re: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) Message-ID: <502BEAA9.9080802@gmail.com> In-Reply-To: <1345039837.27688.14.camel@revolution.hippie.lan> References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> <502AEC99.70708@jetcafe.org> <CAJ-Vmok-n_focw5x4nM1Go2c0xRoeU=xehDAtTgeM2%2BtZ94GjA@mail.gmail.com> <48664E9B-0BBB-4C78-B720-9920083E661A@bsdimp.com> <1345039837.27688.14.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
> The biggest problem we have is build versus run dependencies. When > crossbuilding port foo to run on arm, that port decides it needs the > compile_a_foo port to build the code, so it goes off and cross-builds > compile_a_foo, then wants to run the resulting arm binaries on the x86 > host. The only way I know of to fix that is to tediously identify and > pre-build all the build-time requirements needed by any port you > intend to cross-build. Ports that have their own build systems and > custom tools are essentially impossible to work with. Those are exactly the issues I've run into when attempting to cross build. See my story here: http://matrossi.blogspot.it/2011/08/cross-compiling-ports-for-arm-under.html My Qemu experience: http://matrossi.blogspot.it/2011/09/freebsd-arm-on-qemu-in-virtualbox.html but it didn't prove useful for building ports as there wasn't enough virtual memory to build them, because it fully emulates the 32M of RAM of a gumstix board as well.. Just in case you're interested. Mat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?502BEAA9.9080802>