Greg Wolodkin wrote:
>
> Hi Wolfgang -
> First let me say I'm sorry to see the long and winding road it looks
> like you've traveled in order to solve our problem. For that I
> apologize.
Hi Greg:
First let me thank you for your response - the first positive in this
matter. At least the solution is visible at the horizon now.
>
> It should be obvious, however, that one cannot mix glibc 2.x and libc5
> libraries within a single application. Your example using fclose() is
> one of many that could be cooked up, but the basic fact is that you
> simply cannot mix them.
This is exactly my point (the example was intended to demo it; a fellow
of mine sent a message to MathWorks before and somehow he could not make
himself clear). I told that the interface library is completely useless
for people using glibc 2.x based software (the majority of Linux users
at this time used already glibc 2.x based distributions) and that is why
I asked MathWorks ten month ago for the only clean solution (IMHO):
Interface libraries for glibc 2.x. As you know, I even offered
MathWorks to do it for them if they can't do it themselves for some
reason.
> This is well documented on the web, and has
> little to do with MATLAB except for the fact that we aren't yet
> shipping a glibc 2.x build.
What you call an exception was and is our main point: For about 3 years
and 3 months (this is when glibc 2.0 was announced) MathWorks did not
release at least glibc 2.x based interface libraries for the external
side (this would have already solved the interface problem; it does not
require the whole MATLAB project to be built against glibc 2.x)
> Unfortunately I don't think that Redhat
> makes this obvious to its users.
Beside MathWorks, we had no problems (which could not be solved) with
RedHat and glibc-2.x in conjunction with other commercial products (e.g.
lmgrd). They soon released glibc-2.x based binaries. So I do not see
what RedHat should make obvious to its users.
> For example, Redhat 5.0, 5.1, and
> 5.2 were all built upon glibc 2.0 (I believe). Here's the GNU
> announcement for glibc 2.0, which doesn't read like something I'd
> want to base my software upon:
>
> http://www.gnu.org/software/libc/ANNOUNCE-2.0-linux.html
1) This is the very first announcement with regard to glibc-2.0 and it
was posted in news:comp.os.linux.announce in January of 1997
(http://www.deja.com/%5BST_rn=ps%5D/getdoc.xp?AN=212994973). It is
unfair to cite this announcement with regard to my posting appearing 2
years and 5 month later (which are ages in the fast-pacing software
sector). MathWorks had released several new versions of Matlab in the
meantime and so had the FSF with glibc (glibc-2.1.1). Wouldn't it be
unfair, too, if one would refer to an imperfection of an experimental
MATLAB version when argueing why he/she did not use MATLAB years later?
2) Even if taking into account the facts in this first announcement of
glibc-2.0 with its first-release imperfections, I don't see why I would
not want to base my software on it. It brought a lot of enhancements to
users, distribution builders, libc maintainers as well as developers:
a) abstracted interface to the kernel (packages do not any longer
depend on a special kernel version and may become obsolete when
something changed in the kernel, libc library and headers have not to be
changed to follow a moving target)
b) most noticeable change: multi-threading (whole libc is thread
safe, functions with non-reentrant interface have a reentrant
counterpart. The stdio implementation is really thread safe and not
partly as done in libc-5 with all the hacks)
c) NSS: provides a clean and extendable way to handle the different
lookup schemes (plain file, data base file, DNS, NIS, ...)
d) The math library should be much more correct and often also faster
(important for math intensive application like MATLAB)
e) Glibc also has several new functions from POSIX and XPG4.2 and is
overall very much closer to comply with all the standards out there.
f) Improved support for internationalization.
g) Many (especially commercial) users of Linux in fact *do* want to
see a slower change of the code. FSF tries to fit there needs with
their new glibc release scheme.
3) None of the RedHat distributions (5.0 to 6.2) were based on the first
release of glibc-2.0 which you are referring to. Even for the first
glibc-2.x based distribution (RedHat 5.0) the RedHat folks tested and
waited 10 more month to get a more stable and mature version of glibc:
glibc-2.0.5.
>
> Slackware only recently (October 1999) moved to glibc 2.1.2, and for
> that I give them a lot of credit.
>
BTW, I used to develop under Slackware distributions about 5 years ago
when I started to do Linux ports. Without any doubts, Slackware
contributions to the Linux community were really great in this time.
But about 3 and a half year ago, as Slackware distributions became
larger and larger, they became also more sloppy, unfortunately. Then it
happened that important system libraries became inconsistent (e.g.
Slackware's libg++-2.7.0a caused crashes under Slackware 3.0 whenever
the gethostbyname() function was used). Because of these type of issues
I changed to RedHat 3.3. There were several other reasons to switch to
RedHat:
1) the most mature distribution
2) fast availability of bug fixes and upgrades
3) they had developed RPM
4) availability of commercial support
where all of these items are big contributions especially when it comes
to commerce.
> All that said, I've been running a glibc build for quite some time.
> It will ship with R12, our next official release. I'm hoping that
> glibc 2.1.3 is out by then, along with another minor release of gcc
> and g++ in order to fix the last remaining issues that I know of.
> (With glibc 2.1.2, for example, you cannot dlclose() a C++ shared
> library which has static initializers without later seg-faulting
> during atexit().. this is painful for someone developing C++ mex files).
Good news: Glibc 2.1.3 is out already and RedHat 6.2 (which was released
to the public on March 31th, AFAIK) is shipped with glibc 2.1.3! I have
installed RedHat 6.2 (Zoot) on one of my development boxes already.
>
> The glibc build is currently in beta testing, and if you're interested
> in participating, I will gladly sign you up. In exchange, I'd like to
> chat with you about any problems you have, and there are some NDA
> details but they aren't too hairy I think. You won't be able to link
> your executables against the beta libraries and then distribute them..
> I would not recommend that anyway. But it will give you a heads-up so
> that when R12 ships (not that far away) you'll be ready.
>
> Let me know if you're interested -
> Greg
I am definitively interested in participating and I will do my best to
let you know about any problems. As I offered myself in earlier Emails,
signing a NDA is not a problem for me.
Regards,
Wolfgang.
--
Wolfgang Reimer (Dr.-Ing.)
Technische Universität Ilmenau - Ilmenau University of Technology
Address: TU Ilmenau, FEI/IKM, PF 100565, 98684 Ilmenau, GERMANY
http://ikmcip1.e-technik.tu-ilmenau.de Phone: +49-3677-69-2619
mailto:[EMAIL PROTECTED] Fax : +49-3677-69-1195
V I R T U A L P H O T O N I C S I N C O R P O R A T E D
mailto:[EMAIL PROTECTED] http://www.virtualphotonics.com
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
