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

[Maciej W. Rozycki]

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.

>   * 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.

 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.

  Maciej
_______________________________________________
Linux-Vax mailing list
Linux-Vax at pergamentum.com
http://www.pergamentum.com/mailman/listinfo/linux-vax