X-Mailer: exmh version 2.0.2 2/24/98 (debian)
To: "Mattthew D. Pitts" <mpitts@suite224.net>
cc: linux-gcc@vger.rutgers.edu
Subject: Re: [OFFTOPIC]: MS Porting Office to Linux?
In-reply-to: Your message of "Tue, 16 Mar 1999 19:45:20 EST."
<19990317004247.AAA15937@pcs486>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Mar 1999 09:47:34 +0000
From: Philip Blundell <pb@fountain.nexus.co.uk>
>> Did you actually read what I wrote above? It works with the particular
>> version of glibc that you happen to have installed, yes. It doesn't work
>> with the version that those people having problems are using, and if you
>> install that version it will stop working for you as well.
>>
>In other words, glibc 2.1 is broken.
StarOffice only works with the old glibc by chance. There is simply no way
you can upgrade a library and maintain 100% compatibility in the face of
all the possible stupid things that a user binary can do - the only way you
can be sure that two libraries will behave precisely the same is if they
*are* precisely the same.
However, we are prepared to sacrifice that 100% compatibility and draw a line
somewhere. For example, we assume that if a user program has hardwired
knowledge of the memory address in glibc where a particular variable lives in
some version, it is making unacceptable demands on the library and we won't
feel obliged to try to guarantee that it continues working. Similarly if it
"knows" what the layout of a FILE structure is and starts directly modifying
its fields. The only promises that are made about the interface to newer C
libraries are the interface definitions set out in the documentation.
Using internal C library symbols (anything beginning with an underscore for
example) is another way in which a user program can poke at the unpublished
details of the libc. This is also unacceptable. To discourage this, as of
glibc 2.1 these internal symbols are simply not visible to such programs.
StarOffice tries to refer to __libc_init and __setfpucw at least; maybe
others. Its installer also looks explicitly for "libpthread-0.7.so". None of
these are details that a well behaved program should concern itself with.
A glib answer like "glibc 2.1 is broken" helps nobody. If you really believe
that the library is at fault, take the time to investigate the problem and
suggest a way to fix it.
(This discussion has nothing to do with the kernel. Please don't cc the
linux-kernel list if you reply.)
p.
------- End of Blind-Carbon-Copy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/