On Tue, 15 Jun 2010 11:19:31 -0400 Jim Heck <pinball.rules@gmail.com> wrote: > I am currently evaluating SH as a potential architecture for a project. Unofficial ports are HARD. I'll try and help but things can get tricky. > I would like to target a baked Emdebian as the distribution for this > project. This would be my first attempt at doing a full Emdebian > distro, and normally I would rather start with a known entity like > armel, but the processor choice may be dictated by other issues. I've > read and re-read this thread a few times, as well as much of Emdebian > list traffic over several recent months, and I have some questions. > From my understanding, > > 1. The Emdebian toolchain for SH can be built (in fact I have just built > the gcc-4.4 cross-compiler myself in Squeeze using this method > http://wiki.debian.org/EmdebianToolchain#Buildyourownfromsources). > There is some mention, however, in the notes on the Renesas site > (https://oss.renesas.com/modules/document/?Debian%20%2F%20SH4) that the > SH Debian distribution is being built with a special patch that makes it > binary incompatible with cross compilers. > > "We have applied a patch concerning the _fpcr_value to eglic in > Debian/SH4 distribution. Note that eglic of Debian/SH4 is not > compatible with binary packages that were built with a cross > compiler, eglibc, or glibc included in other Debian distributions." > > Would this mean that code compiled with an Emdebian built cross compiler > will be incompatible with packages that are available in the Debian > ports mirror, and/or also those that have been built on the Emdebian > grip server? Quite possibly, yes. I've got no idea where to proceed with that, except that the packages on the emdebian server for Emdebian Grip SH4 are native built Debian/SH4 packages. >From the oss.renesas.com page, Section 1.2: "Debian/SH4 uses the default compiler provided by Debian for compilation control (the same compiler is used to compile Debian packages)." What confuses me is that if the patch is in the Debian native compiler, then it will also be in the Emdebian cross compilers. True, it won't be in cross-compilers built directly from gcc sources or by other tools (except CodeSourcery) but Emdebian cross-compilers are built from Debian sources and Debian sources include the patches to GNU which are used to build the native compiler. Hector: Can you clarify whether the patch is included in the build of cross-compilers for Emdebian? > 2. I realize from reading the thread that there is no testing or testing > migration support for SH, since it is still a Debian "port" architecture > and not yet on the official Debian server. I'm also trying to > understand the issues with reprepro and the other tools used to work > with Emdebian. I also understand that this is very unlikely to be > rectified for SH in the Squeeze time-frame. The issues are principally getting SH4 to a sufficiently complete build of all of Debian that the port is no longer "unofficial". > Does this then mean that if > one were going to try to release a system based on SH and Squeeze, that > it would only work if one were to create their own private Grip mirror > for SH at some given point so that they could cut off the of updates to > the packages at about the time that Squeeze is released? You would, in effect, not have SH4 for Squeeze. What you'd have is SH4 based on Sid on a particular date. This is difficult, but you've got the general idea correct. What you'd need to do is quite complex (but is what I did for Emdebian Crush 1.0). 1. Start copying Emdebian Grip into a local reprepro SH4 mirror of Sid (unstable) for SH4. 2. When Squeeze enters the freeze, STOP the update / mirroring of Sid. This is vital. Monitor debian-devel@lists.debian.org for this moment. Watch for emails from the release team. Current expectations are some point in August. 3. Monitor packages which migrate into Squeeze after that point - these will only be ones where release-critical bugs are fixed. There's no easy way to do this, other than to have a local mirror based on Emdebian Grip Squeeze for i386 and compare the package lists, then pull those package names from Emdebian Grip Sid SH4. Note that you are comparing Emdebian Grip Squeeze i386 with Emdebian Grip Sid SH4. The version strings must match exactly. 4. Manually pull those packages (and only those packages) from Emdebian Grip Sid for SH4. You have to be quick here - it is quite possible that the maintainer will upload a new version of the source package to Sid after the previous version migrates into Squeeze, which then gets built for SH4. The new version in Sid will *not* migrate into Squeeze alongside the other architectures (because of the freeze) but WILL replace the one you do want and it will do that *immediately* that the new version is built for SH4. As SH4 isn't going into Squeeze, this means that the old version will simply disappear from the debian and Emdebian mirrors. 5. Manually pull in any missing dependencies - although I will try and get those resolved ahead of the freeze, so this shouldn't be too much of a problem. In practice, you might opt to ignore release-critical bug fixes and just take Squeeze as-is on Day1 of the release freeze. > In other > words, will the fact that the ports mirror only supports unstable mean > that it will continue to process updates for a Squeeze distribution > beyond Squeeze's freeze? Yes, unstable will continue to roll ever onwards and as there is nowhere for SH4 packages to migrate, they will simply be replaced by new versions. > Am I correct in assuming that this method would also make it very hard > to pickup any updates whatsoever, since it would be very hard to > manually feed those updates to reprepro? reprepro won't be a problem as long as you always pull the source alongside the updated binaries. Use includedsc and includedeb. My thinking is that, when the Squeeze release freeze is called, we might "invent" a new suite which actually gets frozen immediately and is a snapshot of Sid for SH4 on that day. We need to call it something other than squeeze (so that the other architectures can continue updating RC bugs normally) and it will only contain SH4 packages and Architecture:all packages. Any offers of a name - perhaps sid-sh4 or sh4rc1? What we can't call it is squeeze* because that will let people think it's "official". > Sorry I have tried reprepro in > the past, but I am nothing of an expert in its nuanced use. I do > remember it was hard to get certain manual operations to occur smoothly > (at least in the Etch era when I last used it). reprepro requires that you use it as Debian would use it - always include the sources, always migrate packages with source and never mess around with manual tricks inside the lists. This is why reprepro can get so confused with the cross-compiler repository - it absolutely 100% relies on matching binaries to sources. (Not a bad thing for a mirror of GPL software.) > One other thought that occurred to me is that I could use reprepro to > pull a private source only repository of just the packages I want in my > distribution based on Squeeze testing (and eventually stable) and then > setup my own private autobuilder network to build those packages. Does > autobuilder only support native building, or is there a way to setup to > use an Emdebian cross compiler environment to build packages? The auto builder used for Crush 1.0 is no longer operational (it requires large amounts of work and isn't really auto so much as serial). emgrip is the heart of Grip processing, what's needed is a custom wrapper that passes the packages in and puts them into reprepro at the end. Debian will continue to build the packages for you and Emdebian Grip will continue to update Sid with the gripped versions. All you need to do (!) is pull the right packages at the right time, *if* you want to update your snapshot. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpUb3XfIFr6I.pgp
Description: PGP signature