* Patch: f2c.h Question: objc backend @ 1998-01-12 10:28 Christopher Seawood 1998-01-14 2:02 ` Dave Love 0 siblings, 1 reply; 9+ messages in thread From: Christopher Seawood @ 1998-01-12 10:28 UTC (permalink / raw) To: egcs In the stock 1.0.1 release, f2c.h gets installed in /usr/local/include regardless of which prefix you specify. This patch should fix the problem. Also, I was sent a patch a while back that fixed the objc backend to properly handle thread support under glibc. I was under the impression that it was in the current snapshot at the time (971215, I think). Was there any reason this patch was not included in the 1.0.1 release? Regards Christopher --- Christopher Seawood * Software Engineer/System Admin cls@seawood.org * http://www.seawood.org ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patch: f2c.h Question: objc backend 1998-01-12 10:28 Patch: f2c.h Question: objc backend Christopher Seawood @ 1998-01-14 2:02 ` Dave Love 0 siblings, 0 replies; 9+ messages in thread From: Dave Love @ 1998-01-14 2:02 UTC (permalink / raw) To: egcs >>>>> "Christopher" == Christopher Seawood <cls@seawood.org> writes: Christopher> In the stock 1.0.1 release, f2c.h gets installed in Christopher> /usr/local/include regardless of which prefix you Christopher> specify. This patch should fix the problem. Exactly why is it a problem? What does your include search order come out as? I'm not sure the current install rule is correct for a cross-compiler, but the whole g77 build process seems to be in question in that case. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patch: f2c.h Question: objc backend
@ 1998-01-15 16:06 Trent Jarvi
1998-01-16 1:51 ` Dave Love
1998-01-17 1:40 ` Craig Burley
0 siblings, 2 replies; 9+ messages in thread
From: Trent Jarvi @ 1998-01-15 16:06 UTC (permalink / raw)
To: d.love, egcs
I noticed when porting the egcs rpm package to the alpha machine that f2c.h was
left out. When I mentioned to people that /usr/local/include/f2c.h was left
out I was informed that egcs was wrong. nothing should go into /usr/local with
prefix=/usr.
Christopher took the initiative to fix it. If its the wrong fix we are interested
in hearing so. I can imagine NFS setups that the original would not be well suited
for. The reason f2c.h is being picked on is it is the only file in the egcs
package to go into /usr/local with prefix=/usr
Trent Jarvi
----------------------- Mr Love's Message ---------------------
>>>>> "Christopher" == Christopher Seawood <cls@seawood.org> writes:
Christopher> In the stock 1.0.1 release, f2c.h gets installed in
Christopher> /usr/local/include regardless of which prefix you
Christopher> specify. This patch should fix the problem.
Exactly why is it a problem? What does your include search order come
out as? I'm not sure the current install rule is correct for a
cross-compiler, but the whole g77 build process seems to be in
question in that case.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patch: f2c.h Question: objc backend 1998-01-15 16:06 Trent Jarvi @ 1998-01-16 1:51 ` Dave Love 1998-01-17 1:40 ` Craig Burley 1 sibling, 0 replies; 9+ messages in thread From: Dave Love @ 1998-01-16 1:51 UTC (permalink / raw) To: egcs >>>>> "Trent" == Trent Jarvi <chaos@jarvi.ezlink.com> writes: Trent> I noticed when porting the egcs rpm package to the alpha Trent> machine that f2c.h was left out. It should not be left out of gcc-lib/mumble/mumble/include. Trent> When I mentioned to people that /usr/local/include/f2c.h was Trent> left out I was informed that egcs was wrong. nothing should Trent> go into /usr/local with prefix=/usr. It's conditionally installed in $(includedir) IIRC, or at least it's supposed to be. This is surely discussed in the g77 doc. Trent> Christopher took the initiative to fix it. If its the wrong Trent> fix we are interested in hearing so. I can imagine NFS setups Trent> that the original would not be well suited for. The reason Trent> f2c.h is being picked on is it is the only file in the egcs Trent> package to go into /usr/local with prefix=/usr The point is that we want to avoid losing on an incompatible f2c.h that's already installed and picked up from $(includedir), which is searched early. I think at one time the configure/instal procedure tried to be clever and DTRT according to what was already installed. This is only relevant if one compiles f2c-generated or f2c-compatible C code subsequently for linking with g77 output. I reckon an rpm should not install /usr/local/include/f2c.h but should generate a conflict with one that's already there. Or something. (I'm not an rpm expert.) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patch: f2c.h Question: objc backend 1998-01-15 16:06 Trent Jarvi 1998-01-16 1:51 ` Dave Love @ 1998-01-17 1:40 ` Craig Burley 1998-01-19 2:45 ` Alexandre Oliva 1998-01-19 2:45 ` Dave Love 1 sibling, 2 replies; 9+ messages in thread From: Craig Burley @ 1998-01-17 1:40 UTC (permalink / raw) To: egcs; +Cc: chaos Here's what I think is the "complete story" on g77's treatment of `f2c.h'. g77 relies on the f2c run-time library, named libf2c. That means it generates object-compatible calls to that library. So, with little additional pain, g77 is able to offer object compatibility with f2c. [FYI: f2c converts Fortran code to C code, which the user in turn compiles with a C compiler such as gcc.] That is, users can mix g77-compiled and f2c-compiled code in a single program. Not only can each kind of object call on the same library in a "mixy" way -- e.g. g77 code can OPEN a file on unit 10, then f2c code can WRITE to unit 10, and it all works -- but each kind of object can call on the other (which makes the former practical). For reasons involving portability and simplicity, plus being still fairly primitive, `libf2c.a' is built using some fairly "brittle" assumptions about data types that affect how callers pass arguments to `libf2c.a' routines. These assumptions are encoded in a file named `f2c.h'. This file is #include'd by `libf2c.a' code, and also is #include'd by f2c-produced code when it is compiled by the user's C compiler (which should be the same, or object-compatible with, the one he used to build `libf2c.a' itself). Absent g77, f2c installers are encouraged to tailor `f2c.h' to their system by editing it prior to building `libf2c.a', then making that edited copy available as the version for all f2c users who will link to that particular library. So, a typical f2c installation has a version of `f2c.h' installed wherever local `.h' files live such that they'll be (automatically?) picked up when compiling C code produced by f2c. This version might or might not have been hand-edited by the f2c installer (probably not if the system is SunOS, IIRC). This means that, for most systems, /usr/local/include/ is the place where `f2c.h' is installed. Now, g77 enters the picture, and certain things happen. g77 generates its own version of `f2c.h' during its configuration (and build?) procedure from a file named `f2c.h.in'. This allows g77 to configure and build more automatically than the f2c version of libf2c would by itself (though, perhaps official f2c+libf2c has improved since this was last known to be a problem a couple of years ago). The g77-generated version of `f2c.h' is, in effect, *already* a "hand-edited" version in the narrow libf2c sense. So, to make this version of `f2c.h' available to users of f2c on the system, g77 installs it, along with the version of `libf2c.a' it built, in the canonical include and lib directories if `libf2c.a' isn't already there or explicit overriding macros and/or files exist in the build or source directories. Little of the above *isn't* some kind of kludge, so there's little of it that can't be reworked, as long as the rework is done with some overall understanding of the situation, what is being achieved, and so on. For example, installing `f2c.h' in some other directory instead might or might not be a good idea. It depends on whether f2c users are likely to pick up that version when linking to the corresponding `libf2c.a'. The problem is essentially that g77 is trying, bless its heart, to get along with the gcc configuration and build environment, and for most users it succeeds very well. But it also tries to "eject matter" that will coexist with an independently provided and separately built and installed product, f2c, which has pretty much no similarity to gcc's build environment. There's a variety of "futures" issues that perhaps suggest various ways to resolve this situation: 1. We could bring all of f2c into the gcc/g77 product packaging. It wouldn't take much additional space, but could take a fair amount of work to get all the configuration, build, and porting issues resolved enough to make it worthwhile. 2. We could start to drop any semblance of f2c compatibility from g77, leaving it to "knowledgable" users to do the f2c-related installation by hand. The continued use of `libf2c.a' would thus be essentially "hidden" from the user base by not installing `libf2c.a' anywhere other than in the version-specific library directory. 3. We could start writing libg77.a, the name we've unofficially given the long-term replacement for `libf2c.a' we've been wanting to do for years. libg77.a would *not* offer any compatibility with `libf2c.a'. Whether g77 offered a "compatibility flag" to produce code compatible with `libf2c.a' is undecided, but the "hook" is there for users who want such compatibility. (I.e. they already have a compiler option they can use, which we can start handling by producing a diagnostic when and if necessary.) Items 2 and 3 are fairly compatible, i.e. we could do 2 now and 3 later. Doing item 1 might be more helpful to current g77 users, but I'm not sure how much harder it might make a transition over to 3 (perhaps via 2) in the future. In any case, we *know* we want to do 3, it's just a matter of timing, and, probably, funding. We need a multi-libbed g77 library, one that handles exceptions, threads, more features, higher performance, the whole kit and kaboodle. tq vm, (burley) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patch: f2c.h Question: objc backend 1998-01-17 1:40 ` Craig Burley @ 1998-01-19 2:45 ` Alexandre Oliva 1998-01-19 2:25 ` Craig Burley 1998-01-20 14:54 ` Dave Love 1998-01-19 2:45 ` Dave Love 1 sibling, 2 replies; 9+ messages in thread From: Alexandre Oliva @ 1998-01-19 2:45 UTC (permalink / raw) To: Craig Burley; +Cc: egcs, chaos Craig Burley writes: > So, to make this version of `f2c.h' available to users of f2c > on the system, g77 installs it, along with the version of `libf2c.a' > it built, in the canonical include and lib directories if `libf2c.a' > isn't already there or explicit overriding macros and/or files > exist in the build or source directories. I believe this is unnecessary, since, if people compile C files (translated from Fortran by f2c) with gcc, it will find f2c.h anyway, and it will link against g77's libf2c.a. Is my reasoning wrong? > 1. We could bring all of f2c into the gcc/g77 product packaging. Is there any reason to make f2c available? I can't think of any reason to use it, since there is g77, which makes such a better job about optimizing loops and such, AFAIK. > 2. We could start to drop any semblance of f2c compatibility from > g77 Could there be any performance gain with that? -- Alexandre Oliva mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org http://www.dcc.unicamp.br/~oliva Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patch: f2c.h Question: objc backend 1998-01-19 2:45 ` Alexandre Oliva @ 1998-01-19 2:25 ` Craig Burley 1998-01-20 14:54 ` Dave Love 1 sibling, 0 replies; 9+ messages in thread From: Craig Burley @ 1998-01-19 2:25 UTC (permalink / raw) To: oliva; +Cc: egcs, chaos >Craig Burley writes: > >> So, to make this version of `f2c.h' available to users of f2c >> on the system, g77 installs it, along with the version of `libf2c.a' >> it built, in the canonical include and lib directories if `libf2c.a' >> isn't already there or explicit overriding macros and/or files >> exist in the build or source directories. > >I believe this is unnecessary, since, if people compile C files >(translated from Fortran by f2c) with gcc, it will find f2c.h anyway, >and it will link against g77's libf2c.a. Is my reasoning wrong? I don't know, but would like it to not be! Any excuse to get rid of these kludges. What would be best is to ensure that someone can still use some canned "fort77" script that invokes a canonical, installed gcc and still pick up the "right" `f2c.h' for use with the `libf2c.a' they're going to link with. But if the latter is part of, say, an egcs gcc that isn't the "installed gcc", then what means "right" anyway? So maybe we should just drop this whole business of installing `f2c.h' and `libf2c.a' anyplace other than the ordinary "stuff for this version of gcc" places. >> 1. We could bring all of f2c into the gcc/g77 product packaging. > >Is there any reason to make f2c available? I can't think of any >reason to use it, since there is g77, which makes such a better job >about optimizing loops and such, AFAIK. f2c has a few advantages over g77 still. Few enough that I think few people would mind if g77 dropped its remaining kludges trying to install elegantly vis-a-vis f2c. And few enough that we could probably start knocking off the ones that do remain, one by one, without a lot of effort. Besides the arry-bounds-checking feature, I can't think of an f2c advantage offhand, but know there must be more, and users would tell us if we need that info, especially once we drop support. >> 2. We could start to drop any semblance of f2c compatibility from >> g77 > >Could there be any performance gain with that? Not with #2 per se, because I really mean, for "semblance", "appearance". That is, #2 is kind of like pretending as if f2c never existed, leaving it to experienced users or small blurbs in the docs to understand that g77 still is basically compatible with f2c. It's #3 where we start taking advantage of that separation, which probably should be done before #3 (though maybe not -- maybe users will want to see immediate performance gains to justify moving to a new g77 that even *appears* to no longer offer compatibility). And, yes, there should be some substantial performance benefits available once we undertake #3, primarily in the I/O arena (formatted, unformatted, even internal I/O), but with plenty of opportunity to improve raw math speed as well. tq vm, (burley) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patch: f2c.h Question: objc backend 1998-01-19 2:45 ` Alexandre Oliva 1998-01-19 2:25 ` Craig Burley @ 1998-01-20 14:54 ` Dave Love 1 sibling, 0 replies; 9+ messages in thread From: Dave Love @ 1998-01-20 14:54 UTC (permalink / raw) To: egcs >>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes: Alexandre> I believe this is unnecessary, since, if people compile C Alexandre> files (translated from Fortran by f2c) with gcc, it will Alexandre> find f2c.h anyway, and it will link against g77's Alexandre> libf2c.a. Is my reasoning wrong? No, you're right, there will always be _an_ f2c.h found; the question is whether it's consistent with (a) the libf2c.a that gets linked (b) been compiled into g77 regarding type sizes. Alexandre> Is there any reason to make f2c available? It's particularly useful as an interface generator if you're mixing Fortran and C or something else via a SWIG-like scheme. [`f2c -P' gives you C prototypes for the fortran routines corresponding to the g77 default code generation.] Presumably G77 could do this, but it doesn't currently. It may end up translating more for the g77 runtime at some stage, but that's not necessarily a reason for distributing it with g77, and I suspect the things it does that g77 doesn't aren't now compelling. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Patch: f2c.h Question: objc backend 1998-01-17 1:40 ` Craig Burley 1998-01-19 2:45 ` Alexandre Oliva @ 1998-01-19 2:45 ` Dave Love 1 sibling, 0 replies; 9+ messages in thread From: Dave Love @ 1998-01-19 2:45 UTC (permalink / raw) To: egcs >>>>> "Craig" == Craig Burley <burley@gnu.org> writes: Craig> This allows g77 to configure and build more automatically than Craig> the f2c version of libf2c would by itself (though, perhaps Craig> official f2c+libf2c has improved since this was last known to Craig> be a problem a couple of years ago). It's unchanged in that respect and the maintainer was unenthusiastic about autoconfism. Craig> 1. We could bring all of f2c into the gcc/g77 product Craig> packaging. It wouldn't take much additional space, but Craig> could take a fair amount of work to get all the Craig> configuration, build, and porting issues resolved enough Craig> to make it worthwhile. FWIW that's all been done but long enough ago that bitrot will have set in. Also it uses automake, which ISTR is verboten in gcc. (It was requested for a GNU distribution of f2c but I never wrote the required Texinfo doc.) [BTW, f2c is particularly useful for generating (currently, and with the default options) g77-compatible C prototypes for Fortran routines.] Sorry to confuse matters with a misapprehension about why the messing about is being done as it is. There definitely are problems with people mixing G77 code and C being screwed by f2c stuff, though. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1998-01-20 14:54 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-01-12 10:28 Patch: f2c.h Question: objc backend Christopher Seawood 1998-01-14 2:02 ` Dave Love 1998-01-15 16:06 Trent Jarvi 1998-01-16 1:51 ` Dave Love 1998-01-17 1:40 ` Craig Burley 1998-01-19 2:45 ` Alexandre Oliva 1998-01-19 2:25 ` Craig Burley 1998-01-20 14:54 ` Dave Love 1998-01-19 2:45 ` Dave Love
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).