Re: About dpkg-shlibdeps checks
Hello,
Neil answered me off-list. I'm putting this info on-list just FYI
---------- Forwarded message ----------
From: Neil Williams <codehelp@debian.org>
Date: 27/11/2007 20:01
Subject: Re: Fwd: About dpkg-shlibdeps checks
To: Hector Oron <hector.oron@gmail.com>
Cc: Wookey <wookey@aleph1.co.uk>
Hector Oron wrote:
> Hello codehelp,
>
> We would need to patch Dpkg::Shlibs to use different paths. I
> address to you, because i have been taking a look to it, and as i do
> not know much perl, i would like to hear your advise on what/where to
> patch. How do i patch a perl module as Dpkg::Shlibs, where can i get
> the source? I have downloaded dpkg source code and i have looked into
> scripts/dpkg-shlibdeps.pl, but i believe that is not what i need to
> do. Any hint?
scripts/Dpkg/Shlibs
Perl modules have the directory structure embedded in the module name
(which is why the names can get so long) so Emdebian::Tools is always a
Tools.pm file in an Emdebian/ directory. The code behind Dpkg::Shlibs is
in the Dpkg/ directory. Shlibs is a complex task and also has internal
modules, Dpkg::Shlibs::SymbolFile so the SymbolFile perl module (.pm
file) is in Dpkg/Shlibs/
Load the perl file in geany - it's about the best text editor I've found
for perl because it picks out the function definitions and creates a
list of objects in each perl file so that you can track what call goes
where.
Also, take a look at the source code for emdebuild because that contains
the remnants of the original dpkg-cross diversion code that used to work
with the shell version of dpkg-shlibdeps and which I converted to Perl
until such time as the dpkg-cross diversions were fully merged into dpkg
itself. Guillem is still working on that.
So the problem is that we need Guillem's changes to make a long lasting
patch to Dpkg::Shlibs because it is this whole area of path redirection
that Guillem wants to fix.
My best advice for now is to do what emdebian-tools has done -
workaround Guillem until such time as #439979 is finally closed properly.
Whatever process needs to locate the correct libraries, set the PATH
variable to what you need before it is called. You can do that as easily
in shell as you can in perl.
All you need is the PATH, LD_LIBRARY_PATH and maybe some other
environment variable changes that dpkg-cross used to do prior to v1.38.
The old dpkg-shlibdeps script in dpkg-cross 1.38 is simply not up to the
job anymore (it's almost a decade out of date) so we need to use the
current version, just within a wrapper that lets the new script see the
files in the way that the old script did.
> On Tue, 27 Nov 2007, Hector Oron wrote:
>>> Until dpkg-shlibdeps has been modified to support natively cross-build,
>>> you'll have to indicate him where to find libraries for other
>>> architectures with LD_LIBRARY_PATH=/usr/arm-linux-gnu/lib/ or similar.
This refers to #439979 which is still open at the moment.
Take care here - you cannot simply change LD_LIBRARY_PATH and then
expect perl to operate. Perl uses shared libraries itself beneath the
interpreter so it needs the normal LD_LIBRARY_PATH to be available, so
append, not replace. In emdebuild (perl), I use:
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";
# $crossprefix is the arm-linux-gnu triplet.
# note that the normal paths are set and the new paths appended.
ld skips over the normal ones silently and only fails if the
$crossprefix paths fail to locate the relevant object file.
> You might have to indicate multipe paths in
> LD_LIBRARY_PATH=/arm-linux-gnu/lib/:/usr/arm-linux-gnu/lib/
This is roughly what needs to be done - but in *your* script, not in
dpkg because the dpkg version will (presumably) be different and will be
TheRightWay(tm).
>> But i still have some questions on this matter.
>> Should i take this as a mid-time hack until dpkg-shlibdeps supports
>> cross-build?
Yes.
> When is that to happen (approx)?
When Guillem uploads a version of dpkg that closes #439979.
> I don't know when it'll support cross-build properly. In theory it's not
> too difficult to do, it's mainly patching Dpkg::Shlibs to use different
> paths when in cross-build situation and cross-build can be easily detected
> with Dpkg::Arch (when get_build_arch() != get_host_arch()).
>
> If someones comes up with a tested patch, it can go in quickly.
That someone needs to be either Guillem or someone working closely with
him, unfortunately.
AFAICT the best everyone else can do is work around the delay.
We've been caught by this because dpkg-buildpackage and dpkg-shlibdeps
were converted to perl from shell without anyone in dpkg checking with
us that this was do-able. The diversions that we used to use simply
would not work with the perl replacements and had to be removed.
dpkg-buildpackage -a still doesn't work so everyone still needs wrappers
to cross build, but the "standard" wrapper had to be removed because
dpkg broke it.
:-(
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
--
Héctor Orón
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHTGmkiAEJSii8s+MRAgy8AJ48Bq64lSCzsyz7wXYYUqGZU0G3GQCg9sJW
ptXgrnCL4MB74BR2x2Pmtmo=
=1F1Z
-----END PGP SIGNATURE-----
Reply to: