Bug#453267: tested patch
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
Description: OpenPGP digital signature
Bug#453267: tested patch
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/
Bug#453267: tested patch
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 tho
Bug#453267: tested patch
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/
Bug#453267: tested patch
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 +, 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 Description: OpenPGP digital signature
Bug#453267: tested patch
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 +, 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453267: tested patch
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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/
Bug#453267: tested patch
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 Description: OpenPGP digital signature
Bug#453267: tested patch
Raphael Hertzog wrote:
> On Tue, 04 Dec 2007, Neil Williams wrote:
>> On Wed, 5 Dec 2007 00:01:22 +0100
>> Raphael Hertzog <[EMAIL PROTECTED]> 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 a
Bug#453267: tested patch
On Tue, 04 Dec 2007, Neil Williams wrote:
> On Wed, 5 Dec 2007 00:01:22 +0100
> Raphael Hertzog <[EMAIL PROTECTED]> 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/
Bug#453267: tested patch
On Wed, 5 Dec 2007 00:01:22 +0100
Raphael Hertzog <[EMAIL PROTECTED]> 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/
pgp6NZvDnv5Nk.pgp
Description: PGP signature
Bug#453267: tested patch
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/
Bug#453267: tested patch
On Tue, Dec 04, 2007 at 05:58:01PM +, 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 <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453267: tested patch
Frank Lichtenheld wrote:
> On Tue, Dec 04, 2007 at 10:27:35AM +, 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
Description: OpenPGP digital signature
Bug#453267: tested patch
On Tue, Dec 04, 2007 at 10:27:35AM +, 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 <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453267: tested patch
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/
--- dpkg.old/scripts/Dpkg/Shlibs.pm 2007-11-23 02:42:51.0 +
+++ dpkg-1.14.11/scripts/Dpkg/Shlibs.pm 2007-11-28 22:06:15.0 +
@@ -25,11 +25,28 @@
use Dpkg::Gettext;
use Dpkg::ErrorHandling qw(syserr);
use Dpkg::Shlibs::Objdump;
+use Dpkg::Arch;
use constant DEFAULT_LIBRARY_PATH =>
qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
/emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
-our @librarypaths = (DEFAULT_LIBRARY_PATH);
+my @shlibdeps=();
+# ARCH for some awkward builds
+my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if ($ENV{ARCH});
+# 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",
+"/emul/ia32-linux/lib", "/emul/ia32-linux/usr/lib" );
+}
+our @librarypaths = ((DEFAULT_LIBRARY_PATH), @shlibdeps);
# Update library paths with LD_LIBRARY_PATH
if ($ENV{LD_LIBRARY_PATH}) {
pgpRmMrVgW4AO.pgp
Description: PGP signature
