Hello, Neil answered me off-list. I'm putting this info on-list just FYI
---------- Forwarded message ---------- From: Neil Williams <[EMAIL PROTECTED]> Date: 27/11/2007 20:01 Subject: Re: Fwd: About dpkg-shlibdeps checks To: Hector Oron <[EMAIL PROTECTED]> Cc: Wookey <[EMAIL PROTECTED]> 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-----