[LV] Fully-functional port of glibc available for VAX/Linux
Maciej W. Rozycki
macro at linux-mips.org
Mon Nov 2 01:53:56 CET 2009
Hello everybody interested!
I am pleased to announce the availability of a fully-functional port of
the GNU C library, version 2.4, to the VAX/Linux platform. The port
comprises the C library itself, the dynamic linker, C run-time startup
files as well as system headers, and is accompanied with binutils, version
2.20, and updates to GCC, version 4.1.2, required to build the library as
well as make use of it. Additionally some changes are required for the
Linux kernel.
I have made source and binary packages available at my FTP site. The
packages have been designed to form a cross-compilation environment, where
you can build programs for the VAX/Linux target system using your host
system of choice. Mine is i386/Linux and hence the binutils and GCC
binary packages are meant for such a system. However the corresponding
source packages can be rebuilt on any host system if need be. The C
library itself has no host-system dependency of any kind and hence its
binary package is compatible with any host system.
To get the sources, navigate to:
ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/SRPMS/
and download these files:
vax-linux-binutils-2.20-1.src.rpm
vax-linux-boot-gcc-4.1.2-22.src.rpm
vax-linux-glibc-2.4-13.src.rpm
To get the binaries, navigate to:
ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/RPMS/
and download these files:
i386/vax-linux-binutils-2.20-1.i386.rpm
i386/vax-linux-boot-gcc-4.1.2-22.i386.rpm
noarch/vax-linux-glibc-debug-2.4-13.noarch.rpm
noarch/vax-linux-glibc-devel-2.4-13.noarch.rpm
noarch/vax-linux-glibc-profile-2.4-13.noarch.rpm
noarch/vax-linux-glibc-static-2.4-13.noarch.rpm
Changes required for the Linux kernel were posted here recently. For the
reference, I have made them available from here too:
ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/linux/vax/
Please note the shared objects from the binary glibc-devel package, that
is ld-2.4.so, libc-2.4.so, libm-2.4.so, etc., and their associated
symlinks, can be copied to and used on the target system.
As an additional bonus, the following packages are available:
sources:
vax-linux-zlib-1.2.3-1.src.rpm
SysVinit-2.86-2.src.rpm
binaries:
noarch/vax-linux-zlib-devel-1.2.3-1.noarch.rpm
noarch/vax-linux-zlib-static-1.2.3-1.noarch.rpm
vax/SysVinit-2.86-2.vax.rpm
The latter is a native VAX/Linux package! :)
Further development plan (tentative):
Here is a brief list of things to do in the coming months. I have tried
to put the tasks more or less in the order I envisage they might be done.
Some overlap may happen.
1. Porting of platform support (run-time and library, as appropriate) for
languages other than C provided by GCC; this includes Ada, C++, and
Java.
Initial investigation indicates Ada may be supported with a small
effort and some work is required to support the Java library
(exception handling may need to be sorted out while at it).
Additionally the FFI (Foreign Function Interface) library requires
porting. All the other languages and libraries coming with GCC should
work as it is.
2. Adding support for the VAX/Linux platform to GDB.
3. Implementation of C library functions which due to the lack of
platform-specific code for VAX/Linux are provided as non-functional
stubs only.
4. Design and implementation of Native POSIX Thread Library (NPTL)
support. This mostly comprises the Thread Local Storage (TLS) model
and the surrounding infrastructure. All of binutils, GCC and glibc
have to be updated simultaneously for TLS to be correctly supported.
5. Adding profiling support to the C library. Although profiling
libraries are built as a part of glibc compilation, some essential
low-level platform glue code is missing making profiling
non-functional.
6. Porting of C library changes to the then current head of glibc and
upstream submission of all the changes to glibc as well as NPTL
changes for binutils and GCC.
7. Porting of other libraries or programs utilising handwritten assembly
code for performance reasons; this includes at least the GNU Multiple
Precision (GMP) library.
8. Adding long double support -- based on the H-floating format -- both
in GCC and in glibc; an update to binutils may be required too. Right
now the type aliases to double.
9. Testing and bug fixing. There is undoubtedly plethora of bugs hidden
waiting to bite. This task overlaps all the others of course.
I am fairly sure I have missed something to place on the list, so I will
appreciate any suggestions.
FAQ:
1. Q: Version 2.4 of glibc is a very old one. Likewise GCC 4.1.2. What
was the reason behind choosing these versions?
A: These were the last versions I felt like bringing up to date with
LinuxThreads support which was abandoned upstream a while ago. The
reason to insist on LinuxThreads was the ability to get a
fully-working environment without the need to design the NPTL ABI
beforehand, which is not straightforward for the VAX processor.
This way performance evaluation of different approaches to the NPTL
ABI will be possible from a full-featured system.
2. Q: What about upstream submission? Especially given the above.
A: Patches for binutils shall be submitted straight away, as soon as
validation has passed. There are no outstanding binutils patches at
the moment.
Patches for GCC shall follow as they are believed to be more or less
compatible with the current trunk. They have been smoke-tested and
will only undergo further testing once a full user environment has
become available. GCC patches published back in May have been
integrated upstream. Patches developed since then have been
submitted and are pending approval.
Patches to glibc will be submitted once they have been
forward-ported to the then current trunk, which is scheduled to
after NPTL support has been completed. Porting effort is expected
to be moderate due to the self-containment of most of the patches.
3. Q: What about binary compatibility -- is the ABI defined by this
release guaranteed to be stable?
A: Unfortunately the answer is no. Some internal details may need
further tuning, especially as a result of the NPTL effort. The
intent is to get the ABI stabilised by the time patches are
submitted for inclusion with upstream glibc, but let people play
with the port immediately so that any problems have a greater chance
to be found before submission.
4. Q: Can I help with the port? How?
A: Certainly, you are welcome to join the team!
If you feel competent or would like to learn about the VAX
architecture or the core of GNU software, then please pick a task
from the list above and let the list know you would like to get into
it, or if you have an idea to work on, then please let people on the
list know so that someone does not duplicate your effort, which can
be rather frustrating.
If you are not that much into the details of the VAX architecture or
the pieces of GNU software, but you have VAX hardware and would love
to make a good use of it, than please do make use of the tools and
the library, by building your favourite pieces of software, using it
and reporting any anomalies seen to the list.
5. Q: Is there a wiki available for the port?
A: There is none at the moment, although we have a site, at
http://linux-vax.sourceforge.net/. It will undoubtedly be useful to
have a wiki at one point, preferably hosted at our site. If you can
help with arranging that, it will be useful.
6. Q: Is this FAQ complete yet?
A: No, of course not! Please provide us with further questions and we
will strive to work out answers or alternatively please give us an
answer and we will try to find a question to fit.
Acknowledgments:
1. Thanks to Jan-Benedict Glaw for his work on the VAX/Linux kernel.
2. Thanks to all the people who have supported me with this effort -- you
know who you are!
If you have any questions or comments, then please do not hesitate to
contact me, cc-ing the list if appropriate.
Maciej
_______________________________________________
Linux-Vax mailing list
Linux-Vax at mail.pergamentum.com
http://mail.pergamentum.com/mailman/listinfo/linux-vax
More information about the Vax-linux
mailing list