Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE)

[Warner Losh]

On Aug 15, 2012, at 12:56 PM, Adrian Chadd wrote:

> On 15 August 2012 07:10, Ian Lepore <freebsd at damnhippie.dyndns.org> wrote:
> 
>>> I have the basics, and have for years.  I've posted them several times.  The trouble is that they are very very basic and need more work.  I think you'll need to define the problem a little better before progress can be made.
> 
> Right.
> 
>> The system we use at work is basically Warner's (at least I think he put
>> the bulk of it in place years ago).  It involves defining a bunch of
>> environment variables that change how ports are built (I want to say
>> "fools" or "tricks" the ports into using cross-tools, but the negative
>> implications of those words may just reflect my ignorance of the
>> details).
> 
> Right.
> 
>> 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.
> 
> Well we have build tools as a make stage in building things in
> /usr/src. I know, I keep adding things to it when adding stuff for
> cross-building things.
> 
> So if we know _how_ to mark something as a build time versus run time
> dependency, wouldn't that be good to add to the ports infrastructure?
> 
> Yes, we can't cross-build _all_ports. But a bunch of basic ones to
> begin with would be nice (eg things like thttpd, dropbear.) Ports with
> their own build systems and custom tools can stay out of it for this
> pass.
> 
> I was hoping that others with a little more build experience could be
> coaxed into hacking on the problem. I find it really disenheartening
> that the OpenWRT peeps figured this out years ago and yet we can't
> even make a _start_ on it in /usr/ports.

Now that ports is in svn, maybe we need a projects/xports to get started.  We could dump my crap there, and then start to work out the build vs run issues and go from there.

This is a very time-intensive project, but with enough hands, and a place to save the work so we don't start from scratch each time, I think we can make progress.  Lots of the nay-sayers will STFU if we get to the point of building some useful number of ports this way (say 100).  And if it fails, we can delete the branch :)

Warner