Re: Latest Glibc from CVS has segmentation problems.

[Marcus Brinkmann <marcus dot brinkmann at ruhr-uni-bochum dot de>]

At 07 Mar 2004 10:19:08 -0500,
Patrick J. LoPresti wrote:
> 
> "Alfred M. Szmidt" <ams@kemisten.nu> writes:
> 
> > Oh chirst, this isn't about who is working for who.
> 
> Actually, it might be.  Who can say for certain whether the current
> situation is the result of incompetence or conflict of interest?  But
> true, this is not the main point.

To turn this discussion into something barely useful, let me point out
that nobody will stop anyone from being more helpful to newbies than
the glibc maintainers are (can be, whatever).

glibc is a critical piece of software that affects everybody, so
naturally there are a lot of interests at play.  Ulrich has done a
great job defending glibc against outside crap, and at improving its
implementation.  From what I have seen, this has been a consistent
stance.  Among other things, this is what his responsibility as the
maintainer entails (at least in my opinion).

In my opinion, it is not the responsibility of the maintainer to be
the support guy for everybody.  That simply can't work, in particular
for as wildly used software as glibc is.

So, the natural free software thing to do here would be to start a web
site (not Ulrich, you!) that describes the glibc development and
release process, what to do if you think you found a bug (and what not
to do), how to compile and build glibc and in general to catch the
newbies and help them.

When you have done that, you can wade the development list for newbie
requests and point them to the site you created (and hopefully you did
this before Ulrich replied :)

And newbie has a pretty broad meaning here.  With glibc, everybody is
a newbie who has not studied glibc thoroughly and is intimate with its
internals, really.  I have my own amount of studying, and I still feel
somewhat like a newbie everytime I look into it (less and less so, but
still).  The reason is that for glibc everything is a bit different.
It is more complex, there are more issues to be worried about, and to
make a reasonable design decision you have to be aware of most of
them.  Such information would be really useful to have on a web site,
too.  (For example, how the source tree is structured, in which header
file to put which prototypes, and how the symbol versioning and hiding
works etc etc).  If you don't know how all this works, just finding
the implementation of, for example, read() for your architecture can
be a nuisance.[1]

Of course it is always difficult to get such a thing started, but if
you show to make a reasonable effort, I am sure that any remaining
obscure questions (when you have them in concise form) would be
answered by the gurus, with enough prayers applied.

Thanks,
Marcus

[1] Just look at this naive attempt:
marcus@ulysses:~/gnu/hurd/cvs/libc$ find . -name read.c
./sysdeps/generic/read.c
./sysdeps/mach/hurd/read.c
./sysdeps/standalone/read.c
./sysdeps/unix/sysv/aix/read.c
marcus@ulysses:~/gnu/hurd/cvs/libc$ rgrep ^read\ \( *
manual/stdio.texi:read (including the newline, but not including the terminating null).
marcus@ulysses:~/gnu/hurd/cvs/libc$ rgrep ^__libc_read\ \( *
sysdeps/generic/read.c:__libc_read (int fd, void *buf, size_t nbytes)
sysdeps/mach/hurd/dl-sysdep.c:__libc_read (int fd, void *buf, size_t nbytes)
sysdeps/mach/hurd/read.c:__libc_read (int fd, void *buf, size_t nbytes)
sysdeps/standalone/read.c:__libc_read (int fd, void *buf, size_t nbytes)
sysdeps/unix/sysv/aix/read.c:__libc_read (int fd, void *buf, size_t len)

Finding GNU/Linux's implementation this way is impossible.  TAGS won't
help you either.