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

[andreasf]

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.

[andreasf]

draft shell script

[andreasf]

This initial draft has the following use case:

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

This script works unchanged for both gcc2 and gcc4 builds.

[andreasf]

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

.../configure ... CPPFLAGS="$CPPFLAGS" LDFLAGS="$LDFLAGS"

[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.

[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: http://www.mozilla.org/build/cross-compiling.html

I'll look into this a bit more.

[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.

[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.

[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.

[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.

http://developer.mozilla.org/en/docs/Configuring_Build_Options#Using_a_.mozconfig_Configuration_File

[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)

[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 r24567 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.

[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.

[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.

[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...!