Debian Bug report logs - #453267
dpkg-shlibdeps: support cross-building by scanning required directories

version graph

Package: dpkg-dev; Maintainer for dpkg-dev is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg-dev is src:dpkg.

Reported by: Neil Williams <codehelp@debian.org>

Date: Tue, 28 Aug 2007 20:30:04 UTC

Severity: normal

Tags: patch

Found in version dpkg/1.14.5

Fixed in version dpkg/1.14.17

Done: Neil Williams <linux@codehelp.co.uk>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, debian-embedded@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#439979; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
New Bug report received and forwarded. Copy sent to debian-embedded@lists.debian.org, Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: dpkg-dev: Please support removal of dpkg-cross diversions
Date: Tue, 28 Aug 2007 21:27:56 +0100
[Message part 1 (text/plain, inline)]
Package: dpkg
Version: 1.14.5
Severity: normal
Tags: patch

As outlined on the debian-dpkg lists, I've been testing the removal of
the dpkg-cross diversions of dpkg-buildpackage and dpkg-shlibdeps during
the rewrite of dpkg-cross and I now have two patches (slightly modified
from the last ones posted to the list) that I would like to see in
dpkg-dev as a beginning to a process to merge dpkg-cross back into dpkg.

The first part is to remove the diversions and requires PATH and
environment changes within 'dpkg-buildpackage -a' via a small set of
shell functions provided by dpkg-cross. Cross support for dpkg-shlibdeps
needs a few more PATH changes and a dependency on binutils-multiarch.

Once these patches are included, maybe the shell functions and the
existing cross-config.$arch files can also be merged into dpkg-dev,
leaving dpkg-cross with the original task of preparing foreign shared
objects as Architecture:all packages that can be installed into
/usr/$arch-triplet/lib etc. to make the libraries and headers accessible
to the cross-compiler.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.21-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dpkg depends on:
ii  coreutils                     5.97-5.4   The GNU core utilities
ii  libc6                         2.6.1-1    GNU C Library: Shared libraries

dpkg recommends no packages.

-- no debconf information
[buildpackage.diff (text/plain, attachment)]
[shlibs.diff (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#439979; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #10 received at 439979@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 439979@bugs.debian.org
Subject: reversed patches
Date: Tue, 28 Aug 2007 21:39:40 +0100
[Message part 1 (text/plain, inline)]
Bah!

Patches were the wrong way around. Try these.

The /usr/share/dpkg-cross/buildcross file is part of dpkg-cross 1.99
+2.0.0pre2 which is due to be uploaded to experimental just after pre1
leaves NEW.

dpkg-cross will need to depend on the version of dpkg-dev that includes
these patches before migrating into unstable.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

[buildpackage.diff (text/x-diff, attachment)]
[shlibs.diff (text/x-diff, attachment)]
[Message part 4 (application/pgp-signature, inline)]

Blocking bugs of 283626 added: 439979 Request was from Neil Williams <codehelp@debian.org> to control@bugs.debian.org. (Tue, 28 Aug 2007 21:09:04 GMT) Full text and rfc822 format available.

Blocking bugs of 440929 added: 439979 Request was from Neil Williams <codehelp@debian.org> to control@bugs.debian.org. (Wed, 05 Sep 2007 15:51:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#439979; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Frank Lichtenheld <djpig@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #19 received at 439979@bugs.debian.org (full text, mbox):

From: Frank Lichtenheld <djpig@debian.org>
To: Neil Williams <codehelp@debian.org>, 439979@bugs.debian.org
Subject: Re: Bug#439979: reversed patches
Date: Sun, 23 Sep 2007 13:56:24 +0200
On Tue, Aug 28, 2007 at 09:39:40PM +0100, Neil Williams wrote:
> The /usr/share/dpkg-cross/buildcross file is part of dpkg-cross 1.99
> +2.0.0pre2 which is due to be uploaded to experimental just after pre1
> leaves NEW.
[...]
> --- dpkg.old/scripts/dpkg-buildpackage.sh	2007-08-27 23:23:28.000000000 +0100
> +++ dpkg-1.14.5/scripts/dpkg-buildpackage.sh	2007-08-28 20:06:39.000000000 +0100
> @@ -84,6 +84,18 @@
>  passopts=''
>  admindir=''
>  
> +DPKGCROSSENABLE=0
> +if [ -f /usr/share/dpkg-cross/buildcross ]; then
> + . /usr/share/dpkg-cross/buildcross
> + DPKGCROSSENABLE=1
> +fi
> +
> +function enhance_cross {
> +	if [ $DPKGCROSSENABLE -gt 0 ]; then
> +		setup_cross
> +	fi
> +}
> +

Just to make your life harder ;) I've now decided to convert
dpkg-buildpackage to a Perl script (see head of master branch
in git). Therefor this part of the patch doesn't apply anymore.

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#439979; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #24 received at 439979@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Frank Lichtenheld <djpig@debian.org>
Cc: 439979@bugs.debian.org, Dpkg List <debian-dpkg@lists.debian.org>
Subject: Re: Bug#439979: reversed patches
Date: Sun, 23 Sep 2007 14:11:25 +0100
[Message part 1 (text/plain, inline)]
On Sun, 23 Sep 2007 13:56:24 +0200
Frank Lichtenheld <djpig@debian.org> wrote:

> On Tue, Aug 28, 2007 at 09:39:40PM +0100, Neil Williams wrote:
> > The /usr/share/dpkg-cross/buildcross file is part of dpkg-cross 1.99
> > +2.0.0pre2 which is due to be uploaded to experimental just after pre1
> > leaves NEW.
> [...]
> > --- dpkg.old/scripts/dpkg-buildpackage.sh	2007-08-27 23:23:28.000000000 +0100
> > +++ dpkg-1.14.5/scripts/dpkg-buildpackage.sh	2007-08-28 20:06:39.000000000 +0100
> > @@ -84,6 +84,18 @@
> >  passopts=''
> >  admindir=''
> >  
> > +DPKGCROSSENABLE=0
> > +if [ -f /usr/share/dpkg-cross/buildcross ]; then
> > + . /usr/share/dpkg-cross/buildcross
> > + DPKGCROSSENABLE=1
> > +fi
> > +
> > +function enhance_cross {
> > +	if [ $DPKGCROSSENABLE -gt 0 ]; then
> > +		setup_cross
> > +	fi
> > +}
> > +
> 
> Just to make your life harder ;) I've now decided to convert
> dpkg-buildpackage to a Perl script (see head of master branch
> in git). Therefor this part of the patch doesn't apply anymore.

It isn't a problem - this is a workaround patch. Guillem doesn't want
the external lookup involved in the workaround, he wants an internal
solution. The perl version simply needs to implement the functionality
of setup_cross which, in turn, needs to setup and use a directory of
symlinks that are only in the PATH when cross-compiling and which allow
the command line paths passed to the cross-compiler to be manipulated
in real time to set the actual location of the cross header and -dev
package contents.

$args =~ s,/usr/include/,/usr/$arch_type/include/;
where $arch_type is "arm-linux-gnu", for example, retrieved from
dpkg-architecture (which in turn is set by the -a switch).

That functionality is available as gccross in the dpkg-cross source at
the moment and could be implemented that way in dpkg -
dpkg-buildpackage just needs to setup the PATH to put the directory
containing gccross first.

http://alioth.debian.org/plugins/scmcvs/cvsweb.php/dpkg-cross/buildcross?rev=1.1;content-type=text%2Fplain;cvsroot=dpkg-cross


-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#439979; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #29 received at 439979@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Neil Williams <codehelp@debian.org>, 439979@bugs.debian.org
Subject: Re: Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
Date: Wed, 28 Nov 2007 08:55:35 +0100
user dpkg@packages.debian.org
clone 439979 -1
reassign 439979 dpkg-dev 1.14.5
reassign -1 dpkg-dev 1.14.5
retile 439979 dpkg-buildpackage: support cross-building by setting up the environment
usertag 439979 dpkg-buildpackage
retitle -1 dpkg-shlibdeps: support cross-building by scanning required directories
usertag -1 dpkg-shlibdeps
thanks

On Tue, 28 Aug 2007, Neil Williams wrote:
> As outlined on the debian-dpkg lists, I've been testing the removal of
> the dpkg-cross diversions of dpkg-buildpackage and dpkg-shlibdeps during
> the rewrite of dpkg-cross and I now have two patches (slightly modified
> from the last ones posted to the list) that I would like to see in
> dpkg-dev as a beginning to a process to merge dpkg-cross back into dpkg.

Okay, to make it easier to not loose track of this I properly reassigned
this to dpkg-dev and split it in two issues: one for dpkg-buildpackage and
one for dpkg-shlibdeps.

Contrary to what Hector forwarded from you on -devel, the changes for
dpkg-shlibdeps are relatively independant from the rest and since I've
been doing the work on dpkg-shlibdeps I can review and merge a good patch
of you.

If you don't provide the patch, it'll take some more time but I'll get
around to it sometime.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/




Bug 439979 cloned as bug 453267. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Wed, 28 Nov 2007 07:57:02 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #36 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 453267@bugs.debian.org
Cc: debian-dpkg@lists.debian.org
Subject: Re: Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
Date: Wed, 28 Nov 2007 10:22:11 +0000
[Message part 1 (text/plain, inline)]
Raphael Hertzog wrote:
> On Tue, 28 Aug 2007, Neil Williams wrote:
>> As outlined on the debian-dpkg lists, I've been testing the removal of
>> the dpkg-cross diversions of dpkg-buildpackage and dpkg-shlibdeps during
>> the rewrite of dpkg-cross and I now have two patches (slightly modified
>> from the last ones posted to the list) that I would like to see in
>> dpkg-dev as a beginning to a process to merge dpkg-cross back into dpkg.
> 
> Okay, to make it easier to not loose track of this I properly reassigned
> this to dpkg-dev and split it in two issues: one for dpkg-buildpackage and
> one for dpkg-shlibdeps.
> 
> Contrary to what Hector forwarded from you on -devel, the changes for
> dpkg-shlibdeps are relatively independant from the rest and since I've
> been doing the work on dpkg-shlibdeps I can review and merge a good patch
> of you.

I thought Guillem wanted to review the use of /usr/arm-linux-gnu/lib and
/usr/arm-linux-gnu/include ? I do have perl code that solves the problem
(used it to cross build GPE for Emdebian) involving adding search
directories to LD_LIBRARY_PATH but I wasn't sure if Guillem was looking
at a different implementation for those directories.

CC'ing debian-dpkg to find out.

Guillem: what are your plans for the diversion replacements?

Are you planning on changing the current usage of /usr/$arch/include
etc. or just changing the way that the diversion used to use a temporary
directory of symlinks or something else? Should Raphael and I work on a
solution for dpkg-shlibdeps using LD_LIBRARY_PATH using the example below?

> If you don't provide the patch, it'll take some more time but I'll get
> around to it sometime.

This is the core of what would be the patch:

my $crossprefix = &check_arch($arch);
#(check_arch takes a user-specified string and checks that
#dpkg-architecture supports it, then returns the triplet so for 'arm',
# e.g. $crossprefix="arm-linux-gnu";

my @librarypaths = qw( /lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
        /emul/ia32-linux/lib /emul/ia32-linux/usr/lib );

my @shlibdeps = ( "${crossprefix}/lib", "/usr/${crossprefix}/lib",
        "/${crossprefix}/lib32", "/usr/${crossprefix}/lib32",
        "/${crossprefix}/lib64", "/usr/${crossprefix}/lib64",
        "/emul/ia32-linux/lib", "/emul/ia32-linux/usr/lib" );

my $libpath = join (":", @librarypaths) . join (":", @shlibdeps);

$ENV{LD_LIBRARY_PATH}.="$libpath";

That is what I'm using with the current dpkg-shlibdeps from 1.14.11 and
AFAICT it is fine (providing that the cross paths are added to the
standard paths and not replace them or perl gets confused).

If this method is ok, I'll prepare the patch against 1.14.11.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #41 received at 453267@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Neil Williams <codehelp@debian.org>, 453267@bugs.debian.org
Subject: Re: Bug#453267: Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
Date: Wed, 28 Nov 2007 11:50:50 +0100
On Wed, 28 Nov 2007, Neil Williams wrote:
> I thought Guillem wanted to review the use of /usr/arm-linux-gnu/lib and
> /usr/arm-linux-gnu/include ? I do have perl code that solves the problem
> (used it to cross build GPE for Emdebian) involving adding search
> directories to LD_LIBRARY_PATH but I wasn't sure if Guillem was looking
> at a different implementation for those directories.

I don't know what he plan to do, but for dpkg-shlibdeps's part it's clear
that we need to fix the list of directories to search. So I'd be ready to
apply a patch for this part. We can always tweak it later if needed.

> CC'ing debian-dpkg to find out.

Guillem gets the BTS mail, no need for an explicit CC to the list.

> directory of symlinks or something else? Should Raphael and I work on a
> solution for dpkg-shlibdeps using LD_LIBRARY_PATH using the example below?

The real fix doesn't change LD_LIBRARY_PATH but directly the official list of
directories in scripts/Dpkg/Shlibs.pm and also directories listed in
a LD_LIBRARY_PATH submitted by the package might need to be adjusted
in a similar way (s|/usr/lib/|/usr/<arch-triplet>/lib/|) (provided that
the on-the-fly conversion done by dpkg-cross converts all of what's below
/usr/lib/ in packages in that way.

> That is what I'm using with the current dpkg-shlibdeps from 1.14.11 and
> AFAICT it is fine (providing that the cross paths are added to the
> standard paths and not replace them or perl gets confused).

Care to elaborate on why perl gets confused ? 

In any case, since we would _not_ change LD_LIBRARY_PATH, it shouldn't be
a problem.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #46 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 453267@bugs.debian.org
Subject: Re: Bug#453267: Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
Date: Wed, 28 Nov 2007 11:08:14 +0000
[Message part 1 (text/plain, inline)]
Raphael Hertzog wrote:
> On Wed, 28 Nov 2007, Neil Williams wrote:
>> I thought Guillem wanted to review the use of /usr/arm-linux-gnu/lib and
>> /usr/arm-linux-gnu/include ? I do have perl code that solves the problem
>> (used it to cross build GPE for Emdebian) involving adding search
>> directories to LD_LIBRARY_PATH but I wasn't sure if Guillem was looking
>> at a different implementation for those directories.
> 
> I don't know what he plan to do, but for dpkg-shlibdeps's part it's clear
> that we need to fix the list of directories to search. So I'd be ready to
> apply a patch for this part. We can always tweak it later if needed.

OK.

>> CC'ing debian-dpkg to find out.
> 
> Guillem gets the BTS mail, no need for an explicit CC to the list.

Oops. Sorry.

>> directory of symlinks or something else? Should Raphael and I work on a
>> solution for dpkg-shlibdeps using LD_LIBRARY_PATH using the example below?
> 
> The real fix doesn't change LD_LIBRARY_PATH but directly the official list of
> directories in scripts/Dpkg/Shlibs.pm and also directories listed in
> a LD_LIBRARY_PATH submitted by the package might need to be adjusted
> in a similar way (s|/usr/lib/|/usr/<arch-triplet>/lib/|) (provided that
> the on-the-fly conversion done by dpkg-cross converts all of what's below
> /usr/lib/ in packages in that way.

Yes, that sounds good - the only reason I change LD_LIBRARY_PATH right
now is because dpkg-shlibdeps reads that variable. If the change is done
within it, then I agree, we shouldn't need to touch LD_LIBRARY_PATH
directly.

>> That is what I'm using with the current dpkg-shlibdeps from 1.14.11 and
>> AFAICT it is fine (providing that the cross paths are added to the
>> standard paths and not replace them or perl gets confused).
> 
> Care to elaborate on why perl gets confused ? 

If LD_LIBRARY_PATH does not include /usr/lib/ but only
/usr/$triplet/lib, perl cannot find it's own shared objects (presumably
within the interpreter).

This only became noticeable when I tried to set LD_LIBRARY_PATH in a
perl script that then called another perl script - the system call
failed and perl complained about a broken installation.

> In any case, since we would _not_ change LD_LIBRARY_PATH, it shouldn't be
> a problem.

Agreed.

I'll see about a patch later today.

It's the effect of the change that I need, not the current method.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #51 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 453267@bugs.debian.org
Subject: tested patch
Date: Tue, 4 Dec 2007 10:27:35 +0000
[Message part 1 (text/plain, inline)]
Hector and I have tested this patch with normal builds, cross builds
and cross compiler builds.

It does apply against dpkg 1.14.12 (albeit with offsets), it was
developed against 1.14.11.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
[453267.diff (text/x-diff, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Blocking bugs of 453267 removed: Request was from Neil Williams <codehelp@debian.org> to control@bugs.debian.org. (Tue, 04 Dec 2007 11:21:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Frank Lichtenheld <djpig@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #58 received at 453267@bugs.debian.org (full text, mbox):

From: Frank Lichtenheld <djpig@debian.org>
To: Neil Williams <codehelp@debian.org>, 453267@bugs.debian.org
Subject: Re: Bug#453267: tested patch
Date: Tue, 4 Dec 2007 18:43:09 +0100
On Tue, Dec 04, 2007 at 10:27:35AM +0000, Neil Williams wrote:
>  use constant DEFAULT_LIBRARY_PATH =>
>      qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
>         /emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
[...]
> +if ($crossprefix)
> +{
> +    @shlibdeps = ( "${crossprefix}/lib", "/usr/${crossprefix}/lib",
> +    "/${crossprefix}/lib32", "/usr/${crossprefix}/lib32",
> +    "/${crossprefix}/lib64", "/usr/${crossprefix}/lib64",
> +    "/emul/ia32-linux/lib", "/emul/ia32-linux/usr/lib" );
> +}

Why do you add "/emul/ia32-linux/lib", "/emul/ia32-linux/usr/lib" again?

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #63 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Frank Lichtenheld <djpig@debian.org>
Cc: 453267@bugs.debian.org
Subject: Re: Bug#453267: tested patch
Date: Tue, 04 Dec 2007 17:58:01 +0000
[Message part 1 (text/plain, inline)]
Frank Lichtenheld wrote:
> On Tue, Dec 04, 2007 at 10:27:35AM +0000, Neil Williams wrote:
>>  use constant DEFAULT_LIBRARY_PATH =>
>>      qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
>>         /emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
> [...]
>> +if ($crossprefix)
>> +{
>> +    @shlibdeps = ( "${crossprefix}/lib", "/usr/${crossprefix}/lib",
>> +    "/${crossprefix}/lib32", "/usr/${crossprefix}/lib32",
>> +    "/${crossprefix}/lib64", "/usr/${crossprefix}/lib64",
>> +    "/emul/ia32-linux/lib", "/emul/ia32-linux/usr/lib" );
>> +}
> 
> Why do you add "/emul/ia32-linux/lib", "/emul/ia32-linux/usr/lib" again?
> 
> Gruesse,


Oops.

Do you want a new patch with that final line amended?

Sorry about the typo - there is no need for the repeated /emul/, it is a
hangover from when the cross paths overwrote the standard paths instead
of appending to them.

It should be:

+if ($crossprefix)
+{
+    @shlibdeps = ( "${crossprefix}/lib", "/usr/${crossprefix}/lib",
+    "/${crossprefix}/lib32", "/usr/${crossprefix}/lib32",
+    "/${crossprefix}/lib64", "/usr/${crossprefix}/lib64");
+}


-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Frank Lichtenheld <djpig@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #68 received at 453267@bugs.debian.org (full text, mbox):

From: Frank Lichtenheld <djpig@debian.org>
To: Neil Williams <codehelp@debian.org>, 453267@bugs.debian.org
Subject: Re: Bug#453267: tested patch
Date: Tue, 4 Dec 2007 19:35:03 +0100
On Tue, Dec 04, 2007 at 05:58:01PM +0000, Neil Williams wrote:
> Do you want a new patch with that final line amended?

Nah, just making sure whether this was a typo or not.

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #73 received at 453267@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Neil Williams <codehelp@debian.org>, 453267@bugs.debian.org
Subject: Re: Bug#453267: tested patch
Date: Wed, 5 Dec 2007 00:01:22 +0100
On Tue, 04 Dec 2007, Neil Williams wrote:
> +my @shlibdeps=();
> +# ARCH for some awkward builds
> +my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if ($ENV{ARCH});

What's the role of $ARCH ? And why shall we consider that we're
crossbuilding only because this variable is set ?

> +# host for normal cross builds.
> +$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
> +    if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne $ENV{DEB_BUILD_GNU_TYPE}));

I think you should use the functions contained in Dpkg::Arch instead of
relying only the environment variables here... 

use Dpkg::Arch qw(get_host_arch get_build_arch debarch_to_gnutriplet);
[...]
if (get_host_arch() ne get_build_arch()) {
    $crossprefix = debarch_to_gnutriplet(get_host_arch());
}

> +# target when building a cross compiler
> +$crossprefix = $ENV{DEB_TARGET_GNU_TYPE}
> +    if (($ENV{DEB_TARGET_GNU_TYPE}) and ($ENV{DEB_TARGET_GNU_TYPE} ne $ENV{DEB_BUILD_GNU_TYPE}));

Why would we need a special treatment of libs when creating a
cross-compiler? The cross-compiler runs on the build arch but is not linked
against any lib of the target arch so it doesn't need to scan the
directories of the target arch.

(I may be missing something here, but I don't see what currently)

> +if ($crossprefix)
> +{
> +    @shlibdeps = ( "${crossprefix}/lib", "/usr/${crossprefix}/lib",
> +    "/${crossprefix}/lib32", "/usr/${crossprefix}/lib32",
> +    "/${crossprefix}/lib64", "/usr/${crossprefix}/lib64",
> +    "/emul/ia32-linux/lib", "/emul/ia32-linux/usr/lib" );
> +}

There's no need for a special escapment of the variables here.
"/usr/$crossprefix/something" works ok.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #78 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 453267@bugs.debian.org
Subject: Re: Bug#453267: tested patch
Date: Tue, 4 Dec 2007 23:50:33 +0000
[Message part 1 (text/plain, inline)]
On Wed, 5 Dec 2007 00:01:22 +0100
Raphael Hertzog <hertzog@debian.org> wrote:

> On Tue, 04 Dec 2007, Neil Williams wrote:
> > +my @shlibdeps=();
> > +# ARCH for some awkward builds
> > +my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if ($ENV{ARCH});
> 
> What's the role of $ARCH ? And why shall we consider that we're
> crossbuilding only because this variable is set ?

Not cross building - building a cross compiler.

gcc relies on $ARCH when preparing libgcc1-$arch-cross and other
toolchain libraries.

The actual call in gcc is:

ARCH=arm MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1-arm-cross

e.g.

> cd /opt/emdebian/emchain/gcc-4.2-4.2.2
> GCC_TARGET=arm DEB_CROSS=yes debian/rules control
> GCC_TARGET=arm DEB_CROSS=yes dpkg-buildpackage -b -uc -us -rfakeroot
>
> build completes as normal with the patch
>
> Testing from gcc-4.2-4.2.2 directory:
> ARCH=arm MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1-arm-cross
>
> no errors.
>
> Without the patch, I get:
> dpkg-shlibdeps: failure: couldn't find library libc.so.6 needed by
> debian/libgcc1-arm-cross/usr/arm-linux-gnu/lib/libgcc_s.so.1 (its RPATH
> is '').
> Note: libraries are not searched in other binary packages that do not
> have any shlibs file.
> To help dpkg-shlibdeps find private libraries, you might need to set
> LD_LIBRARY_PATH.
> dh_shlibdeps: command returned error code 512

...

> > +# host for normal cross builds.
> > +$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
> > +    if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne $ENV{DEB_BUILD_GNU_TYPE}));
> 
> I think you should use the functions contained in Dpkg::Arch instead of
> relying only the environment variables here... 

Those variables are only defined in a cross build, not when building a
cross compiler or a toolchain.

We cannot use 'dpkg-architecture -a..' when building a cross compiler,
therefore we only have the environment variables.

> use Dpkg::Arch qw(get_host_arch get_build_arch debarch_to_gnutriplet);
> [...]
> if (get_host_arch() ne get_build_arch()) {
>     $crossprefix = debarch_to_gnutriplet(get_host_arch());
> }
> 
> > +# target when building a cross compiler
> > +$crossprefix = $ENV{DEB_TARGET_GNU_TYPE}
> > +    if (($ENV{DEB_TARGET_GNU_TYPE}) and ($ENV{DEB_TARGET_GNU_TYPE} ne $ENV{DEB_BUILD_GNU_TYPE}));
> 
> Why would we need a special treatment of libs when creating a
> cross-compiler? The cross-compiler runs on the build arch but is not linked
> against any lib of the target arch so it doesn't need to scan the
> directories of the target arch.

The cross compiler needs to build cross libraries that *are* called
when preparing the cross compiler itself.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #83 received at 453267@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Neil Williams <codehelp@debian.org>
Cc: 453267@bugs.debian.org
Subject: Re: Bug#453267: tested patch
Date: Wed, 5 Dec 2007 21:20:25 +0100
On Tue, 04 Dec 2007, Neil Williams wrote:
> On Wed, 5 Dec 2007 00:01:22 +0100
> Raphael Hertzog <hertzog@debian.org> wrote:
> 
> > On Tue, 04 Dec 2007, Neil Williams wrote:
> > > +my @shlibdeps=();
> > > +# ARCH for some awkward builds
> > > +my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if ($ENV{ARCH});
> > 
> > What's the role of $ARCH ? And why shall we consider that we're
> > crossbuilding only because this variable is set ?
> 
> Not cross building - building a cross compiler.

Do we need to check twice for building a cross-compiler ? We don't need to
check $ARCH if we already have DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE,
no ?

> gcc relies on $ARCH when preparing libgcc1-$arch-cross and other
> toolchain libraries.

Fine, but I don't think that dpkg-shlibdeps has to check $ARCH at all.

> > Without the patch, I get:
> > dpkg-shlibdeps: failure: couldn't find library libc.so.6 needed by
> > debian/libgcc1-arm-cross/usr/arm-linux-gnu/lib/libgcc_s.so.1 (its RPATH
> > is '').

OK, but this means that you can't build a cross-compiler without having
the target libc6 ... which in theory you might not yet have since the
cross-compiler might be your only choice to compile that library.

Is that a real requirement or just a consequence of the fact that
dpkg-shlibdeps got more strict in the checks that it does ?

Maybe, the call to dpkg-shlibdeps should exclude files found below
/usr/$target/ ... this can be easily done with dh_shlibdeps.

> > > +# host for normal cross builds.
> > > +$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
> > > +    if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne $ENV{DEB_BUILD_GNU_TYPE}));
> > 
> > I think you should use the functions contained in Dpkg::Arch instead of
> > relying only the environment variables here... 
> 
> Those variables are only defined in a cross build, not when building a
> cross compiler or a toolchain.

Yes and what does that have to do with my remark ? Using the functions
instead of the variables is still nicer to detect a cross build.
My remark was generic and didn't concern the case of building a
cross-compiler at all.

> > Why would we need a special treatment of libs when creating a
> > cross-compiler? The cross-compiler runs on the build arch but is not linked
> > against any lib of the target arch so it doesn't need to scan the
> > directories of the target arch.
> 
> The cross compiler needs to build cross libraries that *are* called
> when preparing the cross compiler itself.

Are called ? You mean that are analyzed by dpkg-shlibdeps ?

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #88 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 453267@bugs.debian.org
Subject: Re: Bug#453267: tested patch
Date: Wed, 05 Dec 2007 22:32:14 +0000
[Message part 1 (text/plain, inline)]
Raphael Hertzog wrote:
> On Tue, 04 Dec 2007, Neil Williams wrote:
>> On Wed, 5 Dec 2007 00:01:22 +0100
>> Raphael Hertzog <hertzog@debian.org> wrote:
>>
>>> On Tue, 04 Dec 2007, Neil Williams wrote:
>>>> +my @shlibdeps=();
>>>> +# ARCH for some awkward builds
>>>> +my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if ($ENV{ARCH});
>>> What's the role of $ARCH ? And why shall we consider that we're
>>> crossbuilding only because this variable is set ?
>> Not cross building - building a cross compiler.
> 
> Do we need to check twice for building a cross-compiler ? We don't need to
> check $ARCH if we already have DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE,
> no ?

My first patch did exactly that - and failed on building a cross
compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the
preparation of libgcc1-$arch-cross and other libraries used in the
complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE !=
DEB_BUILD_GNU_TYPE at other stages of the build.

dpkg-shlibdeps is called multiple times in the cross compiler build,
sometimes only $ARCH is set (libgcc1-arm-cross), sometimes GCC_TARGET is
used to set DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE and $ARCH is
undefined, sometimes both are set.

>> gcc relies on $ARCH when preparing libgcc1-$arch-cross and other
>> toolchain libraries.
> 
> Fine, but I don't think that dpkg-shlibdeps has to check $ARCH at all.

? When preparing libgcc1-$arch-cross, only $ARCH is in effect.
dpkg-shlibdeps *fails* if it ignores $ARCH.

gcc relies on dpkg-shlibdeps noticing that ARCH is set and acting
accordingly - without the patch, the build fails.

gcc sets ARCH, it checks ARCH for internal purposes and it requires that
dpkg-shlibdeps acts on the value from ARCH when looking for the
libraries that gcc linked against the cross libraries built by gcc (or
installed previously using dpkg-cross) and which support the final
toolchain.

>>> Without the patch, I get:
>>> dpkg-shlibdeps: failure: couldn't find library libc.so.6 needed by
>>> debian/libgcc1-arm-cross/usr/arm-linux-gnu/lib/libgcc_s.so.1 (its RPATH
>>> is '').
> 
> OK, but this means that you can't build a cross-compiler without having
> the target libc6 ... which in theory you might not yet have since the
> cross-compiler might be your only choice to compile that library.

This is a separate problem being resolved via dpkg-cross. It is not
something that dpkg-shlibdeps needs to support, as long as
dpkg-shlibdeps checks both $ARCH and DEB_TARGET_GNU_TYPE !=
DEB_BUILD_GNU_TYPE, then adds the crossprefix locations to the list of
directories to search, dpkg-cross can deal with the rest.

The basic problem is determining which existing architecture can act as
a base for the libc6 component sufficient to get the cross compiler to
rebuild the final version of the library.

An alternative is to build a crippled cross compiler that skips certain
packages. Either way, this is not a problem that needs to be (or could
be) solved within dpkg-shlibdeps. It is not one, IMHO, that can be
solved within dpkg at all - at least not fully. It is a simple reality
of starting a new port for a new architecture - it may well be necessary
to build temporary packages, partially disabled packages or use other
external wrappers to get to the point where a fully usable cross
compiling toolchain can actually be built for the new architecture -
assuming, of course, that gcc can support the new architecture in the
first place.

> 
> Is that a real requirement or just a consequence of the fact that
> dpkg-shlibdeps got more strict in the checks that it does ?

A real requirement that was previously implemented in the dpkg-cross
diversion of dpkg-shlibdeps that was used to build all Debian cross
compilers prior to dpkg 1.14.11 and dpkg-cross 2.0.0.

dpkg-shlibdeps from dpkg has *never* worked for cross building because
'dpkg-buildpackage -a' has built neither a cross compiler nor a cross
built package successfully. dpkg-cross has always diverted the dpkg
versions of dpkg-buildpackage and dpkg-shlibdeps.

All these changes are inherited from the diversions that were supported
until dpkg-shlibdeps and dpkg-buildpackage became perl scripts.
Currently, cross building in Debian means using this patch or something
very similar.

The whole point of this bug and 439979 is that these diversions needed
to be removed because cross building needs the improved checks that are
in place for native builds in order to be able to successfully build new
package sets that have dramatically reduced dependency trees. The old
diversions simply acted as if dpkg-shlibdeps.orig did not exist.

> 
> Maybe, the call to dpkg-shlibdeps should exclude files found below
> /usr/$target/ ... this can be easily done with dh_shlibdeps.

? exclude ? It needs to include them, that's why the cross compiler
build fails - they are excluded already in 1.14.11 and 1.14.12 and the
build fails.

libgcc1-arm-cross needs to have a usable, generated, dependency list and
that should be done by dpkg-shlibdeps, just as it is for every other
package.

To do that, dpkg-shlibdeps must check the environment variables that are
set by the cross compiler build and act accordingly. This means checking
both DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE and checking $ARCH.

(I have tested with these changes, it simply does not work without both.)

Having a libgcc1-arm-cross package with the wrong dependencies or no
dependencies at all would ruin the toolchain. It's hard enough keeping
all the toolchains installable (and usable) as it is.....

>>>> +# host for normal cross builds.
>>>> +$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
>>>> +    if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne $ENV{DEB_BUILD_GNU_TYPE}));
>>> I think you should use the functions contained in Dpkg::Arch instead of
>>> relying only the environment variables here... 
>> Those variables are only defined in a cross build, not when building a
>> cross compiler or a toolchain.
> 
> Yes and what does that have to do with my remark ? Using the functions
> instead of the variables is still nicer to detect a cross build.
> My remark was generic and didn't concern the case of building a
> cross-compiler at all.

I intended to keep the patch as small as possible - it was only in order
to fix the $ARCH issue in the cross compiler build that I had to add
'use Dpkg::Arch' at all.

I don't see a function to detect DEB_TARGET_GNU_TYPE or $ARCH and the
functions to check DEB_HOST_GNU_TYPE only wrap the existing call to
dpkg-architecture that is performed using 'dpkg-buildpackage -a' or the
existing cross building wrappers like emdebuild.

Any cross build has to set 'dpkg-architecture -a$arch' anyway so the
relevant environment variables are already set - using the functions
gains nothing AFAICT.

A cross compiler build sets and checks DEB_TARGET_GNU_TYPE then sets and
checks for ARCH (based on the value passed by the user in the GCC_TARGET
environment variable) in separate parts of the build process. Using
wrappers within Dpkg::Arch would simply be wrong in such situations
because the value of the variables is determined by the package, not dpkg.

> cd /opt/emdebian/emchain/gcc-4.2-4.2.2
> GCC_TARGET=arm DEB_CROSS=yes debian/rules control
> GCC_TARGET=arm DEB_CROSS=yes dpkg-buildpackage -b -uc -us -rfakeroot

Building a cross compiler is already specialised - dpkg-shlibdeps just
needs to understand the special needs of this situation and change
behaviour in these specific and specialised circumstances.

> 
>>> Why would we need a special treatment of libs when creating a
>>> cross-compiler? The cross-compiler runs on the build arch but is not linked
>>> against any lib of the target arch so it doesn't need to scan the
>>> directories of the target arch.
>> The cross compiler needs to build cross libraries that *are* called
>> when preparing the cross compiler itself.
> 
> Are called ? You mean that are analyzed by dpkg-shlibdeps ?

The cross compiler builds libgcc1-arm-cross which contains a shared
library built for and linked against libc6 for the target arch
(libc6-arm-cross) - that's the problem referred to above. So yes, the
cross libraries are linked into the binaries built by gcc when preparing
a cross compiler toolchain. dpkg-shlibdeps simply needs to read those
objects correctly and identify the dependencies as they apply to the
target architecture - that requires "special" treatment of libs created
during the cross compiler build and that is why the current cross
compiler builds fail with the unpatched dpkg.

I don't want to have to reimplement a diversion of dpkg-shlibdeps in
perl that basically wraps your script in this patch - dpkg-shlibdeps
just needs to check some specialised environment variables for
particular circumstances.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #93 received at 453267@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Neil Williams <codehelp@debian.org>
Cc: 453267@bugs.debian.org, debian-gcc@lists.debian.org
Subject: Re: Bug#453267: tested patch
Date: Sat, 8 Dec 2007 19:41:28 +0100
On Wed, 05 Dec 2007, Neil Williams wrote:
> Raphael Hertzog wrote:
> > On Tue, 04 Dec 2007, Neil Williams wrote:
> >> On Wed, 5 Dec 2007 00:01:22 +0100
> >> Raphael Hertzog <hertzog@debian.org> wrote:
> >>
> >>> On Tue, 04 Dec 2007, Neil Williams wrote:
> >>>> +my @shlibdeps=();
> >>>> +# ARCH for some awkward builds
> >>>> +my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if ($ENV{ARCH});
> >>> What's the role of $ARCH ? And why shall we consider that we're
> >>> crossbuilding only because this variable is set ?
> >> Not cross building - building a cross compiler.
> > 
> > Do we need to check twice for building a cross-compiler ? We don't need to
> > check $ARCH if we already have DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE,
> > no ?
> 
> My first patch did exactly that - and failed on building a cross
> compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the
> preparation of libgcc1-$arch-cross and other libraries used in the
> complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE !=
> DEB_BUILD_GNU_TYPE at other stages of the build.

If that's the case, I'd like to know if this is deliberate and really
required... can't the gcc package be consistent and always have both
DEB_TARGET_GNU_TYPE and DEB_BUILD_GNU_TYPE properly set ?

(Ccing debian-gcc@l.d.o to have their opinion)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #98 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Raphael Hertzog <hertzog@debian.org>, 453267@bugs.debian.org, debian-gcc@lists.debian.org
Subject: Re: Bug#453267: tested patch
Date: Sat, 08 Dec 2007 19:01:14 +0000
[Message part 1 (text/plain, inline)]
Raphael Hertzog wrote:
> On Wed, 05 Dec 2007, Neil Williams wrote:
>> My first patch did exactly that - and failed on building a cross
>> compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the
>> preparation of libgcc1-$arch-cross and other libraries used in the
>> complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE !=
>> DEB_BUILD_GNU_TYPE at other stages of the build.
> 
> If that's the case, I'd like to know if this is deliberate and really
> required... can't the gcc package be consistent and always have both
> DEB_TARGET_GNU_TYPE and DEB_BUILD_GNU_TYPE properly set ?

Even if gcc changes that behaviour in 4.2 (or 4.3), lots of people still
need to be able to build cross compilers from older versions of gcc,
especially 4.1 and some even need 3.3 or 3.4.

Emdebian still hosts 4.1 and 3.4 toolchains:
http://www.emdebian.org/toolchains/search.php?package=gcc-3.4-arm-linux-gnu

It's not sensible to say that these cannot be built in the future
without writing a whole new diversion for dpkg-shlibdeps. Emdebian and
lots of other people doing cross building need backwards compatibility here.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #103 received at 453267@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Neil Williams <codehelp@debian.org>, 453267@bugs.debian.org
Cc: Raphael Hertzog <hertzog@debian.org>, debian-gcc@lists.debian.org
Subject: Re: Bug#453267: tested patch
Date: Sun, 9 Dec 2007 09:16:04 +0200
Hi,

[ I don't have a real opinion yet on the initial patch and this
  changes proposed, will try to get to this on Sunday. ]

On Sat, 2007-12-08 at 19:01:14 +0000, Neil Williams wrote:
> Raphael Hertzog wrote:
> > On Wed, 05 Dec 2007, Neil Williams wrote:
> >> My first patch did exactly that - and failed on building a cross
> >> compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the
> >> preparation of libgcc1-$arch-cross and other libraries used in the
> >> complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE !=
> >> DEB_BUILD_GNU_TYPE at other stages of the build.
> > 
> > If that's the case, I'd like to know if this is deliberate and really
> > required... can't the gcc package be consistent and always have both
> > DEB_TARGET_GNU_TYPE and DEB_BUILD_GNU_TYPE properly set ?

> Even if gcc changes that behaviour in 4.2 (or 4.3), lots of people still
> need to be able to build cross compilers from older versions of gcc,
> especially 4.1 and some even need 3.3 or 3.4.

Why can't 4.1 and 3.4 be "fixed" (if that's really needed) as well?
3.3 might be a problem, but even then you have to build them locally
to support cross-compiling, why can't they be patched locally as well?

regards,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #108 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Guillem Jover <guillem@debian.org>, 453267@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>, debian-gcc@lists.debian.org
Subject: Re: Bug#453267: tested patch
Date: Sun, 09 Dec 2007 11:03:23 +0000
[Message part 1 (text/plain, inline)]
Guillem Jover wrote:
> Hi,
> 
> [ I don't have a real opinion yet on the initial patch and this
>   changes proposed, will try to get to this on Sunday. ]

OK, thanks, Guillem. I'd like to get this resolved asap.

> On Sat, 2007-12-08 at 19:01:14 +0000, Neil Williams wrote:
>> Raphael Hertzog wrote:
>>> On Wed, 05 Dec 2007, Neil Williams wrote:
>>>> My first patch did exactly that - and failed on building a cross
>>>> compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the
>>>> preparation of libgcc1-$arch-cross and other libraries used in the
>>>> complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE !=
>>>> DEB_BUILD_GNU_TYPE at other stages of the build.
>>> If that's the case, I'd like to know if this is deliberate and really
>>> required... can't the gcc package be consistent and always have both
>>> DEB_TARGET_GNU_TYPE and DEB_BUILD_GNU_TYPE properly set ?
> 
>> Even if gcc changes that behaviour in 4.2 (or 4.3), lots of people still
>> need to be able to build cross compilers from older versions of gcc,
>> especially 4.1 and some even need 3.3 or 3.4.
> 
> Why can't 4.1 and 3.4 be "fixed" (if that's really needed) as well?
> 3.3 might be a problem, but even then you have to build them locally
> to support cross-compiling, why can't they be patched locally as well?

Local patches are *hell* to maintain - that is why I need to remove the
dpkg-cross diversions in the first place. We had local patches for
years, we've got passed that stage (thankfully) and desperately need
usable cross building support *within* Debian and stop this crazy "patch
upon patch upon diversion" approach.

Emdebian cannot build, patch or test every permutation of toolchain that
people need so this isn't about "us" patching locally, it is about
lowering the barrier to cross building on Debian by not forcing every
user to patch locally. This is why we are at the current impasse - too
many permutations.

Why propose changing every version of gcc (a process that could take
extreme amounts of time to test, implement and get into testing) and
then make it impossible to build cross compilers in Etch? Are we looking
at backports as well?? Who is going to do all that work? (Not me, before
anyone asks.)

This is a problem within dpkg, not actually within gcc. It makes far
more sense to change one line in one script than to change every version
of gcc.

dpkg-shlibdeps is (and has always been) broken with regard to building
cross compilers or cross built packages. Various solutions have been
created due to this long, long breakage and things are working nicely,
all the way back to gcc-3.3 and Etch (possibly earlier). Now that we
finally have a chance to fix dpkg-shlibdeps, why must all the previous
work be undone? For the sake of one environment variable?

This bug is about *removing* the dpkg-cross diversions, not *rewriting*
them - changing every gcc package is simply not workable IMHO and the
only real alternative to dpkg-shlibdeps supporting $ARCH is for me to
write a new diversion of dpkg-shlibdeps that *does* check the value of
$ARCH and forces the value of LD_LIBRARY_PATH when building a cross
compiler. That would just be a hack so please, can we just check $ARCH
in dpkg-shlibdeps?


-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #113 received at 453267@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Neil Williams <codehelp@debian.org>
Cc: Guillem Jover <guillem@debian.org>, 453267@bugs.debian.org, debian-gcc@lists.debian.org
Subject: Re: Bug#453267: tested patch
Date: Sun, 9 Dec 2007 14:31:05 +0100
On Sun, 09 Dec 2007, Neil Williams wrote:
> Emdebian cannot build, patch or test every permutation of toolchain that
> people need so this isn't about "us" patching locally, it is about
> lowering the barrier to cross building on Debian by not forcing every
> user to patch locally. This is why we are at the current impasse - too
> many permutations.

Emdebian provides ready to use cross compiler. You can also provides
ready-to-use source packages for building other cross-compilers that are
not yet provided.

> Why propose changing every version of gcc (a process that could take
> extreme amounts of time to test, implement and get into testing) and
> then make it impossible to build cross compilers in Etch? Are we looking
> at backports as well?? Who is going to do all that work? (Not me, before
> anyone asks.)

ARCH is a very generic environment variable that might be set for some
other reasons (I use it for example in debian-cd) and I don't like to
change the behaviour of dpkg-shlibdeps just because it's set. IMO,
there should be a single check to activate cross-building support
and gcc's crossbuild should provide the right variables. I'm ok with a
supplementary specific check for building of a cross-compiler, but not
with a generic check like testing the ARCH environment variable.

Furthermore, all the cross-building support in gcc has been contributed
by various Emdebian people (according to doko), so it looks like Emdebian
is also able to fix gcc in that regard if needed.

> Now that we finally have a chance to fix dpkg-shlibdeps, why must all
> the previous work be undone? For the sake of one environment variable?

Please stop dramatizing the situation, we're not undoing your work. We're
adding proper support for cross-building by trying to do the right thing
instead of integrating crude hacks to match other crude hacks on the gcc
side.

Until you convince me that there's a good reason on the gcc side to not
have a consistent set of variables set, my opinion won't change just
because you repeat the same non-arguments.

> them - changing every gcc package is simply not workable IMHO and the

You make it sound like it would require horribly complicated patches on
the gcc side but we're speaking of setting a few environment variables
only. IMO it's perfectly workable.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #118 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 453267@bugs.debian.org, debian-gcc@lists.debian.org
Subject: Re: Bug#453267: tested patch
Date: Sun, 09 Dec 2007 16:04:28 +0000
[Message part 1 (text/plain, inline)]
Raphael Hertzog wrote:
> On Sun, 09 Dec 2007, Neil Williams wrote:
>> Emdebian cannot build, patch or test every permutation of toolchain that
>> people need so this isn't about "us" patching locally, it is about
>> lowering the barrier to cross building on Debian by not forcing every
>> user to patch locally. This is why we are at the current impasse - too
>> many permutations.
> 
> Emdebian provides ready to use cross compiler. You can also provides
> ready-to-use source packages for building other cross-compilers that are
> not yet provided.

? You make it sound as trivial as providing a web page.

Emdebian provides a small selection of binary toolchains containing
selected cross compilers. Extending that range is a truly massive
undertaking that nobody has the time to do. There are no usable
toolchain-source packages anymore - unmaintainable - we can provide
simple scripts that can assist in building a variant toolchain but we do
not provide ready-to-use source packages for building cross compilers.

The major reason why this is so much work is because the necessary
changes have not been incorporated into dpkg and we end up having to
patch a patch of a diversion of a patch.

Emdebian has quite a good relationship with the gcc maintainers and our
patches are generally welcome but that does not diminish the amount of
time involved in making a tested patch in the first place. Emdebian only
has enough developer time to derive patches for the latest versions of
gcc and even then it can be difficult to keep up with gcc releases. We
look forward to the stability of the pre-Lenny freeze because we know
that we can catch up and get a stable set of toolchains for unstable and
testing, all thoroughly tested and fixed. Then as soon as Lenny comes
out, we'll be swamped by gcc changes again. (We, in this case, equals
Hector Oron, myself and Wookey - gcc has a much larger team just for
itself.)

>> Why propose changing every version of gcc (a process that could take
>> extreme amounts of time to test, implement and get into testing) and
>> then make it impossible to build cross compilers in Etch? Are we looking
>> at backports as well?? Who is going to do all that work? (Not me, before
>> anyone asks.)
> 
> ARCH is a very generic environment variable that might be set for some
> other reasons (I use it for example in debian-cd) and I don't like to
> change the behaviour of dpkg-shlibdeps just because it's set. IMO,
> there should be a single check to activate cross-building support

cross building != building a cross compiler, as I've said many times.

A single check for cross building is already in place -
DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE

I created a patch for that in gcc for reverse cross support, it is
included in gcc-4.2.

A mass bug filing is already under way to implement this single check
for cross building support across Debian. The patch to dpkg-shlibdeps
contains a part of that support.

Cross building gcc is NOT the problem. gcc now cross builds just like
any other package in Debian. If reverse cross support in Debian goes
wrong, I'll fix it. I've no problem with that.

Building a cross compiler is a completely separate task and one that has
only become a problem *after* changes in dpkg made the dpkg-cross
diversions impractical.

> and gcc's crossbuild should provide the right variables.

It does, thanks to the reverse cross support in gcc-4.2. Thankfully, we
don't need reverse cross support in 4.1 or earlier. (Well, it would be
nice if it could happen but then nobody has the time to do it so ...)

> I'm ok with a
> supplementary specific check for building of a cross-compiler, but not
> with a generic check like testing the ARCH environment variable.

OK, I have a solution for that - replace $ARCH with $GCC_TARGET.

I've tested with this change to the patch for scripts/Dpkg/Shlibs.pm

# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
...

I went for ARCH before because, in the context of building a cross
compiler, ARCH is only set at certain times. GCC_TARGET is set at the
beginning and is present throughout the build. This means that the
patched dpkg-shlibdeps behaves much more like the original diversion
from dpkg-cross - it effectively extends the list of directories
searched by dpkg-shlibdeps to include the ${crossprefix} ones for every
call throughout the entire build. It may slow things down a little bit
but building a cross compiler isn't exactly quick anyway. It is far more
important that the build completes than shaving a few more seconds off
the build time.

> Furthermore, all the cross-building support in gcc has been contributed
> by various Emdebian people (according to doko), so it looks like Emdebian
> is also able to fix gcc in that regard if needed.

Those fixes (or hacks) were implemented piecemeal over many years and
the cross building support in Emdebian has recently been rewritten so
some of those hacks (i.e. the dpkg-cross diversions) have to be removed.
I don't like the hacks any more than you do, that's why I'm still
pursuing this bug.

As I've mentioned above, Emdebian is not usually able to fix gcc in
anything other than the latest version due to lack of developer time.

>> Now that we finally have a chance to fix dpkg-shlibdeps, why must all
>> the previous work be undone? For the sake of one environment variable?
> 
> Please stop dramatizing the situation, we're not undoing your work. We're
> adding proper support for cross-building by trying to do the right thing
> instead of integrating crude hacks to match other crude hacks on the gcc
> side.
> 
> Until you convince me that there's a good reason on the gcc side to not
> have a consistent set of variables set, my opinion won't change just
> because you repeat the same non-arguments.

? So the simple fact that changing all versions of gcc is simply too
much work is not relevant ?

Anyway, I hope you are now happy to use the "supplementary specific
check for building of a cross-compiler" that I have described above, in
addition to the checks from the original patch for normal cross building
support, including checking DEB_TARGET_GNU_TYPE so that future versions
of gcc can migrate away from GCC_TARGET, possibly.

The final version is:

(email line wrapping notwithstanding)

use constant DEFAULT_LIBRARY_PATH =>
    qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
       /emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
my @shlibdeps=();
# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
# host for normal cross builds.
$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
    if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne
$ENV{DEB_BUILD_GNU_TYPE}));
# target when building a cross compiler
$crossprefix = $ENV{DEB_TARGET_GNU_TYPE}
    if (($ENV{DEB_TARGET_GNU_TYPE}) and ($ENV{DEB_TARGET_GNU_TYPE} ne
$ENV{DEB_BUILD_GNU_TYPE}));
if ($crossprefix)
{
    @shlibdeps = ( "${crossprefix}/lib", "/usr/${crossprefix}/lib",
    "/${crossprefix}/lib32", "/usr/${crossprefix}/lib32",
    "/${crossprefix}/lib64", "/usr/${crossprefix}/lib64");
}
our @librarypaths = ((DEFAULT_LIBRARY_PATH), @shlibdeps);


>> them - changing every gcc package is simply not workable IMHO and the
> 
> You make it sound like it would require horribly complicated patches on
> the gcc side but we're speaking of setting a few environment variables
> only. IMO it's perfectly workable.

Are you proposing to do the work?

I fear it is not as simple as you imagine - the patches would be
complicated because of the permutations that would need testing and the
amount of time involved. This is a dpkg problem and it needs a dpkg
solution, IMHO.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #123 received at 453267@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Neil Williams <codehelp@debian.org>, 453267@bugs.debian.org
Cc: debian-gcc@lists.debian.org
Subject: Re: Bug#453267: tested patch
Date: Sun, 9 Dec 2007 18:46:44 +0100
On Sun, 09 Dec 2007, Neil Williams wrote:
> > I'm ok with a
> > supplementary specific check for building of a cross-compiler, but not
> > with a generic check like testing the ARCH environment variable.
> 
> OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
> 
> I've tested with this change to the patch for scripts/Dpkg/Shlibs.pm
> 
> # GCC_TARGET for cross compiler builds
> my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
> ($ENV{GCC_TARGET});
> ...
> 
> I went for ARCH before because, in the context of building a cross
> compiler, ARCH is only set at certain times. GCC_TARGET is set at the
> beginning and is present throughout the build. 

If I understand you correctly, we can check for GCC_TARGET only and we
don't need to check DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE.

Is that correct and does that work ?

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#453267; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

Message #128 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Raphael Hertzog <hertzog@debian.org>, 453267@bugs.debian.org, debian-gcc@lists.debian.org
Subject: Re: Bug#453267: tested patch
Date: Sun, 09 Dec 2007 23:04:55 +0000
[Message part 1 (text/plain, inline)]
Raphael Hertzog wrote:
> On Sun, 09 Dec 2007, Neil Williams wrote:
>>> I'm ok with a
>>> supplementary specific check for building of a cross-compiler, but not
>>> with a generic check like testing the ARCH environment variable.
>> OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
>>
>> I've tested with this change to the patch for scripts/Dpkg/Shlibs.pm
>>
>> # GCC_TARGET for cross compiler builds
>> my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
>> ($ENV{GCC_TARGET});
>> ...
>>
>> I went for ARCH before because, in the context of building a cross
>> compiler, ARCH is only set at certain times. GCC_TARGET is set at the
>> beginning and is present throughout the build. 
> 
> If I understand you correctly, we can check for GCC_TARGET only and we
> don't need to check DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE.

What's the obsession with cutting components out of the patch?? I'm
confused.

dpkg-shlibdeps should at least *support* the "right" way of doing
things, even if the packages currently do not use that. At least it
supports a migration route away from GCC_TARGET for future releases of
gcc. GCC_TARGET is a hack, yes, but we need it around for older
compilers that simply aren't going to get fixed. It would be nice to
provide a migration path to do it TheRightWay(TM) eventually because
that only means changing the latest version of gcc (probably 4.3) and we
can do that in the Lenny freeze when everything else gets easier too. I
don't want to have to go through all this again. GCC_TARGET is likely to
be around until gcc-4.3 gets into oldstable but that's a small price to
pay, IMHO. (It's been around for as long as dpkg-cross which is a decade
so a bit longer isn't going to hurt.)

> Is that correct and does that work ?

I don't believe it is correct but it happens to work - for now.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, attachment)]

Bug reassigned from package `dpkg' to `dpkg-dev'. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sat, 29 Dec 2007 15:51:05 GMT) Full text and rfc822 format available.

Changed Bug title to `dpkg-shlibdeps: support cross-building by scanning required directories' from `dpkg-dev: Please support removal of dpkg-cross diversions'. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sat, 29 Dec 2007 15:51:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#453267; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #137 received at 453267@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: control@bugs.debian.org
Cc: 453267@bugs.debian.org
Subject: setting package to dselect dpkg-dev dpkg, tagging 453267
Date: Thu, 27 Mar 2008 22:51:50 +0100
# Automatically generated email from bts, devscripts version 2.10.20
#
# dpkg (1.14.17) UNRELEASED; urgency=low
#
#  * dpkg-shlibdeps is now able to look into directories containing libraries
#    used by cross-built binaries provided that the right environment variable
#    are set. Closes: #453267
#

package dselect dpkg-dev dpkg
tags 453267 + pending





Tags added: pending Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Thu, 27 Mar 2008 21:56:18 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#453267; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #144 received at 453267@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Neil Williams <codehelp@debian.org>, 453267@bugs.debian.org
Subject: Re: Bug#453267: dpkg-shlibdeps and cross-building
Date: Thu, 27 Mar 2008 22:54:55 +0100
Hi,

On Tue, 04 Dec 2007, Neil Williams wrote:
> It does apply against dpkg 1.14.12 (albeit with offsets), it was
> developed against 1.14.11.

I have merged a variant of this patch this evening:
http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=626dda6f55bb7fb025be6a7c276651df884ac8a1

Can you check that it works as you want?

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#453267; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #149 received at 453267@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 453267@bugs.debian.org
Subject: Re: Bug#453267: dpkg-shlibdeps and cross-building
Date: Fri, 28 Mar 2008 21:40:21 +0000
[Message part 1 (text/plain, inline)]
On Thu, 2008-03-27 at 22:54 +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Tue, 04 Dec 2007, Neil Williams wrote:
> > It does apply against dpkg 1.14.12 (albeit with offsets), it was
> > developed against 1.14.11.
> 
> I have merged a variant of this patch this evening:
> http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=626dda6f55bb7fb025be6a7c276651df884ac8a1
> 
> Can you check that it works as you want?

I have been testing this with a variety of packages, including
reverse_cross builds and cross-compiler builds of gcc-4.2 (there are
upstream problems with gcc-4.3 right now) and a mix of other Emdebian
packages and it works perfectly.

Thanks for committing this fix, it will help Emdebian enormously.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, inline)]

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Neil Williams <codehelp@debian.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #154 received at 453267-close@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: 453267-close@bugs.debian.org
Subject: Bug#453267: fixed in dpkg 1.14.17
Date: Sun, 30 Mar 2008 10:17:05 +0000
Source: dpkg
Source-Version: 1.14.17

We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive:

dpkg-dev_1.14.17_all.deb
  to pool/main/d/dpkg/dpkg-dev_1.14.17_all.deb
dpkg_1.14.17.dsc
  to pool/main/d/dpkg/dpkg_1.14.17.dsc
dpkg_1.14.17.tar.gz
  to pool/main/d/dpkg/dpkg_1.14.17.tar.gz
dpkg_1.14.17_i386.deb
  to pool/main/d/dpkg/dpkg_1.14.17_i386.deb
dselect_1.14.17_i386.deb
  to pool/main/d/dpkg/dselect_1.14.17_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 453267@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 30 Mar 2008 12:48:22 +0300
Source: dpkg
Binary: dpkg dpkg-dev dselect
Architecture: source i386 all
Version: 1.14.17
Distribution: experimental
Urgency: low
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description: 
 dpkg       - package maintenance system for Debian
 dpkg-dev   - package building tools for Debian
 dselect    - user tool to manage Debian packages
Closes: 4588 4628 4655 12564 17243 68981 114774 142042 151540 203792 215374 217622 220758 246918 248693 255882 308285 311843 323909 355654 363018 366555 379028 435126 439979 443338 445552 448946 453267 462225 462403 462413 463048 463398 465282 465420 465651 466135 466321 466957 467470 468916 469520 469838 471342 472332
Changes: 
 dpkg (1.14.17) experimental; urgency=low
 .
   [ Guillem Jover ]
   * Replace strdup plus error checking usage with a new m_strdup function.
     Closes: #379028
   * Add new keybinding in dselect to restore all selections back to
     whatever's currently installed. Closes: #151540
     Thanks to Colin Watson.
   * Use system timersub and fix timeval normalization in multiplication in
     start-stop-daemon. Thanks to Andreas Påhlsson. Closes: #462225
   * Cosmetic fixes to start-stop-daemon output and man page. Document that
     --chuid will change the group even if it has not been specified. Add
     EXIT STATUS and EXAMPLE sections to man page. Thanks to Justin Pryzby.
   * Add Raphael Hertzog to Uploaders, and remove Brendan O'Dea and
     Christian Perrier with their permission.
   * Use functions from libcompat when those are not provided by the system.
     - Add strnlen to libcompat.
     - Link programs against libcompat which provides obstack. Closes: #142042
   * Change dpkg-gencontrol to not output the Homapage field on udeb.
   * Reintroduce 'no-debsig' back in dpkg.cfg to avoid failing to install any
     package when debsig-verify is installed. Closes: #311843
   * Fix some small memory leaks. Closes: #469520
     Thanks to Sean Finney.
   * Correct broken dselect logic for self-conflicting packages.
     Thanks to Ian Jackson.
   * Implement 'Breaks' properly in dselect. Closes: #448946
     Thanks to Ian Jackson.
   * Fix erroneous description of Breaks in dselect output.
     Thanks to Ian Jackson.
   * Allow compilation with --disable-nls on systems without libintl.h where
     a non glibc claims to be glibc. Closes: #465420
   * Fix crash when a .deb file becomes unreadable while dpkg is starting.
     Thanks to Ian Jackson. Closes: #255882
   * Few file descriptor cleanup and error handling fixes.
     Thanks to Ian Jackson. Closes: #443338
   * Move test suite invokation to a new check target in debian/rules.
   * Add support for nocheck DEB_BUILD_OPTIONS in debian/rules, so that the
     dpkg test suite can be skept if desired.
   * Improve log and status-fd output by printing more status change updates
     and actions. Thanks to Ian Jackson.
   * Implement triggers support. Thanks to Ian Jackson.
     Closes: #17243, #68981, #215374, #217622, #248693, #308285
 .
   [ Raphael Hertzog ]
   * Add a warning displayed by dpkg-genchanges if the current version is
     smaller than the previous one. Closes: #4655
   * Add -d and -c options in dpkg-checkbuilddeps to override
     build-depends/conflicts. Closes: #114774
   * Include list of libraries in dpkg-gensymbols' warning about new/lost
     libraries.
   * Add -R option to dpkg-buildpackage so that one can replace the usual
     "debian/rules" by something else. Closes: #355654
   * Always list all binary packages in the Description: field of .changes
     files. It's nice for reviewers and mentors.debian.net was using this field
     on source only uploads to display short description of what the package is
     about.
   * Handle the case when the library has a different SONAME than the one used
     to find it. Closes: #462413
   * Fix Dpkg::Version and Dpkg::Fields::Object to import _g() from
     Dpkg::Gettext. Thanks to Adam Heath and Olivier Berger for spotting
     this. Closes: #465651
   * Change PATH during make check to look into build directories containing
     dpkg and the related scripts. Thanks to Mike Frysinger. Closes: #466957
   * Some lintian cleanup:
     - add overrides for some useless I: tags
     - drop unused overrides
     - updated several manual pages to fix hyphen-used-as-minus-sign
     - fixed manpage-has-errors-from-man in several manual pages
     - removed empty debian/dpkg.prerm
   * Removed old upgrade code from dpkg's preinst and postinst which only
     concerns upgrading from dpkg version older than the one in oldstable
     already. And thus we get rid of old the last usage of read in those
     scripts (fixes lintian's warning read-in-maintainer-script).
   * Removed sorting of dependencies in dpkg-gencontrol and dpkg-source. But
     kept it for all other fields (Enhances, Conflicts, Replaces, Breaks,
     Build-Conflicts and Build-Conflicts-Indep).
   * Instead changed dpkg-shlibdeps to sort the dependencies generated in
     ${shlibs:*} variables.
   * Changed the logic of simplification of dependencies: if any dependency
     must be discarded due to another dependency appearing further
     in the field, the superseding dependency will take the place of the
     discarded one. Added a test case for this.
   * dpkg-shlibdeps properly accounts usage of symbols provided by private
     libraries without SONAME. Closes: #469838
   * Add a new warning to dpkg-shlibdeps when a library NEEDED is in fact
     not used by any of the binaries analyzed. Closes: #472332
   * Add a new --warnings=<value> option to select the set of warnings to
     activate. By default, do not activate the warning about useless
     libraries at the binary level (instead the new warning above is activated
     by default: it's less strict and more useful).
   * dpkg-source has been heavily refactored to make it easier to support
     multiple source package formats. Several new source package formats have
     been added:
     - the format "2.0" is the original wig&pen
     - the format "3.0 (quilt)" is based on 2.0. It uses a tarball for the
       debian directory and can thus include binary files. Binaries
       outside of the debian directory can be also included if they
       are listed in debian/source/include-binaries (and option
       --include-binaries will generate this file automatically).
       Closes: #4588, #4628
     - thus it will also preserve timestamps on Debian-provided
       documentation like README.Debian. Closes: #366555
     - it handles an explicit series of patches and the patch can thus be
       named without constraints. Patches can contain arbitrary
       headers/comments between file chunks. Closes: #363018
     - it ignores changes on a number of temporary and VCS-specific files
       by default. Closes: #203792, #323909
     - the patches in debian/patches can remove files. Closes: #12564
     - the patches are applied at unpack time. Closes: #463048
     - the formats "3.0 (quilt/native)" don't include VCS directories by
       default. Closes: #435126
     - the format "3.0 (custom)" can be used to create a source package
       containing arbitrary files. It's useful for helper tools that can
       generate the files by themselves in a more efficient way
       (like all the *-buildpackage tools). Closes: #246918
     - the formats "3.0 (git/bzr)" are experimental formats based
       on corresponding VCS repositories. Thanks to Joey Hess and Colin Watson
       respectively.
   * dpkg-source has a new --no-check option. It disables GPG check and
     checksums checks. Closes: #220758
   * dpkg-shlibdeps is now able to look into directories containing libraries
     used by cross-built binaries provided that the right environment variable
     are set. Closes: #453267
   * Change default value of LDFLAGS (set by dpkg-buildpackage) to ''
     instead of '-Wl,-Bsymbolic-functions'. It's safer at this point of the
     release cycle.
   * dpkg-buildpackage will set PKG_CONFIG_LIBDIR (but not override an existing
     value) in case of cross-compilation so that pkgconfig finds .pc files
     in the directory specific to the target architecture. Closes: #439979
 .
   [ Frank Lichtenheld ]
   * Add a warning in dpkg-buildpackage if the build-dependencies are not
     satisfied during -S. Closes: #445552
   * Add a missing space in the German scripts translation. Closes: #463398
   * Add improved deb-shlibs.5 manual page by Zack Weinberg. Closes: #466135
   * dpkg-buildpackage exports some build related environment variables
     now. Based on a patch by Matthias Klose. Closes: #465282
     (See dpkg-buildpackage(1) and https://wiki.ubuntu.com/DistCompilerFlags
      for details)
   * Add support for use of SHA1 and SHA256 checksums in .dsc and
     .changes files. Information will be available in Checksums-Sha{1,256}
     fields. .changes format version increased to 1.8.
   * Link dselect against libncursesw. Closes: #466321
   * Forward port a patch from the old changelog parser to the new
     one that got lost during the transition. '+' and '.' can now
     be used in distribution names yet again. Reported by dann frazier.
     Closes: #467470
 .
   [ Updated dpkg translations ]
   * Korean (Changwoo Ryu).
   * Polish (Robert Luberda).
   * Romanian (Eddy Petrişor).
   * Slovak (Ivan Masár). Closes: #471342
   * Swedish (Peter Karlsson).
   * Thai (Theppitak Karoonboonyanan). Closes: #468916
 .
   [ Updated manpages translations ]
   * German (Helge Kreutzmann).
   * Polish (Robert Luberda).
   * Swedish (Peter Karlsson).
 .
   [ Updated dselect translations ]
   * Basque. (Piarres beobide). Closes: #462403
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
   * Polish (Robert Luberda).
   * Swedish (Peter Karlsson).
 .
   [ Updated dselect translations ]
   * Polish (Robert Luberda).
   * Romanian (Eddy Petrişor).
Files: 
 56444961ee40787d3ea5021dcc06a876 1205 admin required dpkg_1.14.17.dsc
 0ca6340578ada3e552d65da20a156f63 6379035 admin required dpkg_1.14.17.tar.gz
 358289c629a4b576fc2b442c7651a415 2122620 admin required dpkg_1.14.17_i386.deb
 84ab760fccbd19f8471d0699adbcd5a0 736746 admin optional dselect_1.14.17_i386.deb
 faca7bfb16abe077738e7607379d64ec 626054 utils optional dpkg-dev_1.14.17_all.deb
Checksums-Sha1: 
 cac35895c30cbd70ab57139306353ee0168aa29e 968 dpkg_1.14.17.dsc
 15faa3d798821d27b05fc09a3250fb26bacfb4a4 6379035 dpkg_1.14.17.tar.gz
 fc2c83f6f73b59dd173d944ad2dbf456725b6728 2122620 dpkg_1.14.17_i386.deb
 22214ad294485c59baa3c268d89f44e4e7e5b76f 736746 dselect_1.14.17_i386.deb
 913250129eef33396fcbed06aa051d5d19d3460c 626054 dpkg-dev_1.14.17_all.deb
Checksums-Sha256: 
 59d7e12cf3ab6096a27c87b3181a9c950574398dd38c83afbad5493035b581f4 968 dpkg_1.14.17.dsc
 9c45ae389e305a76070340415169383ae1126c1e7e77376c16feaf35cc40b6d2 6379035 dpkg_1.14.17.tar.gz
 4e8f8a1d24aaa7584fc94aaa7f40d87b4a8bf66bfdc31cc2a4a6a0b66c656c2d 2122620 dpkg_1.14.17_i386.deb
 4b788d10b1779ea032dea864aebfc7171607c7a5de6a71a39f7b190b679e81a7 736746 dselect_1.14.17_i386.deb
 a598e6468317c6401593c5830fc7c7380f0acdce8dc61c45b07157834c92eb18 626054 dpkg-dev_1.14.17_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH72VTuW9ciZ2SjJsRAtvcAKC3lKxZP+TcJkXuNk2YrhWMr54UJgCgp/Es
81b/wWSjXuYpn8Vku+tiby8=
=y/qC
-----END PGP SIGNATURE-----





Reply sent to Neil Williams <linux@codehelp.co.uk>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Neil Williams <codehelp@debian.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #159 received at 453267-done@bugs.debian.org (full text, mbox):

From: Neil Williams <linux@codehelp.co.uk>
To: 453267-done@bugs.debian.org
Subject: reopened in error
Date: Wed, 21 May 2008 11:05:31 +0100
[Message part 1 (text/plain, inline)]
Package: dpkg
Version: 1.14.17

Re-opened in haste, repenting at leisure.


-- 
Neil Williams <linux@codehelp.co.uk>
[signature.asc (application/pgp-signature, inline)]

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 19 Jun 2008 07:37:40 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 19:02:24 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.