[LV] Success! was: Re: Status of the toolchain build scripts?

[Jan-Benedict Glaw]

On Mon, 2007-07-09 16:17:33 +0100, Maciej W. Rozycki <macro at linux-mips.org> wrote:
> On Mon, 9 Jul 2007, Jan-Benedict Glaw wrote:
> 
> > However, in the long-term, uClibc is probably *not* the route to go.
> > GNU libc should be taken. The basic port is quite straight-forward,
> > but there are some interesting pieces:
> > 
> >   * Dynamic loader
> > 	  I was told that generating PIC code currently doesn't work
> > 	due to GCC bugs/missing features/...  The NetBSD people worked
> > 	on that and have patches in their CVS repo. Once these go
> > 	upstream (ask Mark!), the first issue should be fixed.
> > 	  The second issue is that you need to have an idea of the
> > 	process of dynamic linking.
> 
>  That's about the only actual requirement for getting glibc going.  Plus 
> stuff like syscall wrappers, etc.

syscall macros should be easy to transplant from uClibc. As for the
wrappers, we can most probably simply use whatever i386 has.

Our syscall table may need a review, ie. adding what has recently been
added and drop legacy stuff.

> >   * TLS
> > 	  Since GNU libc abandoned linuxthreads (and uses NPTL now),
> > 	working TLS simply is requires. This'll require at least
> > 	binutils hacking for the relocs (and probably also some GCC
> > 	hackery.)
> > 
> >   * NPTL
> > 	  Long-term, NPTL is *the* threading library for linux.
> > 	This'll need some additional handling functions to be
> > 	implemented.
> 
>  You can build and run glibc without these.  I think I will only do it 
> once (modulo obvious bugfixes) and for glibc 2.4 only (using GCC 4.1.2, or 
> whichever 4.1 version is the newest then).  But once that is done, it 
> should be easy to support such a configuration with glibc 2.5 or 2.6, as 
> somebody has taken over the task of maintaining linuxthreads in a similar 
> manner that ports are.

Why start with an old GCC there? At least the PIC stuff should be
fixed by the NetBSD guys (though the patches probably easily apply to
older GCC versions.)

>  I do not want to follow this path long-term, but this step will let 
> people make a real use of their systems while the TLS ABI is being agreed 
> upon -- given the past experience with other platforms, assuming it will 
> go fast and smooth would be unjustified optimism.

:-)  I remember the weeks and months the PA-RISC people fought with
it. No day with some regressios being fixed and others showing up
again. Seems NPTL is somewhat "sophisticated" to implemend *chough*...

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of:              What we do for ourselves dies with us. What we do for
the second  :         others and the world remains and is immortal. (Albert Pine)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/vax-linux/attachments/20070709/966db8bb/attachment.pgp>
-------------- next part --------------
_______________________________________________
Linux-Vax mailing list
Linux-Vax at pergamentum.com
http://www.pergamentum.com/mailman/listinfo/linux-vax