ftp://ftp.azstarnet.com/pub/linux/axp/axpbin-binutils-1.tar.gz
ftp://ftp.azstarnet.com/pub/linux/axp/inc-and-libs.0.35.4davidm.tar.gz
ftp://ftp.azstarnet.com/pub/linux/axp/libc-linux-0.35.4davidm.patch.gz
They are both >2MB in size so now is a good time to get that new
coolant for your modem.
Pretty much all changes are due to the fact that the new
assembler/linker can properly handle weak aliases. I rebuilt libc
from scratch to take advantage from this. To make sure nothing got
lost, I verified that the external symbols in the new libc are a
proper superset of the old one (it's a superset because most system
calls are now defined as "__syscallname" with "syscallname" being
defined as a weak alias). I didn't verify the other libraries (libm
etc.) and you may want to be careful anyway, as there is always the
chance that something broke unexpectedly. So before upgrading, I'd
suggest you make backup copies of the old as, ld and other binutils
binaries as well as the libraries and include files.
Notice that even though libc is now compiled with GNU_STABS defined,
the stabs that are normally used for aliasing are not functional.
Both the assembler and the linker treat them correctly, but the ECOFF
linker reads in external symbols only (for efficiency) and because
stabs are debugging information, the linker never actually sees those
stabs. The Cygnus people recommend to use .weakext instead and not to
worry about trying to fix the GNU stabs aliasing. As that is the easy
way out, it's what I did. The upshot of all this is that you can
safely ignore all GNU stabs aliases---they get compiled correctly but
are not used/visible anywhere.
Let me emphasize that the new libraries *require* the new binutils.
The old linker can't handle weak alias properly. Also, the new
binutils fix a number of other bugs, so it's probably a good idea to
upgrade anyway. (For MILO folks: the assembler in the new binutils
generates identical output for the Noname PALcode compared to my
earlier "as" release, so I'm fairly confident it is safe to use these
tools for building PALcode.)
The binutils are based on a recent Cygnus snapshot of "gas" so I don't
think I can make the sources widely available. I'll submit a patch to
Cygnus and hope it will make it into the next full release. In any
case, if you need the sources, just give a holler and I'll find a way
to make them available.
And now the final, unfortunately bad news: as alluded to before, the
libraries contain encryption code that for some weird reason may not
be exported outside the US (the irony of all this is that the crypt
code was written in the Netherlands...). As has been pointed out by
some of you, the password encryption is not the problem (there appears
to be no export restriction on one-way hash functions). However, the
library contains regular DES encryption which to my knowledge falls
under the restrictions. This is bad because I really don't have the
time to maintain a separate libc that has the encryption code removed
(downloading libc over a 14.4K link takes forever). So, at this
point, if you're outside the US, you can't get the libc
sources/libraries. So here my request for help: could somebody inside
the US with a fast network link strip the encryption code both from
the libraries and the sources and then make it available to our
friends outside the US? I can give you a list of files involved (it's
all self-contained, so this is a short list). Then, somebody outside
the US can ftp this and add back the encryption code (which is readily
available on non-US sites and can be put back into libc in a matter of
minutes). I'm afraid this is rather complex and I doubt it will work
out, but I don't know of any better solution under the given
circumstances. Fortunately, in the future we should be able to work
off of source diffs and those are very unlikely to involve the crypto
code in any significant way.
--david