Opened 11 years ago

Closed 5 years ago

#1844 closed enhancement (no change required)

Provide a convenience script for cross-compiling Haiku software from Linux et al.

Reported by: andreasf Owned by: bonefish
Priority: normal Milestone: R1
Component: Build System Version: R1/pre-alpha1
Keywords: Cc: tqh
Blocked By: Blocking:
Has a Patch: no Platform: All


Haiku itself uses the Jam build system to setup the search paths for its cross-compiler. For developers wishing to cross-compile GNU autoconf based software, I'm attaching a script to setup appropriate environment variables.

Attachments (1) (1.2 KB) - added by andreasf 11 years ago.
draft shell script

Download all attachments as: .zip

Change History (18)

Changed 11 years ago by andreasf

Attachment: added

draft shell script

comment:1 Changed 11 years ago by andreasf

Cc: tqh added

This initial draft has the following use case:

export HAIKUDIR=/home/you/Haiku/haiku
. path/to/
export PATH=$PATH:$HAIKUDIR/generated/cross-tools/bin
.../configure ...

This script works unchanged for both gcc2 and gcc4 builds.

comment:2 in reply to:  1 Changed 11 years ago by andreasf

Actually, an important detail for recursive configure scripts can be:


comment:3 Changed 11 years ago by tqh

This doesn't work out of the box with Firefox as it uses both native compiler and cross-compiler. The cpp- and ldflags needs to only apply to the cross-compiler. The path-flag is the same as I've used previously so that's ok though.

comment:4 Changed 11 years ago by tqh

Seems that this method might be hard to use for Firefox, unless there is a way to set this for the crosscompiler only. Here is Mozilla crosscompilation doc:

I'll look into this a bit more.

comment:5 Changed 11 years ago by andreasf

I've never compiled Firefox myself. While the page you reference does not seem to set flags or search paths (except for X11), it may not be necessary for you to use my script for Firefox as you could copy and paste the relevant paths directly to that mozconfig file.

But also for other software there may be a need for both cross- and native compilation; as long as our Haiku paths are added last, that shouldn't hurt - assuming we're not adding Haiku-specific CFLAGS/CXXFLAGS/LDFLAGS.

comment:6 Changed 11 years ago by tqh

I'm going to look into it. The best thing would be if we somehow can make the flags specific to the crosscompiler as the LDFLAGS do get in the way. I think it should be possible. It is a good start though.

comment:7 Changed 11 years ago by tqh

I've looked into it, but almost everyone says that the files should be copied. So I guess there is no simpler way for Firefox at least.

comment:8 Changed 11 years ago by andreasf

At least in their trunk CVS, Mozilla are using a GNU autoconf generated configure script; hence a .mozconfig file should theoretically allow you to do

ac_add_options CPPFLAGS="..."
ac_add_options LDFLAGS="..."

as with any other such configure script, except manually putting the relevant paths in there. Could be worth a try.

Alternatively you could try using mk_add_options to mess with the Makefiles directly.

comment:9 Changed 11 years ago by tqh

No, I already do crosscompilation with headers and libs copied. From what I've read it seems to be the recommended way, and especially for Mozilla which builds some tools for the host-platform and some for the target-platform.

It would have been great to be able to config the environment with just a 'source env-script', without needing to copy haiku headers and libs, but apparently the crosscompiling mailing lists says that's how to do it.

The script is good, but I was hoping that it could have been made even more general to fit the more complex cases. (And if we are going to modify things I'd rather modify the crosscompiler setup than a single crosscompilable project)

comment:10 Changed 11 years ago by bonefish

Sorry for ignoring this ticket for a while. We can just add the script to some cozy place in the repository of course, if you guys think there're more people who would want to use it.

I'd much prefer to get Haiku ready for native development, though. As of hrev24567 the optional "Development" package installs the build tool chain for the gcc 2.95.3 build. I think I'll stay a little longer in the gcc 2.95.3 world -- there are more tools that are practically must haves for basic development (like ssh and svn) -- and will then look into the gcc 4 tool chain.

comment:11 Changed 11 years ago by tqh

I don't think there would be any harm done if it was added with some small readme on how to use it. Maybe even a reference to this bug.

comment:12 in reply to:  11 Changed 11 years ago by bonefish

Replying to tqh:

I don't think there would be any harm done if it was added with some small readme on how to use it. Maybe even a reference to this bug.

Any takers for writing such a ReadMe? I suppose it can simply be added as a comment (or --help text) to the script.

comment:13 Changed 11 years ago by andreasf

Feel free to add the script if you see fit. I haven't had the time to use it for some time now, not sure if I have any local changes. You could adapt comments 1 and 2 as preliminary readme.

I actually started this script because I was told gcc4 cross was the way to go, now it's gcc2 native again, a little confusing...!

comment:14 Changed 9 years ago by mmadia

Given the age of this ticket & Haiku's stability, can this be closed --> invalid ?

comment:15 in reply to:  14 Changed 9 years ago by korli

Replying to mmadia:

Given the age of this ticket & Haiku's stability, can this be closed --> invalid ?

As I understand, some packages have now to be cross built for non-x86 archs (arm, ppc) because sources are no longer stored in our repository or the platform is not powerful enough. The ticket is still valid IMO.

comment:16 in reply to:  14 Changed 9 years ago by andreasf

In addition to what korli has said, I think Haiku has the responsibility to allow cross-compilation, whether strictly needed or not.

A script, as originally outlined here, is handy for actively working with changing headers in the working copy. For example, I've cross-compiled signal test apps for x86 SA_SIGINFO, for speed reasons and to facilitate keeping source code changes across haiku.images. Since we have no working ppc userland or Optional Package for x86, I have cross-compiled a ppc Hello World app for my QEMU haiku-user emulator-to-be.

An alternative to a script might be to have some Jam target / script to setup include and lib directories appropriately for standalone use, similar to the development Optional Packages for Haiku itself.

Feel free to lower the priority though.

comment:17 Changed 5 years ago by bonefish

Resolution: no change required
Status: newclosed

There's official support for bootstrapping in the build system, now.

Note: See TracTickets for help on using tickets.