Re: arm gnueabi problem with tls.

["Martin Guy" <martinwguy at gmail dot com>]

> > > You'll need to use a copy of CVS HEAD binutils for now if you want EABI
> > > TLS support.
... which is where I gtoo ot stuck in my last attempts to make an arm
eabi xtoolchain with crosstool. There may be something I'm missing,
but my current understanding is that crosstool needs an identifiable
version of the things it uses
- to be able to specify the version of binutils for a particular build
- to be able to download a tarball of the specific version
- to be able to have a version-specific directory of patches to apply
to apply if necessary.

Now as far as I can see, the binutils maintainers have not released an
identifiable version since last summer (2.16.1), which is too old for
ARM EABI work. There is only CVS access, and a directory of daily
snapshot tarballs, but these tarballs only remain on the net for 48
hours (today's and yesterday's), then they disappear so are useless
for crosstool. The Debian maintainers seem to have used a random CVS
version called 2.16.91, but I don't see where these version numbers
come from. My attempt at making a fake tarball from the latest stuff
from CVS makes binaries that report "?.??" as the version number,
which horrifies any version-checking configure scripts.

I mean, I can cobble together *a* working version by fetching from
cvs, bundling them up with some name and putting them in the
"downloads" directory. That might get me one working compiler, but I'd
rather find a solution that would work automatically for other people
as well without making them do the same.

Possible solutions that come to mind are:
# Implement code in crosstool to fish out the CVS version for a
specific date. There is already code to do a similar thing for glibc.
Unfortunately I don't have a fast enough inet connection to be able to
afford this every time I try a new build, so i presume that others are
in the same situation.
# Implement "CVSHEAD" as a pseudo-version in crosstool, that fetches
the very latest version of something (or updates a local copy)
# Automatically take a copy of the daily snapshots and keep them
visible on the web somewhere as an "unofficial binutils snapshot
site", and refer to that.
# Persuade the binutils maintainers to make a new release, just so
that we can name interim versions instead of having to mess about.
Even the presence of a 2.16.3.0.51 tarball or the continuing presence
of daily (weekly? first-of-the-monthly?) snapshots would be an
improvement on the current situation.
# Wait until they release binutils >2.16.1. I can't see when this is
going to happen.

Does anyone have any suggestions as to which might be the least bad of
these options or have a better idea that I am missing?

Ta

   M

--
For unsubscribe information see http://sourceware.org/lists.html#faq