Re: How to handle cross compiling source packages?
On Thu, Apr 13, 2006 at 04:23:20PM +0400, Nikita V. Youshchenko wrote:
> > I guess they ran into the infinite recursion trap.
> > It took hours for me to recognize, analyze and fix it.
>
> No.
> Gccross was added when I already was the maintainer.
> archtable appeared before that.
Oh. This may be either nothing, or an undocumented potential problem.
All I can say is that it works fine for me.
Maybe it's the question whether we really *want* to use dpkg-architecture.
Either it is used more consequently than it is now, or it should be
avoided much more than it is now. See below.
> > > 2. If not, there is a way: create a temporary directory, symlink
> > > target *-config files there, add this directory to the beginning of
> > > the path.
> >
> > Since gccross creates and manages already such a directory, it seems
> > logical to me to fix it in gccross.
> >
> > I'll have to take a deeper look into gccross.
>
> gccross is just a simple wrapper to replace mentions of /usr/lib
> and /usr/include in gcc command line to proper cross paths.
This wrapper only works when the cross compiler isn't referenced by
an absolute path ...
> Maybe code that symlings *-config scripts to the same temporary directory
> should be just added there...
> Btw, does dpkg-cross -b preserve *-config files? Not sure...
As you tell it ... let's see ...
No, currently it doesn't. It seems to me that *-config scripts aren't
handled by dpkg-cross at all.
> > Not directly. An addition to %crossprefixtable should be IMHO
> > unnecessary when $crossprefix is set correctly.
> >
> > In general, I think that get_tool should always use $crossprefix
> > if the given $arch is the current DEB_HOST_ARCH. See below.
>
> No it should not. It should check the binary arch, and choose proper tool.
Here is a misunderstanding. Of course you first check the arch, which
is then passed as argument $arch to get_tool(). If that $arch is
equal to DEB_HOST_ARCH, one should also have a look at $crossprefix.
> > Thanks. But I hope you include my complete patch for proposal 6, as
> > adding something to %std_tools might break things in the current code.
> >
> > As already explained, one cannot blindly set them to:
> > $makeflags_{$var_} = $crossprefix . $std_tools{$var_};
> >
> > This should be handled by get_tool:
> > $makeflags_{$var_} = get_tool($arch, $std_tools{$var_}, $mode);
> >
> > get_tool() is intended to try at first:
> > $crossprefix . $std_tools{$var_}
> > isn't it? So this is exactly what we want.
>
> It is not (see above), but I agree that using get_tool is better than
> prepending prefix. Committed to CVS.
get_tool() has the slight disadvantage (or feature :-)) to return
an absolute path. Thus, the gccross wrappers are not called, but the
original tools instead.
So the gccross wrappers should exist (and prepended on PATH) before the
initialization of $makeflags. However, the dpkg-buildpackage wrapper
calls setup_cross_env() *before* creating the gccross wrappers.
But this is necessary, because the initialized PATH and a correct
$crossprefix are needed to create the gccross wrappers.
So you either change it back (which would be really sad), or you use
just the basename of the tool returned by get_tool. Both solutions
aren't good. The old way fails when using a tool that is not extra
rovided by the cross compiling environment. The other way would cause
the basename to may have a different prefix than $crossprefix, thus
bypassing gccross.
Arghh ... the only solution that doesn't need a complete redesign of
dpkg-cross is to remember the original problem:
Do I use $(crossprefix)ranlib or ranlib?
Exactly this and nothing else does my patch:
patch-dpkgcross-fix-std_tools_2.diff
> > > get_tool is used to find proper tools per binary.
> > > It is required - because sometimes native strip is needed, and
> > > sometimes cross.
> > > Always using cross strip does not work. It is how things worked before
> > > - causing lots of problems. E.g. for cross-gcc packages build.
> >
> > I understand. So my proposal 5 has to be reworked.
> >
> > > Wy adding needed entries to tables won't fit in your case?
> >
> > Because these entries won't work everywhere. I could fix it for my case,
> > but support for other w32 cross compilers (e.g. Cygwin) may still break.
>
> I think that tables should contain entries to all supported targets.
> But printing a warning and using $crossprefix-tool as the last resort (if
> it is in path), may be good idea. If this is ok for you, let me know, and
> I will commit it.
Although I don't think any longer that this is necessary (see below), it's
IMHO still a good idea to do so.
> > One adds proper entries to ostable and maybe cputable, or puts proper
> > values into ~/.dpkg-cross/cross-compile:
> > crossprefix = i586-mingw32msvc-
> > crossdir = /usr/i586-mingw32msvc
>
> I think that this should be done not at crossprefix/crossdir values, but at
> level of 'architecture'. It should be possible to define new
> 'architecture', that will be understood both by [wrapped]
> dpkg-architecture and dpkg-cross, and definition of it should define
> prefix, path and likely other things.
Yes, you are perfectly right. But currently, there's some confusion
between the $crossprefix and the paths returned by get_tool(). I tapped
into that trap, too. Now I got it. As least I hope so.
> It is important to have these parameters constant for a given architecture,
> and not allow to overwrite them for standard architectures. This makes
> depending on -arch-cross packages reliable.
Okay, so the ideal solution would be to ignore dpkg-architecture, right?
Of course, it would be even better to make dpkg-architecture use the
tables of dpkg-cross, or to make it more flexible to reflect at least
the default values correctly. But this is completely unrealistic, isn't
it?
So there's a problem in keeping these 2 domains separately. What should
be handled by dpkg-architecture, what is handled by %crossprefixtable?
I mean, ideally, "dpkg-architecture -a$arch -qDEB_HOST_GNU_TYPE" should
return exactly the same as "$crossprefixtable{$arch}[0]-" ... right?
And $archtable{$arch} should also return that value.
This isn't the case. For example:
* %archtable maps "i386" to "i486-linux-gnu",
* `dpkg-architecture -ai386` shows "i486-linux-gnu"
* but $crossprefixtable{'i386'}[0] is "i386-linux-gnu-"
Why?
In addition, the "dpkg-architecture" tables are somewhat too simplified.
If I add w32 to dpkg/ostable, "dpkg-architecture -aw32-i386" will always
return "i486-...". The only change to make dpkg-architecture use
"i586-..." is to add another dpkg/cputype, too, and refer tp w32-i586
instead of w32-i386. But as this won't be really a new entry, and will
overlap with i386, I really don't like that situation. dpkg-architecture
is simply too inflexible, isn't it?
Do you have any idea how I should handle this? Is a new dpkg/cputype for
i586 really justified?
And what about adding w32 to dpkg/ostable? Should it be included in
dpkg permanently, or should dpkg-cross bypass dpkg-architecture instead?
Anyway, I wrote a patch which adds the correct w32-i386 entries to
%archdetecttable and %crossprefixtable:
patch-dpkgcross-w32-entries.diff
Greets,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Fri Apr 14 04:46:53 CEST 2006 Volker Grabsch <vog@notjusthosting.com>
* fix-std_tools_2
diff -rN -u old-dpkg-cross/dpkg-cross-1.26/dpkg-cross.pl new-dpkg-cross/dpkg-cross-1.26/dpkg-cross.pl
--- old-dpkg-cross/dpkg-cross-1.26/dpkg-cross.pl 2006-04-14 04:47:17.000000000 +0200
+++ new-dpkg-cross/dpkg-cross-1.26/dpkg-cross.pl 2006-04-14 04:47:17.000000000 +0200
@@ -484,7 +484,8 @@
# Set standard variables for compilers and binutils.
foreach $var_ ( keys %std_tools ) {
- $makeflags_{$var_} = get_tool($arch, $std_tools{$var_}, $mode);
+ $tool_ = $crossprefix.$std_tools{$var_};
+ $makeflags_{$var_} = find_in_path($tool_) ne "" ? $tool_ : $std_tools{$var_};
}
# Allow to use $crossprefix-gcc -E as preprocessor if $crossprefix-cpp
Fri Apr 14 05:00:26 CEST 2006 Volker Grabsch <vog@notjusthosting.com>
* w32-entries
diff -rN -u old-dpkg-cross/dpkg-cross-1.26/dpkg-cross.pl new-dpkg-cross/dpkg-cross-1.26/dpkg-cross.pl
--- old-dpkg-cross/dpkg-cross-1.26/dpkg-cross.pl 2006-04-14 05:01:06.000000000 +0200
+++ new-dpkg-cross/dpkg-cross-1.26/dpkg-cross.pl 2006-04-14 05:01:06.000000000 +0200
@@ -94,7 +94,8 @@
's390x' => 'ELF 64-bit MSB .* S.390',
'ia64' => 'ELF 64-bit LSB .* IA-64',
'm32r' => 'ELF 32-bit MSB .* M32R',
- 'amd64' => ' ELF 64-bit LSB .* x86-64',
+ 'amd64' => 'ELF 64-bit LSB .* x86-64',
+ 'w32-i386' => '80386 COFF',
'AR' => 'current ar archive');
# Lists of possible crossprefix'es for each architecture
@@ -116,7 +117,8 @@
"ia64" => [ "ia64-linux-gnu-", "ia64-linux-" ],
"m32r" => [ "m32r-linux-gnu-", "m32r-linux-" ],
"amd64" => [ "amd64-linux-gnu-", "amd64-linux-", "x86_64-linux-gnu-", "x86_64-linux-",
- "x86-64-linux-gnu-", "x86-64-linux-" ]);
+ "x86-64-linux-gnu-", "x86-64-linux-" ],
+ "w32-i386" => [ "i586-mingw32msvc-" ]);
# All environment variables for compiler and binutils with their corresponding
# application name which will be modified for cross-compiling.
Reply to: