[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: binutils-multiarch



On Sun, 26 Aug 2007 21:53:47 +0400
"Nikita V. Youshchenko" <yoush@debian.org> wrote:

> >> During the rewrite of dpkg-cross, is it achievable to use
> >> binutils-multiarch to solve some of the issues regarding reading
> >> foreign shared library ELF files?
> > 
> > It would appear usable - with binutils-multiarch installed, the
> > dpkg-cross versions of objdump and strip are unnecessary.
> 
> At least previously, binutils-multiarch did not provide cross-assemblers, so
> it could not be used for cross-compiling. This made cross-binutils
> required. And as soon as cross-binutils are installed, there was motivation
> to use strip and objdump from those.

OK, thanks. I'll use the cross-assemblers from our toolchain and return
to using the binutils-multiarch versions of strip and objdump because
of the improvements in those. As with the diversions, I'll keep old
copies in /usr/share/dpkg-cross for reference / problem solving.

I now have a replacement shell "library" (it's only 60 lines) that
replicates the functions of our dpkg-buildpackage diversion script
(which was perl) and with a few more tests I will be able to submit
this as a patch to dpkg-dev. With other changes to dpkg-shlibdeps to
merge that into dpkg-dev, I anticipate this construction:

1. dpkg-dev does not need to depend on dpkg-cross

2. dpkg-cross Enhances: dpkg-dev

3. This code (or something quite like it) in dpkg-buildpackage from
dpkg-dev:

DPKGCROSSENABLE=0
if [ -f /usr/share/dpkg-cross/buildcross ]; then
 . /usr/share/dpkg-cross/buildcross
 DPKGCROSSENABLE=1
fi

The '-a' switch to dpkg-buildpackage then calls a new function, patched
into dpkg-dev:

function enhance_cross {
	if [ $DPKGCROSSENABLE gt 0 ]; then
		setup_cross
	fi
}

setup_cross comes from our file and basically implements our path and
environment changes within the dpkg-dev version of dpkg-buildpackage
and our /usr/share/dpkg-cross/gccross and cross-config.$arch files.

The remaining changes are in gccross and porting our dpkg-shlibdeps
diversion code into the dpkg-dev version (both are perl) to use the
binutils-mulitarch versions of objdump and strip.

We remove the dpkg-buildpackage and dpkg-shlibdeps diversions, relocate
the scripts into /usr/share/dpkg-cross alongside the old versions of
objcopy, objdump and strip. Only dpkg-cross goes into /usr/bin/. I'm
thinking that we could have a /usr/share/dpkg-cross/bin/gccross so that
there is no chance of the old scripts being called accidentally. It
seems strange to have a bin/ below share/ but I'm not sure what else to
call it at the moment. The only file on my system in a similar location
is /usr/share/openoffice/bin/openoffice-xlate-lang which is also a perl
script.

This will be in 1.99+2.0.0pre2.

-- 


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

Attachment: pgpQW3DB2K8Q4.pgp
Description: PGP signature


Reply to: