Re: How to handle cross compiling source packages?
On Thu, Apr 13, 2006 at 01:15:39PM +0400, Nikita V. Youshchenko wrote:
> > 2. use /etc/dpkg-cross/cross-config.$(DEB_HOST_ARCH_OS)
> > -------------------------------------------------------
> >
> > The files cross-config.* contain a suffix for each architecture.
> > Some suffixes are CPU type, but most are OS types.
>
> I feel a bit uncomfortable with replacing one broken thing with another
> thing that is likely broken also.
Okay. It seems that I don't rely on this, anyway.
> > 3. use dpkg-architecture instead of %archtable
> > ----------------------------------------------
>
> I agree that this is the way to go - but
> *) probably reverse change was done by previous dpkg-cross maintainers for
> a reason?
I guess they ran into the infinite recursion trap.
It took hours for me to recognize, analyze and fix it.
> *) doesn't this change need more general rework of usage of $arch and
> similar over all dpkg-cross code?
> Maybe this is also for the new maintainer(s)?
I agree.
However, until now I try to keep my patches as small as possible.
I'd like to see them in Debian/unstable. Refactoring should start
*after* fixing the w32 issues and releasing them. IMHO.
> > Since dpkg-architecture only needs programs in /usr/bin, that
> > problem can be solved by setting PATH=/usr/bin before calling
> > dpkg-architecture.
>
> Better not to set PATH to /usr/bin, but to remove /usr/share/dpkg-cross
> from $PATH
You are right. I'll fix it.
> > I don't supply a patch, because I'm unsure how to solve that
> > problem. Does anyone use dpkg-cross to build applications that
> > use glib-config, gtk-config, sdl-config or similar?
>
> 1. Does not gccross make host *-config files to do intended thing?
That's possible. However, it doesn't work for sdl-config.
Maybe sdl-config has to get a symlink "i586-mingw32msvc-sdl-config".
Hoever, in that case "dpkg-cross -b" should be changed to rename the
*-config scripts during repackaging.
> 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.
> Why strip wrapped does not work?
> Could you try it from commang-line?
> Probably addition to %crossprefixtable is needed?
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.
> It's new information for me that ar and ranlib are architecture-dependent.
At least they don't work for w32. :-)
May it's because w32 uses DLL instead of SO.
> Quite strange for ar - it just creates an archive...
Well, this might be an exception. But when a cross compiling environment
supplies its own tool, one should use it.
> nm also surprises me - it only parses ELF, doesn't it?
Maybe, but in fact it simply doesn't work, while "i586-mingw32msvc-nm"
does work for me.
> Anyway, added nm, ar, ranlib and windres to %std_tools. In CVS.
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.
> 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.
My thoughts were as follows:
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
If this information is given, why not use it? At least if $arch is
the current target architecture, this information can and should
be used, and should always take precedence.
(the current code seems to try that, but isn't successfull if
the architecture and/or crossprefix are not mentioned in
%crossprefixtable)
I see that my proposed patch doesn't solve that problem properly.
But I do think that get_tool() should never break on architectures
just because they aren't mentioned in %crossprefixtable.
Searching for the correct "strip" is really cool. But if one doesn't
need this feature (e.g. one only cross compiles libSDL), one shouldn't
be forced to manipulate %crossprefixtable.
BTW, get_tool() takes a $mode argument. What is this good for? Is it
documented somewhere? I always see functions either passing it or
setting it to "default". What are the other possible values? What do
they mean?
Greets,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Reply to: