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

Re: Renesas SH4 support in emdebian



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: pgpw9hCleQnTT.pgp
Description: PGP signature


Reply to: