Cross compiler ITP (armel)
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Cross compiler ITP (armel)
by Hector Oron
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Ben Hutchings-3
::
Rate this Message:
On Sun, 2009-11-01 at 23:14 +0100, Hector Oron wrote:
> Hello, > > I would like to do a little explanation on the ITP I have filled for > {linux,binutils,eglibc,gcc-4.3,gcc-4.4,gdb}-armel. > > These set of packages provide a cross toolchain for armel targets to > be built on i386 and amd64 platforms (maybe ppc could be added) > > In order to avoid code duplication in the archive, this packages > build depend on -source packages. At present, there is nothing that will ensure that the binary packages you build are released along with the packages containing their actual source. It would therefore require manual attention to ensure that we meet the source distribution requirements of the GPL, which the FTP team really hates having to do. Until the FTP team implements a means of automatically recording some build-dependencies and the versions actually used as additional source dependencies, and ensuring that these source dependencies are satisfied within each release, you should not use this approach. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou |
|
|
Re: Cross compiler ITP (armel)
by Matthias Klose
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Ben Hutchings-3
::
Rate this Message:
On Mon, 2009-11-02 at 02:34 +0100, Matthias Klose wrote:
> On 02.11.2009 00:00, Ben Hutchings wrote: > > On Sun, 2009-11-01 at 23:14 +0100, Hector Oron wrote: > >> Hello, > >> > >> I would like to do a little explanation on the ITP I have filled for > >> {linux,binutils,eglibc,gcc-4.3,gcc-4.4,gdb}-armel. > >> > >> These set of packages provide a cross toolchain for armel targets to > >> be built on i386 and amd64 platforms (maybe ppc could be added) > >> > >> In order to avoid code duplication in the archive, this packages > >> build depend on -source packages. > > [...] > > > > At present, there is nothing that will ensure that the binary packages > > you build are released along with the packages containing their actual > > source. It would therefore require manual attention to ensure that we > > meet the source distribution requirements of the GPL, which the FTP team > > really hates having to do. > > > > Until the FTP team implements a means of automatically recording some > > build-dependencies and the versions actually used as additional source > > dependencies, and ensuring that these source dependencies are satisfied > > within each release, you should not use this approach. > > I disagree. It's not worse than the current scheme splitting up GCC uploads into > three different source packages, forced by the release team. currently reject any new packages that use source code from their build- dependencies. It would likely be a waste of Hector's time to continue with this approach. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou |
|
|
Re: Cross compiler ITP (armel)
by Bernd Zeimetz
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Matthias Klose
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Mike Hommey
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Hector Oron
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Philipp Kern-4
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Goswin von Brederlow-2
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Goswin von Brederlow-2
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Mark Hymers-3
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Florian Weimer
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Ben Hutchings-3
::
Rate this Message:
On Tue, 2009-11-03 at 07:31 +0100, Florian Weimer wrote:
> * Ben Hutchings: > > > You can disagree all you like, but I believe that the FTP team will > > currently reject any new packages that use source code from their build- > > dependencies. > > Surely this is not true because that would rule out many programs > written in C++. Yes, my original statement was much too broad. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou |
|
|
Re: Cross compiler ITP (armel)
by Hector Oron
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Goswin von Brederlow-2
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Neil Williams-4
::
Rate this Message:
On Tue, 03 Nov 2009 20:22:14 +0100
Goswin von Brederlow <goswin-v-b@...> wrote: > Hector Oron <hector.oron@...> writes: > > > Hello, > > > > 2009/11/2 Goswin von Brederlow <goswin-v-b@...>: > >> Why do you need --sysroot support? Or what prevents a --sysroot > >> of / when using the multiarch directories? > >> > >> It seems like wasted work with multiarch being a release goal for > >> squeeze. Hop on the wagon and make it work for you too. for toolchain usage. sysroot would then be internal to the toolchain build. > > As you already know, multiarch does not have a plan (yet) for -dev > > packages. In terms of cross compiling, things are unclear which way > > is painless sysroot or multiarch (orthogonal solutions). The more I > > think, the more I believe sysroot is painless. As mentioned off-list, I disagree strongly. sysroot - as it appears at the moment - retains the hacks in dpkg-cross which means that cross-building anything more complex than a trivial rootfs becomes impossible. Cross-building needs to stop requiring package hacks, package renaming, version string hacks and the consequent complicated changes to the dependency chain. dpkg-cross and apt-cross can take us no further - neither package can have a role in cross-building long-term. The hacks are workable for only very limited situations. Achieving anything like a reasonable binary distribution on more than one architecture is all but impossible - Emdebian Crush 1.0 required many, many individual hand-implemented super-hacks to get into a releasable state and that was only a few hundred packages for a single architecture. There is no chance of Crush 2.0 being ready because we simply cannot repeat the same miracle that gave us Crush 1.0 without ditching the hacks in dpkg-cross. Once we have multiarch, Crush 3.0 for Squeeze+1 will be the objective, supporting several hundred (maybe a few thousand) packages all on at least four architectures. http://lists.debian.org/debian-embedded/2009/08/msg00005.html *Any* method that requires any kind of hacks like the current ones in dpkg-cross will not be capable of supporting a sane cross-building system for a cross-built binary distribution. If sysroot can work without hacks, maybe it could be usable but the removal of the hacks is the imperative here. > Your cross-libfoo-dev package would have to solve this. Changing package names is not acceptable - that is what is causing the current logjam. The cross package needs to retain correlation with the file in the archive so that the foreign package can be upgraded alongside the native arch package and so that the foreign package can be installed whilst taking into account the existing Arch:all dependencies. In essence, 'apt-get upgrade' would need to be able to upgrade the native arch and the foreign arch at the same time - or at least tell the user that the native upgrade also needs a few foreign packages upgraded. Otherwise, what happens (now) is that as the foreign package (with a changed package name) cannot be correlated with the package from which it was built, the built package is therefore removed (with all it's foreign reverse dependencies) if there is any kind of transition. The removed foreign packages then need to be reinstalled all over again, once the native packages have upgraded. Even if the resulting process actually does this, it's better to do this in one operation. Merely allowing the frontend to realise that the foreign package has been updated in the archive, makes it possible. The problems are outlined in #502433. The dependency calculations need to take account of what is already installed as foreign without native versions being considered, yet still take account of Arch:all - AFAICT multiarch allows this mode. For it to work, the package actually installed has to retain a correlation to what is in the Packages file, so that the correct dependency chain can be constructed. Changing package names (or even version strings due to strict versioned dependencies) in such situations is only going to lead to non-installable combinations, as we have now. The current behaviour of dpkg-cross interrupting the process of downloading, rebuilding,renaming and then installing packages *has* to stop. The current dpkg-cross hacks have to be removed and dpkg needs to be able to understand how to deal with foreign versions of -dev packages in a multiarch setting - then frontends like apt need to be able to calculate the dependencies correctly. (This *should* be as simple as identifying which packages are foreign then starting the dependency calculation from the Packages file for that arch, taking account of Arch:all packages that are already installed {as most frontends already do}). > Usualy the > cross-libfoo-dev package would only contain the *.so link in > /usr/lib/arch-os-libc/ and depend on the normal -dev package. Forget dpkg-cross, it is a dead package walking. The hacks upon which it utterly relies need to be dropped. > For multiarch the problematic part is actually just splitting out the > *.so links into an arch:any package and common header files into an > arch:all package. A lot of work to modify rules files and lots of new > tiny debs for the archive (and NEW processing). So it got put off for > later. Your dpkg-cross can automatically do this in 99% of cases > leaving verry little handholding. Please drop ideas of dpkg-cross working with multiarch - what remains of dpkg-cross after multiarch will not be anything like what it currently achieves. We need a system that can work without mangling package names (as this corrupts dependency calculations) and without interrupting the normal package installation process. That way, 'apt-get -a armel build-dep foo' becomes practical - that's what cross-building needs from multiarch. In particular, we *really must* stop renaming packages when installing a foreign version of a -dev package. I might be wrong, but I thought that was what multiarch promised - at least if considering a -dev as if it was just another package. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ |
|
|
Re: Cross compiler ITP (armel)
by Goswin von Brederlow-2
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Hector Oron
::
Rate this Message:
|
|
|
Re: Cross compiler ITP (armel)
by Neil Williams-4
::
Rate this Message:
On Wed, 04 Nov 2009 15:11:06 +0100
Goswin von Brederlow <goswin-v-b@...> wrote: > > As mentioned off-list, I disagree strongly. sysroot - as it > > appears at the moment - retains the hacks in dpkg-cross which means that > > cross-building anything more complex than a trivial rootfs becomes > > impossible. Cross-building needs to stop requiring package hacks, > > package renaming, version string hacks and the consequent complicated > > changes to the dependency chain. > > To be fair that doesn't help NOW. Of course, but 'now' is stuck in a dead end. Please accept that the dpkg-cross/apt-cross hacks are a complete dead end. Sometimes it is best to abandon one direction and start afresh. I maintained the existing hacks and wrote quite a few of my own to get the system to the point where we could have Emdebian Crush 1.0 - I can honestly say that I believe there is no "now" for dpkg-cross/apt-cross methods. If the RFH for apt-cross does not result in any new work, I'm considering turning it into an RM: before the Squeeze freeze - I'll almost certainly be turning the RFH into an O: unless someone comes forth. > While I agree cross-building should > use the multi-arch directories that will be in preparation of > multi-arch becoming a reality. Until such a time dpkg-cross/apt-cross > still need to do the renaming hacks. But all those hacks are well > understood and existing. > > So what I'm suggesting is doing it with hcks now in such a way that > multiarch will remove the remaining hacks when it becomes reality. I'm not sure what is gained by putting more work into a broken system. apt-cross is dead, if I hadn't nailed it to ftpmaster it'd be pushing up the daisies already. It's not so much gone to meet it's maker, it's been given up for dead by it's author! $ perl -e 'print "parrot\n" if ($apt-cross =~ "/Norwegian blue/");' $ parrot (apologies to Mr's Palin & Cleese.) > Well, ia32-apt-get did it just fine and all automatic. There also was > no foreign package with changed name in the archive but the original > foreign package was used. But none the less the converted foreign > package had the right "Source: <source> (version)" information giving > a clear correlation between the converted package and the source it > was build from. Also in any kind of transition the source > transitions. That means both the native and foreign package change > their source and therefore binary version. They are always both > updated and transitioned together. As for forcing both the native and > foreign package to be upgraded by the user as pair that is a simple > Depends. So that really isn't a problem. It is just a matter of > getting the information at the proper place. > > The usage is verry simple with ia32-apt-get: > > ia32-apt-get update > ia32-apt-get [dist-]upgrade > > Or with "ln -s /usr/share/ia32-apt-get/* /usr/local/bin" you can even > save the ia32- prefix. Get your apt-cross to be equaly user friendly. rewrite. I certainly do not have time to consider any such effort. > > The problems are outlined in #502433. The dependency calculations need > > to take account of what is already installed as foreign without native > > versions being considered, yet still take account of Arch:all - AFAICT > > multiarch allows this mode. For it to work, the package actually > > installed has to retain a correlation to what is in the Packages file, > > so that the correct dependency chain can be constructed. Changing > > package names (or even version strings due to strict versioned > > dependencies) in such situations is only going to lead to > > non-installable combinations, as we have now. > > ia32-apt-get does this by changing the Packages files post download > and only renaming packages that need to be foreign. There is > absolutely no reason the same renaming can not be applied to Sources > and control files for Build-Depends. That way anything (like apt, > dpkg, sbuild) looking at the Packages, Sources or debian/control files > sees the correct dependency chain and will install exactly the same > packages with the renaming or with multiarch. And a normal > dpkg-checkbuilddeps would also detect missing or wrong packages just > like in the non-cross case. > > But what has that got to do with #502433? clean dependency path from a clean chroot to a full libgtk2.0-dev build environment using foreign packages. If you hack around the package names, the careful work of dozens of maintainers is thrown at /dev/null. It's not surprising that things break as soon as you try something remotely complicated. > That looks to me to be 2 bugs: > > 1) The libkrb5-dev explicitly mentioned in debian/xcontrol does not > override the heimdal-dev in debian/control. > > 2) The heimdal-dev-cross package contains a broken library or misses > one. It seems to fall back to the native library, which has the wrong > fileformat. There should be a /usr/arm-linux-gnu/lib/libgssapi_krb5.so. > > [Maybe it is looking only in the multiarch directoy: > /usr/lib/arm-linux-gnu/libgssapi_krb5.so?] AFAICT I did investigate such ideas but got nowhere. It wasn't that simple. Patches welcome! > > The current behaviour of dpkg-cross interrupting the process of > > downloading, rebuilding,renaming and then installing packages *has* > > to stop. The current dpkg-cross hacks have to be removed and dpkg needs > > to be able to understand how to deal with foreign versions of -dev > > packages in a multiarch setting - then frontends like apt need to be > > able to calculate the dependencies correctly. (This *should* be as > > simple as identifying which packages are foreign then starting the > > dependency calculation from the Packages file for that arch, taking > > account of Arch:all packages that are already installed {as most > > frontends already do}). > > With multiarch this will hopefully all go away. But till then you > can't get around some magic somewhere. it needs multiarch to fix. If you have patches that can show this magic, fine, but AFAICT there is no magic available to fix all of the problems in the current hacks. heimdal is only the most obvious one. The others relate to the problem of keeping a mixed system upgradable as well as more that are documented in the debian-embedded mailing list archive and the EmdebianCodeAudit pages on the Debian Wiki. > In ia32-apt-get I only hook > into two places: "apt-get update" and dpkg-deb. "apt-get update" needs > to modify the Packages files post download for the renaming. That > fixes all the Depends. And "dpkg-deb" handles the extraction of > individual deb packages. All the dependency calculations in apt and > dpkg remain 100% as is. For building sources you also need to hook > into the debian/control file but you do that already with the > deban/xcontrol. I agree that the -cross packages should not be handled > magically in a second pass like it seems to be done now. But that is a > implementation detail and not due to the renaming and converting of > packages. with dpkg-cross but dpkg-cross is at least able to continue doing what it can and what it has always done, unlike apt-cross. > >> Usualy the > >> cross-libfoo-dev package would only contain the *.so link in > >> /usr/lib/arch-os-libc/ and depend on the normal -dev package. > > > > Forget dpkg-cross, it is a dead package walking. The hacks upon which > > it utterly relies need to be dropped. > > The prolem is time. multiarch takes time. After the ubuntu multiarch > announcement the cabal seems to have gone dormant again or back into > their back rooms for secret coding. Who knows when multiarch will be > actually added. Hasn't happened in the last 5 years. developer time available for apt-cross than there is for multiarch. Right now, I have zero. What's the saying about developers starting lots of threads and always having to throw some away? Things have changed radically for me in the last 6 months, the amount and kind of work that I am willing to undertake has been drastically affected. apt-cross is just one of the casualties, but it's defects were already mortal. It was written as a temporary stopgap but the gap has outlived the hack. Maybe things will change in 2010. In effect, the developer of apt-cross has given it up and unless someone steps up, it will disappear in a blaze of bitrot. > I never said anything about dpkg-cross working with an finished > multiarch. Once multiarch is fully reality dpkg-cross is obsolete. Definitely agreed. ;-) I would venture that apt-cross is already close to obsolescence. If anyone thinks differently, please help with the package or request adoption. I won't hinder anyone who wants to take it over but I cannot undertake to help development of the current apt-cross codebase. > The > point was to use the bits and pices of multiarch that are there now > (which is the multiarch directories and toolchain support for them) in > dpkg-cross now. And to use more and more of multiarch as it comes > along and less and less of dpkg-cross. That would mean a smooth > transition. I don't think we can support a transition, that's the problem. The current method is at an impasse - IMHO there is no route from apt-cross/dpkg-cross to form a basis from a transition, except abandoning the hacks and rewriting from scratch. To do that, we need multiarch to at least be understood by dpkg and apt. By the time multiarch is in that state, I expect to have the time to do the coding. IMHO there is no point wasting more time with apt-cross now. > With sysroot you will be stuck with sysroot until the day multiarch is > 100% reality and then you need to do a 180 degree turn and change > everything from sysroot to multiarch. And all that time none of the > cross patches can be merged into debian. We already need a complete rewrite - not sure if that means a 180 degree turn or actually more of an 180 degree turn followed by a path of uncertain length into the past back to the branch point where we can get things done TheRightWay. _____ apt-cross___| ____/ \_____ multiarch IMHO it's better to just do: |___ apt-cross___| ____ \_____ multiarch Granted, I'd like to avoid having to do another about-turn which is why I think sysroot is the wrong path, but I fail to see a path from apt-cross into a full multiarch that does not mean completely rewriting apt-cross and therefore we may as well start the rewrite as soon as something of multiarch is in place. (Otherwise we end up with TWO rewrites - actually make that 3 - apt-cross has already been rewritten once.) I don't want to get involved in another mire of workaround hacks that try to compensate for having a broken implementation and a flawed design. I do not have the time. Perhaps this list will indicate some of the problems which need to be overcome to have anything for "now": http://lists.debian.org/debian-embedded/2009/08/msg00016.html 28 potential bugs (not all in apt-cross but all related to getting something useful "now" out of the dpkg-cross/apt-cross system), some could easily be deemed RC, most of the others are at least "important" severity, most directly flow from the initial design which, in turn, comes directly out of the hacks that underpin dpkg-cross. *THAT* is why I believe apt-cross is a dead end. In some ways, it was *designed* as a dead end. Some of the very earliest commits describe how it was never expected to have a long future as a package. It was written for a short term need and it's days have come and gone. > (FYI the renaming is just because dpkg can't handle 2 packages with > the same name but different arch. Once that part of multiarch is in > apt/dpkg the renaming can be changed from foo-cross to foo:arch where > needed. Multiarch adds a feature, dpkg-cross drops one. That is the > way dpkg-cross should take.) There isn't any point, once dpkg understands that element of multiarch, dpkg-cross has nothing left to do. Yes, that is the path that dpkg-cross must take; the path to it's own oblivion. It has always been that way. The problem is that apt-cross is hardwired to the broken dpkg-cross methods and would need to be rewritten. *I do not have the time*. Sorry. (Why is it so hard to give up a lost cause? Why do others still think there is hope despite evidence to the contrary?) There again, this is free software so if anyone fancies doing the work, go ahead. Don't wait for me to retitle the RFH to an O, if someone here has the motivation and the time, skip straight to an ITA. It would not be a hostile adoption, I'd welcome it. Just don't expect me to help with the rewrite. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ |
signature.asc (845 bytes) | < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
