Front page | perl.perl5.porters |
Postings from December 2012
Re: Cross-building and Makefile.SH
Thread Previous
|
Thread Next
From:
Neil Williams
Date:
December 18, 2012 18:26
Subject:
Re: Cross-building and Makefile.SH
Message ID:
20121218182644.97d6bdc172d6fdf0280834a2@debian.org
On Tue, 18 Dec 2012 13:23:55 -0000
"Jess Robinson" <castaway@desert-island.me.uk> wrote:
> On Thu, 13 Dec 2012 13:32:32 -0000, Neil Williams <codehelp@debian.org>
> wrote:
> > The only upstream change is for Makefile.SH :
> >
> > https://github.com/codehelp/perl-cross-debian/blob/master/patches/5.14.2/cross-Makefile.diff
>
> I haven't gotten to changing Makefile.SH yet, I've been doing the
> following:
>
> 1) Build a miniperl for the host system, in a separate host/ subdir (which
> has had ../Configure -Dmksymlinks run in it).
> 2) Ditto generate_uudmap
> 3) symlink/copy both of the above to the main dir which will build the
> cross-compiled Perl.
> 4) Build perl as otherwise normal.
> (See https://github.com/castaway/perl/wiki which is, oops, slightly out of
> date, but more or less correct)
>
> This currently fails at the point where it requires RUN_PERL, as I don't
> have a runnable one.
>
> Your Makefile.SH patch looks like it makes a lot of sense for the
> miniperl/hostperl parts, I'll try applying it to my bleadperl. That will
> save me my extra manual symlinking/file copying.
>
> I'd prefer the CROSS_PERL variable be named HOST_PERL or similar,
That sounds fine, the use of the variable in Debian is:
+ [ ! -f Makefile ] || $(MAKE) distclean CROSS_PERL=$(HOST_PERL)
:-)
So HOST_PERL=$(HOST_PERL) is clearer.
> since it
> sounds like its a cross-built perl at the moment, which is the opposite of
> the intention. Thinking a bit more about this on the fly, I'm going to
> need to detect and store (in %Config) a path-to-host-perl, which can be
> used for building / cross-compiling modules on the host for use on the
> target, later on. So I'll probably have it set RUN_PERL to that, if
> available, and you can stuff your detected Perl into the config.sh instead
> of passing it as an argument.
OK.
> The only part I'm puzzling over is, what is the reason for:
>
> +# Cross building requires a separate target to allow manipulation of the
> build tree
> +extensions: $(dynamic_ext) $(nonxs_ext)
These changes have evolved over quite a long period of time. I have
been updating the patches for 5.14 and 5.16 and this change has raised
queries with the perl maintainers in Debian too.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633884#17
"Nearly all of the changes to Makefile.SH are isolated within
conditionals utilising CROSS_PERL except one - the extensions target.
This could do with some more testing but it is mainly to support the
alternative extensions build target to avoid some of the work needed by
the 'all' target. It could also be useful in the generation of the cache
files themselves as the content of the generated headers are common to
some combinations of architecture. It *should* make it easier to
prevent the kind of errors which have tripped me up once already. [1]
I hope to use this target *on native* machines to only generate the
extensions data to try and debug similar problems."
So this is an interim step, it might not be necessary when the final
system is implemented, subject to just how the generated_headers output
is created and updated.
> Also I think I'll need to find a way to actually generate the uudmap +
> bitcount files, rather than ignore them and just steal the host ones.
Yes, I haven't got a way to generate those other than to prepare a set
of data for each architecture candidate. So far, I've only got data for
armel (ARMv5) and armhf (ARMv7) with ARMv8 pending. I'm going to seek
out a wider range of data for mips and other Debian architectures to
try and isolate whether these files change and how.
The extensions target can help prepare the headers by running stages of
the perl build on native machines.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Thread Previous
|
Thread Next