Re: arm specific patches
On Sunday 23 March 2008, Neil Williams wrote:
> On Sun, 2008-03-23 at 11:14 +0000, David Goodenough wrote:
> > In the patches for util-linux, apt, dpkg, gnupg and mktemp there are
> > patches build a file called arm-linux-gnu.cache. This file is then
> > copied into the build tree.
>
> It is put in place by emsource when the patches are applied but it is
> ignored by any non-arm-linux-gnu build - each arch would need their own
> and emsource/emdebuild support this.
That is true of most of them, but not for gnupg which complains that the
file does not exist. So I presume that something is wrong with the gnupg
rules file. Do you want the .build file to look at?
>
> Native builds ignore it completely so your i386 builds do not need any
> cache files, ./configure can run AC_TRY directly because you aren't
> using a cross compiler.
>
> > Now I realise that the patches can not build an architecture specific
> > file, we can not substitute into the diff file names.
>
> One file per arch, one patch per arch. (Until we come up with a better
> solution).
>
> > So would it not be better to create a file called generic.cache,
>
> Already exists - dpkg-cross already has a generic cache file for each
> arch for values that many applications need. Some of the current cache
> values may migrate into there but most are entirely specific to that one
> package.
>
> > and then
> > when the cp is done to copy it into the build tree to convert it into an
> > architecture specific file name:-
> >
> > cp generic.cache build-deb/$DEB_HOST_GNU_TYPE.cache
>
> No. The values themselves differ between architectures, that's why we
> have .cache files in the first place. The value of having
> arm-linux-gnu.cache is that when preparing a build for armel or mipsel,
> you have a head start on *which* cache values may be needed. It is then
> simply a case of looking up those values in the native Debian build log
> and setting them in the new cache file.
>
> The problem with cache files is that the cache values might actually
> change and then we'd be building the wrong setup. A better solution is
> needed but a generic cache file is not it. We need improved support in
> autotools so that AC_TRY automatically has a replacement when cross
> building instead of just dieing which is actually very rude. Overall, I
> would like to see cross-building cleanly supported in autotools with
> some degree of backwards-compatibility, so that an update in autoconf
> would allow many applications to build a ./configure script that does
> not simply die when cross building is detected but I suspect it needs
> changes to hundreds of m4 files across the internet. :-(
OK
>
> > Also, how does the emsource program know which patches are architecture
> > specific, so that it can ignore patches which are not relevant to the
> > architecture you are building?
>
> It doesn't need to - the patch to debian/rules already handles that via
> --cache-file=$(DEB_HOST_GNU_TYPE).cache
>
> i.e. ./configure is passed the architecture-specific cache file but only
> if the DEB_HOST_GNU_TYPE differs from DEB_BUILD_GNU_TYPE. In your case,
> even that is ignored.
David
Reply to: