Test version of glibc 2.3.5-10

[Aurelien Jarno]

Hi all,

Petr Salinger has made a lot of work on glibc recently, and we now have
a working glibc. I have build debian packages from revision r972 of the
SVN. I am using them on my laptop without any problems.

Those packages are available on:
http://people.debian.org/~aurel32/glibc/

It would be nice if some of you can test them to make sure they are no
other regression. After a period of test, I think it would be possible
to upload them to unreleased.

There is still a few problem to be solved before though:


* thread cancelation
   cancelable functions are not properly marked in syscalls.list, ...

I am not sure they're is a real list of function that should be
cancellable. Looking on the web, it seems it depends on the libc used.
I have looked at all the functions that are cancellable for Linux, and
verified that it is also the case for kFreeBSD. Below is a list of
functions that are cancellable, by using the "C" flag in the 
syscall.list file, by using the correct calls in the .c file, or by
calling function that are cancellable:

clock_nanosleep()
close()
creat()
fcntl()
fsync()
lockf()
msgrcv
msgsnd()
msync()
nanosleep()
open64()
open()
pause()
pause()
poll()
pread64()
pread
pwrite64()
pwrite
read()
readv()
recvfrom()
recv()
select()
sendmsg()
send()
sendto()
sigpause()
sigsuspend()
sigtimedwait()
sigwaitinfo()
socket()
system()
tcdrain()
wait()
waitpid()
write()

The functions below are not implemented, so there is also no problem:
getmsg()
getpmsg()
mq_receive()
mq_send()
mq_timedreceive()
mq_timedsend()
putmsg()
putpmsg()

The aio_* functions should also be cancellable. The libc currently does
not use the syscall (that are not marked as cancellable), but rather the
default userland code. I don't know if we should use those syscalls, or
remove them from the syscalls.list file.


* "make check" fails

Currently there is a dozen of failures. If they are not regressions, we
can live with those failures a bit, but they have to be fixed.


* when directly executing dynamic libraries (same problem with 2.3.0 too)
  they (as is also dynamic loader) are loaded at base addr 0

This is not a regression. The problem is also present in our old glibc.
Therefore we could live a little more time with this problem.


* ugly-hacks have to be transformed into proper fixes.

Maybe we can negociate conditionnal patching for the Debian package.
dpatch supports that


* struct statfs

Personally I would prefer that the change in the structure is handled
via symbol versioning, therefore we don't need to break the ABI.

Please also note that when the port will move to ftp.debian.org (aj said
at the end of the month), it will not be possible to break the ABI.


* upgrade syscalls.list (from kernel 5.4 or 6.0)

We can live with the old syscalls, however I think we have to switch to
at least 5.4 soon.


Any comment?

Bye,
Aurelien

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32 at debian.org         | aurelien at aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net