Re: dpkg-cross proposals

[Volker Grabsch <vog@notjusthosting.com>]

Dear dpkg-cross Developers,

here are some more improvements.


5. bugfix in get_tool
---------------------

    I had the problem that many tools were not found. The reason
    was a bug in function get_tool() in dpkg-cross.pl.
    This function uses %crossprefixtable, a kind of dpkg-cross
    internal replacement for dpkg-architecture. This works well
    for the architectures already mentioned there, but fails
    dramatically when using a new archtecture such as "w32".
    It caused a lot of subtle bugs and was hard to analyze.
    Luckily I was finding that bug.

    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.

    Since $crossprefix is initialized by setup(), but get_tool()
    may be called without setup(), it has to recompute $crossprefix,
    i.e. to call dpkg-buildpackage for itself. I know that this
    introduces a small amount of code redundance in get_tool(), but
    it's much better than calling setup() just for this trivial task.

    This is fixed by:
        patch-dpkgcross-fix-get_tool.diff


6. additions to %std_tools
--------------------------

    The %std_tools is a hash table with entries like
        CC => "gcc"
    for setting the correct environment variables for make. The
    problem is that these variables are blindly set to:

        $makeflags_{$var_} = $crossprefix . $std_tools{$var_};

    i.e. CC is always set to ${crossprefix}gcc. This may cause
    trouble if an architecture doesn't provide i.e. an own
    variant of "ld".

    Instead, if you use get_tool() for that task, it will fail
    back to /usr/bin/ld if no ${crossprefix}ld has been found:

        $makeflags_{$var_} = get_tool($arch, $std_tools{$var_}, $mode);

    Another advantage is that you don't need to fear new entries
    in %std_tools. For example, the mingw32 package provides an
    extra i586-mingw32msvc-ranlib. Many other cross compilers don't.
    A comment in the dpkg-cross.pl even states that ranlib is platform
    independent, which obviously isn't the case.

    Now we're able to include as much as possible in %std_tools, as
    this won't break anything. For w32, I added:
        NM => "nm"
        AR => "ar"
        RANLIB => "ranlib"
        RC => "windres"

    This is fixed by:
        patch-dpkgcross-fix-std_tools.diff

    Now my programs compile successfully without any PATH manipulation.
    (except those who need SDL or similar, as the wrong sdl-config is
    called)


I hope that my 5 patches will be included in dpkg-cross.

However, the PATH problem (nr. 4) is still present. :-(  Any ideas?


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

Thu Apr 13 02:34:34 CEST 2006  Volker Grabsch <vog@notjusthosting.com>
  * fix-get_tool
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-13 02:35:03.000000000 +0200
+++ new-dpkg-cross/dpkg-cross-1.26/dpkg-cross.pl	2006-04-13 02:35:03.000000000 +0200
@@ -432,6 +432,11 @@
 		return $t_ if ($t_);
 	}
 
+	chomp ($deb_host_gnu_type = `PATH=/usr/bin dpkg-architecture -a$arch -qDEB_HOST_GNU_TYPE 2>/dev/null`);
+	$crossprefix ||= $ENV{'CROSSPREFIX'} || "${deb_host_gnu_type}-";
+	my $t_ = find_in_path($crossprefix . $tool_);
+	return $t_ if ($t_);
+
 	if (defined($crossprefixtable{$arch_})) {
 		my @l_ = @{$crossprefixtable{$arch_}};
 		# move $crossprefix to the first place in the list

Thu Apr 13 02:46:27 CEST 2006  Volker Grabsch <vog@notjusthosting.com>
  * fix-std_tools
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-13 02:47:01.000000000 +0200
+++ new-dpkg-cross/dpkg-cross-1.26/dpkg-cross.pl	2006-04-13 02:47:01.000000000 +0200
@@ -120,8 +120,7 @@
 
 # All environment variables for compiler and binutils with their corresponding
 # application name which will be modified for cross-compiling.
-# For binutils, only LD and AS make sense: for strip we have
-# a wrapper, ar and ranlib are archiecture-indepndent.
+# For strip we have a wrapper, so it isn't mentioned here.
 %std_tools = (
 	CC => "gcc",
 	GCC => "gcc",
@@ -129,7 +128,11 @@
 	CPP => "cpp",
 	IMAKECPP => "cpp",
 	AS => "as",
-	LD => "ld");
+	LD => "ld",
+	NM => "nm",
+	AR => "ar",
+	RANLIB => "ranlib",
+	RC => "windres");
 
 # Contains variable definitions from ``$conffile'' distinguished by their
 # scope ("makeflags" or "environment") of definition.
@@ -492,7 +495,7 @@
 	
 	# Set standard variables for compilers and binutils.
 	foreach $var_ ( keys %std_tools ) {
-		$makeflags_{$var_} = $crossprefix . $std_tools{$var_};
+		$makeflags_{$var_} = get_tool($arch, $std_tools{$var_}, $mode);
 	}
 
 	# Allow to use $crossprefix-gcc -E as preprocessor if $crossprefix-cpp