blob: 398188bbeedcd1e63ab2a9441f37d9569755468e (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
Temporary readme:
Examples:
OSX:
x64:
./configure --host=x86_64-apple-darwin # (defaults chosen)
x86:
./configure --host=i386-apple-darwin
IOS:
./configure --host=arm-apple-darwin # (defaults chosen)
./configure --host=arm-apple-darwin --with-sdk=4.3 --prefix=home/foo/xbmc-deps
Android (the pathes are examples and have to match those of docs/READM.android):
arm:
./configure --with-tarballs=/opt/xbmc-tarballs --host=arm-linux-androideabi --with-sdk-path=/opt/android-sdk-linux --with-ndk=/opt/android-ndk-r10d --with-toolchain=/opt/arm-linux-androideabi-4.8-vanilla/android-17 --prefix=/opt/xbmc-depends
x86:
./configure --with-tarballs=/opt/xbmc-tarballs --host=i686-linux-android --with-sdk-path=/opt/android-sdk-linux --with-ndk=/opt/android-ndk-r10d --with-toolchain=/opt/x86-linux-4.8-vanilla/android-17 --prefix=/opt/xbmc-depends
Linux:
ARM toolchain (codesourcery/lenaro/etc)
./configure --with-toolchain=/opt/toolchains/my-example-toolchain/ --prefix=/opt/xbmc-deps --host=arm-linux-gnueabi
RASPBERRY-PI:
PATH="/opt/rbp-dev/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin:$PATH" ./configure --with-platform=raspberry-pi --host=arm-linux-gnueabihf --prefix=/opt/xbmc-deps --with-tarballs=/opt/xbmc-tarballs --with-toolchain=/opt/rbp-dev/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/arm-bcm2708hardfp-linux-gnueabi/sysroot --with-firmware=/opt/rbp-dev/firmware --build=i686-linux
Native toolchain
./configure --with-toolchain=/usr --prefix=/opt/xbmc-deps --host=x86_64-linux-gnu
Details:
We build a native tools for platforms that do not have the native tools we need. OSX is
the largest builder of native tools as there is not much present. No cmake, no autotools, etc.
Cross compiling is a real pain is the rear :) Generally there are three forms,
autotools (configure/make), cmake driven, and hand crafted makefile. In term
of usage, 90 percent are autotools, followed by cmake and hand crafted makefiles.
Some libs need patching, most do not. Lib versions are picked for a reason, be prepared
for robust testing if you go bumping libs. Never commit bumps unless you have also done
a complete distclean nuke of EVERYTHING and rebuild from scratch on ALL platforms.
Epic fail if this is not tested.
1) autotool driven tend to be simple PROVIDED the authors followed proper autotool format.
Try with $(CONFIGURE) 1st, if problem, try adding $(AUTORECONF) -vif before the
$(CONFIGURE). Some are do silly things and only a config.site can correct the errors.
So watch for this in the config.site.in. config.site rules and this is the only way
to handle bad autotool behavior.
2) cmake driven tend to be simple, setup cmake flags right and go. On rare cases, you might
need to diddle the native cmake setup.
3) hand crafted Makefiles typically require manual sed tweeks or patching.
|
