| 1 | You're reading ./Cross/README.new, describing Perl cross-compilation process. |
| 2 | NOTE: this file will replace ./Cross/README, after the cross-compilation scheme |
| 3 | is stabilized. |
| 4 | |
| 5 | =head1 NAME |
| 6 | |
| 7 | README.new - Cross-compilation for linux |
| 8 | |
| 9 | =head1 DESCRIPTION |
| 10 | |
| 11 | This is second approach to linux cross-compilation, which should allow |
| 12 | building full perl and extensions for target platform. Cross-compilation |
| 13 | for linux uses similar approach and shares the same files as |
| 14 | cross-compilation for WinCE. |
| 15 | |
| 16 | We refer to HOST as the platform where the build is performed, and to |
| 17 | TARGET as where final executables will run. |
| 18 | |
| 19 | =head2 Basic ideas |
| 20 | |
| 21 | =head3 common |
| 22 | |
| 23 | Unlike WinCE, output files from GCC cross-compiler are produced in the same |
| 24 | directory where C files are. All TARGET binaries have different extensions |
| 25 | so to distinguish HOST and TARGET binaries. Namely, object files for C<arm> |
| 26 | cross-compilation will have extension C<.armo>, executable files will have |
| 27 | C<.arm>. |
| 28 | |
| 29 | After typical cross-compilation the following files will be built, among |
| 30 | others: |
| 31 | |
| 32 | sv.c |
| 33 | sv.o |
| 34 | sv.armo |
| 35 | libperl.arma |
| 36 | |
| 37 | (this approach may be reconsidered, however.) |
| 38 | |
| 39 | =head3 build process |
| 40 | |
| 41 | C<miniperl> is built. This executable is intended to run on HOST, and it |
| 42 | will facilitate the remaining build process; all binaries built after it are |
| 43 | foreign (TARGET) and should not run locally (HOST). |
| 44 | |
| 45 | Unlike HOST build, miniperl will not have C<Config.pm> of HOST within reach; |
| 46 | it rather will use the C<Config.pm> from the cross-compilation directories. |
| 47 | In fact, if the build process does have Config.pm within reach, this is only |
| 48 | an indication of a mistake somewhere in the middle. |
| 49 | |
| 50 | # following command is okay: |
| 51 | ./miniperl -Ilib -MCross -MConfig -e 1 |
| 52 | # following command should cluck, and it is bad if it does not: |
| 53 | ./miniperl -Ilib -MConfig -e 1 |
| 54 | |
| 55 | After C<miniperl> is built, C<configpm> is invoked to create an |
| 56 | appropriate C<Config.pm> in the right place and its corresponding |
| 57 | C<Cross.pm>. |
| 58 | |
| 59 | File C<Cross.pm> is dead simple: for given cross-architecture places in @INC |
| 60 | a path where perl modules are, and right C<Config.pm> in that place. |
| 61 | |
| 62 | That said, C<miniperl -Ilib -MConfig -we 1> should report an error, because |
| 63 | it cannot find C<Config.pm>. If it does not give an error, a wrong C<Config.pm> |
| 64 | is substituted, and resulting binaries will be a mess. |
| 65 | |
| 66 | C<miniperl -MCross -MConfig -we 1> should run okay, and it will provide a |
| 67 | correct C<Config.pm> for further compilations. |
| 68 | |
| 69 | During extensions build phase, the script C<./ext/util/make_ext_cross> is |
| 70 | invoked. |
| 71 | |
| 72 | All invocations of C<Makefile.PL> are provided with C<-MCross> so to enable |
| 73 | cross-compilation. |
| 74 | |
| 75 | =head2 BUILD |
| 76 | |
| 77 | =head3 Tools & SDK |
| 78 | |
| 79 | To compile, you need the following: |
| 80 | |
| 81 | =over 4 |
| 82 | |
| 83 | =item * TODO |
| 84 | |
| 85 | =back |
| 86 | |
| 87 | =head1 Things to be done |
| 88 | |
| 89 | =over 4 |
| 90 | |
| 91 | =item * better distinguishing of config.h/xconfig.h, dependencies |
| 92 | |
| 93 | =item * object files created in ./xlib/cross-name/ ? |
| 94 | |
| 95 | =back |