Bug#453267: Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
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
Description: OpenPGP digital signature
Bug#453267: Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
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/
Bug#453267: Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
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 Description: OpenPGP digital signature
