This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
>That is a g77 Makefile bug. I meant to fix it. But I don't want
>to waste my time on it. I am still waiting for other g77/libf2c
>related Makefile patches of mine to be installed. It seems to me
>that people working on g77/libf2c either don't care or have few
>clues on Makefile. It is not news to me.
>
>If people who maintains g77 Makefile really wants to fix it,
>please drop me a line.
HJ, perhaps you've forgotten, or somehow missed, my email of
the first of the month on this topic. It is enclosed below.
In any case, I'll make it *very clear* so you can understand it:
NEVER, NEVER, NEVER AGAIN post messages claiming that g77 people
either don't care or don't know about Makefile stuff. It is a lie,
and repeating it doesn't make it any more true.
I also asked you, back awhile, to remind me about patches you'd
sent that were pending, at you sent me some pointers to them.
I consider those to still be in my large, but slowly shrinking,
in-box. (Have you not noticed the sudden, substantial increase
of recent CVS changes to the g77 areas of the repository by myself?
Has it occurred to you how much of a strain my being generally
unavailable for real g77 work during the preceding months has
been on other g77 people, like Dave Love -- the closest thing we
have to a libf2c guru on the egcs list -- and Toon Moene?)
Your patches will not get addressed any faster by continuing to
insult the integrity and the expertise of g77 developers.
Now, I want you to take a moment out of your busy schedule, find a
post-it note, write "STOP INSULTING G77 DEVELOPERS", and stick it
on your video display. Come to think of it, change "G77" to "GCC",
and make *all* of us happier.
tq vm, (burley)
>>Date: 1 Feb 1999 12:48:00 -0000
>>From: craig@jcb-sc.com
>>To: hjl@lucon.org
>>CC: egcs@egcs.cygnus.com
>>Cc: craig@jcb-sc.com
>>In-reply-to: <m1073ND-0000V1C@sea.lucon.org> (hjl@lucon.org)
>>Subject: Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1
>>
>>Thanks for the patch-pointers, they're in my email in-box for me to
>>get to someday.
>>
>>>The discussion and inaction around those threads leave me an impression
>>>that noone from libf2c really cares or understands what is going. I am
>>>more than happy to be proved wrong on that.
>>
>>Don't hold yer breath. :) I'm sure there's a good amount of *caring*,
>>but time and understanding are in short supply.
>>
>>Remember that libf2c isn't "grown" in these parts -- it's from netlib --
>>so egcs/libf2c is really libg2c, a version of libf2c modified to be
>>generally compatible with libf2c but more appropriate for use with g77
>>than vanilla libf2c.
>>
>>So there's not really any individual developer who works on libf2c as
>>the run-time library for g77, in the same sense that there probably is
>>at least one for glibc, libc5, etc. That is, the person who best
>>understands libf2c does not work on g77, egcs, gcc2, or anything like
>>that (though he's been generally quite willing to change libf2c to
>>accommodate g77 needs to seem general-purpose enough).
>>
>>Normally, Dave Love takes care of the libU77 part of libg2c (there's
>>no libU77 in libf2c) and all the configury stuff. I've made changes
>>to the libF77 and, especially, libI77 areas, but I've been out-to-lunch
>>for a couple of months now (at least), which should change soon.
>>
>>Another wrinkle is that we (the g77 people) have been still trying to
>>support FSF-g77 in some fashion, so we avoid making too many changes
>>to egcs-libg2c that can't be directly put in FSF-g77-libg2c.
>>
>>So, things should improve, but I can't promise when or by how much.
>>
>>Someday maybe libg77 -- a run-time library designed to work solely with
>>and for g77 -- will happen. In one sense, that'll make for more
>>development and maintenance effort overall, but it'll be more monolithic:
>>the problems of coping with different versions of something not really
>>designed for g77 won't be there, so what'll be left will, while larger,
>>will be more straightforward to deal with.
>>
>> tq vm, (burley)