Re: How to handle cross compiling source packages?
Hello people.
First of all: as I've written before, I don't use debian cross stuff
currently, and I'm ready to give dpkg-cross package to any interested
person.
Just a reminder: Wartan has promised to write a team proposal ...
> 1. small bugfix in DEB_* environment variables
> ----------------------------------------------
>
> While stepping through the sources, I found a nasty typo.
> It causes the DPKG_* environment variables not to be set
> correctly.
Agreed, fix is in CVS.
> 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.
I'm afraid configure vars support is broken, and needs preper redesign and
rework. Separation of os-specific, cpu-specific, 'debian arch'-specific
things; maybe some sort of automatic extraction of needed vars from
configure scripts of debian packages, etc, etc
Probably new maintainer(s) of dpkg-cross will fix this in proper way.
> 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?
*) 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)?
> 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
> 4. modifying the PATH correctly
> -------------------------------
>
> dpkg-cross.pl changes the PATH:
> $ENV{'PATH'} = "/usr/share/dpkg-cross:$ENV{PATH}:$crossbin";
>
> However, when there's e.g. SDL installed, the sdl-config of /usr/bin
> would be used, instead of the correct $crossbin/sdl-config. So the
> $crossbin should take precendence:
> $ENV{'PATH'} = "/usr/share/dpkg-cross:$crossbin:$ENV{PATH}";
>
> In addition, the "strip" wrapper doesn't work for me, and the
> wrong "ranlib" is called. (which isn't patform independent!)
>
> So the only way I currently get it working is by putting $crossbin
> at the first place of PATH:
> $ENV{'PATH'} = "$crossbin:/usr/share/dpkg-cross:$ENV{PATH}";
>
>
> However, on the other hand, the sources contain a comment which
> states that they "append $crossbin, so that cross binaries can
> be found, but native stuff still has precedence (if a package
> wants to compile with 'gcc' a build tool that will be executed,
> for example)."
>
>
> This is a serious problem. Maybe I could bugfix the wrappers and
> include "ar" and "ranlib" in %std_tools. This way cross compiling
> would generally work with $crossbin as the last PATH entry. But
> what's about sdl-config, pkg-config, etc.?
>
>
> 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?
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.
Why strip wrapped does not work?
Could you try it from commang-line?
Probably addition to %crossprefixtable is needed?
It's new information for me that ar and ranlib are architecture-dependent.
Quite strange for ar - it just creates an archive... maybe tar is also
arch-dependent these days? :) nm also surprises me - it only parses ELF,
doesn't it?
Anyway, added nm, ar, ranlib and windres to %std_tools. In CVS.
> The function get_tool() looks for the correct command of
> a given tool on a given platform, i.e. in my case, it should
> tell me that "strip" can be found at
> "/usr/bin/i586-mingw32msvc-strip". To find this command, it simply tries
> some prefixes. However, it just took a look into the internal tables,
> but forgot the abvious solution: using $crossprefix. This is the first
> thing to be tried.
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.
Wy adding needed entries to tables won't fit in your case?
Nikita
Reply to: