Add generic cross-compile support

[CodingCellist]

Having previously needed to cross-compile this for use in simulation (but used a native platform for compilation, then copied the files), I have made an attempt at making this cross-compile in general.

There are some problems with getting volrend's libtiff to cross-compile successfully, and I have been unable to resolve these. Any help would be greatly appreciated!

[SakalisC]

It might be possible to link with a system version of libtiff for volrend instead of using the bundled version, which might solve the compilation issues. We have been able to compile for ARM targets before, but I can't remember if we used the bundled version or the system one.

Regarding support for cross-compilation in general, CC is already a variable, so it's possible to replace it with any compiler, I don't think you need to use the CROSS_COMPILE prefix. Similarly, I think it makes more sense to make ar into a variable as well, so that it can be set to the correct binary for the target. Finally, I am fairly certain it is possible to link with dynamic libraries when cross-compiling, so why is the -static flag hardcoded when cross-compiling?

[CodingCellist]

Compiling with the system version of libtiff unfortunately doesn't seem to work when cross-compiling (which I guess makes sense given that the shared library will have been compiled for the guest OS architecture). However, I did manage to get volrend to compile by downloading and cross-compiling libtiff from its website, so thank you very much for that idea!

The CROSS_COMPILE prefix, as far as I know, is there so that variables like CC, LD, AR, etc. can be conveniently prefixed with CROSS_COMPILE instead of having to export/define each one when wanting to use a different tool.
Regarding the -static flag: It is hardcoded because for simulations, it can be difficult to have all the right libraries and tools installed in the right place on the virtual disk. Or at least, I found it to be the simpler approach for something like gem5 full system simulations, as opposed to configuring something like buildroot.

[SakalisC]

Alright, I guess it makes more sense to have a prefix instead of having to change all the different variables. I am nitpicking, but would it make sense to rename the CROSS_COMPILE variable to something a bit more generic and self-explanatory, such as TOOLCHAIN_PREFIX or something similar?

Regarding -static, it makes sense with gem5, but I don't think we should have it hardcoded in the Makefile, since the Makefile is not gem5 specific.

[CodingCellist]

Yes, TOOLCHAIN_PREFIX works as well. I picked CROSS_COMPILE because that seems to be what the Linux kernel uses, but I agree that having one with a clearer meaning is a good idea.

I'll remove the -static.

[SakalisC]

Thank you,this should be useful for a lot of people.