[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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 

> 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 

> 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.


Reply to: