Re: How to handle cross compiling source packages?
> > *) 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.
No.
Gccross was added when I already was the maintainer.
archtable appeared before that.
> > > 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.
gccross is just a simple wrapper to replace mentions of /usr/lib
and /usr/include in gcc command line to proper cross paths.
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...
> > 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.
No it should not. It should check the binary arch, and choose proper tool.
Alternative is to depend on binutils-multiarch - but in past embedded
people disliked this solution. And I agree it is ugly to install both
binutils-multiarch to get cross-stip, and binutils-$arch to get
cross-assembler.
> 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 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.
> 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.
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.
> 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)
This code is pretty old and could be buggy.
> 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.
Isn't it not question about compiling libSDL, but about supporting your
target?
> 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?
This was added for people who wished to have ability to use different
toolchains for the same arch (e.g. standard gnu toolchain, and a
commercial toolchain). This is used in tool selection, and in additional
variable setting.
Maybe better to incorporate it in 'new arch definition' - don't know.
Nikita
Reply to: