collect2 compiles C with g77 !

collect2 compiles C with g77 !

[Philippe De Muyter]

On m68k-motorola-sysv all g77/execute tests fail because collect2 tries
to compile a c-program with a fortran compiler :).  Details using -v and
-Wl,-debug options follow.

Does someone know the best way to fix that ?  I can think of at least three :
	1. Make collect2 always invoke gcc
	2. Make g77 recognize .c suffix and invoke cc1
	3. Make collect2 directly generate assembler, not C.

Philippe

Reading specs from /usr/gnu/tmp/egcs/gcc/specs
gcc version egcs-2.90.16 971105 (gcc2-970802 experimental)
 /usr/gnu/tmp/egcs/gcc/f771 /usr/gnu/tmp/egcs-971105/gcc/testsuite/g77.f-torture/execute/971102-1.f -fset-g77-defaults -quiet -dumpbase 971102-1.f -O0 -w -version -fversion -o /usr/tmp/cca17627.s
GNU F77 version egcs-2.90.16 971105 (gcc2-970802 experimental) (m68k-motorola-sysv) compiled by GNU C version egcs-2.90.16 971105 (gcc2-970802 experimental).
GNU Fortran Front End version 0.5.22-19970929
 as -o /usr/tmp/cca176271.o /usr/tmp/cca17627.s
 /usr/gnu/tmp/egcs/gcc/ld -o /tmp/971102-1.x /usr/gnu/tmp/egcs/gcc/crt0.o -L/usr/gnu/tmp/egcs/gcc -L/usr/local/m68k-motorola-sysv/lib -L/usr/local/lib /usr/tmp/cca176271.o -debug -lf2c -lm -lgcc -lc881 -lgcc
collect2 version egcs-2.90.16 971105 (gcc2-970802 experimental) (68k, SGS/AT&T sysV68 syntax)
ld_file_name        = /usr/local/bin/ld
c_file_name         = /usr/gnu/tmp/egcs/gcc/g77
nm_file_name        = /bin/nm
strip_file_name     = /usr/local/m68k-motorola-sysv/bin/strip
c_file              = /usr/tmp/cca17630.c
o_file              = /usr/tmp/cca17630.o
COLLECT_NAMES       = /usr/gnu/tmp/egcs/gcc/ld
COLLECT_GCC_OPTIONS = '-B/usr/gnu/tmp/egcs/gcc/' '-v' '-w' '-O0' '-o' '/tmp/971102-1.x'
COLLECT_GCC         = /usr/gnu/tmp/egcs/gcc/g77
COMPILER_PATH       = /usr/gnu/tmp/egcs/gcc/m68k-motorola-sysv/egcs-2.90.16/:/usr/gnu/tmp/egcs/gcc/:/usr/local/lib/gcc-lib/m68k-motorola-sysv/egcs-2.90.16/:/usr/local/lib/gcc-lib/m68k-motorola-sysv/:/usr/lib/gcc/m68k-motorola-sysv/egcs-2.90.16/:/usr/lib/gcc/m68k-motorola-sysv/:/usr/local/m68k-motorola-sysv/bin/m68k-motorola-sysv/egcs-2.90.16/:/usr/local/m68k-motorola-sysv/bin/
LIBRARY_PATH        = /usr/gnu/tmp/egcs/gcc/m68k-motorola-sysv/egcs-2.90.16/:/usr/gnu/tmp/egcs/gcc/:/usr/local/lib/gcc-lib/m68k-motorola-sysv/egcs-2.90.16/:/usr/lib/gcc/m68k-motorola-sysv/egcs-2.90.16/:/usr/local/m68k-motorola-sysv/lib/m68k-motorola-sysv/egcs-2.90.16/:/usr/local/m68k-motorola-sysv/lib/:/usr/local/lib/m68k-motorola-sysv/egcs-2.90.16/:/usr/local/lib/:/lib/m68k-motorola-sysv/egcs-2.90.16/:/lib/:/usr/lib/m68k-motorola-sysv/egcs-2.90.16/:/usr/lib/

/usr/local/bin/ld -o /tmp/971102-1.x /usr/gnu/tmp/egcs/gcc/crt0.o -L/usr/gnu/tmp/egcs/gcc -L/usr/local/m68k-motorola-sysv/lib -L/usr/local/lib /usr/tmp/cca176271.o -lf2c -lm -lgcc -lc881 -lgcc
 /bin/nm -p /tmp/971102-1.x

nm output with constructors/destructors.

0 constructor(s) found
0 destructor(s)  found
[Leaving /tmp/971102-1.x]

========== output_file = /tmp/971102-1.x, c_file = /usr/tmp/cca17630.c
#ifdef __cplusplus
extern "C" {
#endif
typedef void entry_pt();

extern void *x1 __asm__ ("_GLOBAL__F___bb_exit_func");
extern void *x2 __asm__ ("_GLOBAL__F___fixunsdfdi");
extern void *x3 __asm__ ("_GLOBAL__F___umoddi3");
extern void *x4 __asm__ ("_GLOBAL__F__exit_dummy_decl");
extern void *x5 __asm__ ("_GLOBAL__F___udivdi3");
extern void *x6 __asm__ ("_GLOBAL__F___do_global_dtors");
extern void *x7 __asm__ ("_GLOBAL__F___fixdfdi");
extern void *x8 __asm__ ("_GLOBAL__F___floatdidf");
	static void *frame_table[] = {
		&x1,
		&x2,
		&x3,
		&x4,
		&x5,
		&x6,
		&x7,
		&x8,
	0
};
extern void __register_frame_table (void *);
extern void __deregister_frame (void *);
static void reg_frame () {
	__register_frame_table (frame_table);
	}
static void dereg_frame () {
	__deregister_frame (frame_table);
	}

entry_pt * __CTOR_LIST__[] = {
	(entry_pt *) 1,
	reg_frame,
	0
};


entry_pt * __DTOR_LIST__[] = {
	(entry_pt *) 1,
	dereg_frame,
	0
};

extern entry_pt __main;
entry_pt *__main_reference = __main;

#ifdef __cplusplus
}
#endif
========== end of c_file

/usr/gnu/tmp/egcs/gcc/g77 -c -o /usr/tmp/cca17630.o -fno-exceptions /usr/tmp/cca17630.c
/usr/tmp/cca17630.c:1: undefined or invalid # directive
/usr/tmp/cca17630.c:2: 
   extern "C" {
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:3: undefined or invalid # directive
/usr/tmp/cca17630.c:4: 
   typedef void entry_pt();
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:6: 
   extern void *x1 __asm__ ("_GLOBAL__F___bb_exit_func");
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:7: 
   extern void *x2 __asm__ ("_GLOBAL__F___fixunsdfdi");
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:8: 
   extern void *x3 __asm__ ("_GLOBAL__F___umoddi3");
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:9: 
   extern void *x4 __asm__ ("_GLOBAL__F__exit_dummy_decl");
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:10: 
   extern void *x5 __asm__ ("_GLOBAL__F___udivdi3");
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:11: 
   extern void *x6 __asm__ ("_GLOBAL__F___do_global_dtors");
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:12: 
   extern void *x7 __asm__ ("_GLOBAL__F___fixdfdi");
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:13: 
   extern void *x8 __asm__ ("_GLOBAL__F___floatdidf");
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:14: 
           static void *frame_table[] = {
           1           2
Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2)
/usr/tmp/cca17630.c:14: 
           static void *frame_table[] = {
                                   ^
Unrecognized character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:15: 
                   &x1,
                   ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:16: 
                   &x2,
                   ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:17: 
                   &x3,
                   ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:18: 
                   &x4,
                   ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:19: 
                   &x5,
                   ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:20: 
                   &x6,
                   ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:21: 
                   &x7,
                   ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:22: 
                   &x8,
                   ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:24: 
   };
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:25: 
   extern void __register_frame_table (void *);
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:26: 
   extern void __deregister_frame (void *);
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:27: 
   static void reg_frame () {
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:28: 
           __register_frame_table (frame_table);
           ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:29: 
           }
           ^
Unrecognized character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:30: 
   static void dereg_frame () {
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:31: 
           __deregister_frame (frame_table);
           ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:32: 
           }
           ^
Unrecognized character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:34: 
   entry_pt * __CTOR_LIST__[] = {
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:35: 
           (entry_pt *) 1,
           ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:36: 
           reg_frame,
           1        2
Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2)
/usr/tmp/cca17630.c:38: 
   };
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:41: 
   entry_pt * __DTOR_LIST__[] = {
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:42: 
           (entry_pt *) 1,
           ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
/usr/tmp/cca17630.c:43: 
           dereg_frame,
           1          2
Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2)
/usr/tmp/cca17630.c:45: 
   };
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:47: 
   extern entry_pt __main;
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:48: 
   entry_pt *__main_reference = __main;
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:50: undefined or invalid # directive
/usr/tmp/cca17630.c:51: 
   }
   ^
Invalid first character at (^) [info -f g77 M LEX]
/usr/tmp/cca17630.c:52: undefined or invalid # directive
collect2: gcc returned 1 exit status
[Leaving /usr/tmp/cca17630.c]
[Leaving /usr/tmp/cca17630.o]
[Leaving /usr/tmp/cca17630.x]
[Leaving /usr/tmp/cca17630.ld]
[Leaving /tmp/971102-1.x]

Re: collect2 compiles C with g77 !

[Dave Love]

>>>>> "Philippe" == Philippe De Muyter <phdm@macqel.be> writes:

 Philippe> Does someone know the best way to fix that ?  I can think of at least three :
 Philippe> 	1. Make collect2 always invoke gcc
 Philippe> 	2. Make g77 recognize .c suffix and invoke cc1

I don't know about the problem at hand, but g77 should definitely do
2.  I hadn't realized that it now doesn't.

Re: collect2 compiles C with g77 !

[Jeffrey A Law]

  In message < rzqk9efhdea.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Philippe" == Philippe De Muyter <phdm@macqel.be> writes:
  > 
  >  Philippe> Does someone know the best way to fix that ?  I can think of at 
  > least three :
  >  Philippe> 	1. Make collect2 always invoke gcc
  >  Philippe> 	2. Make g77 recognize .c suffix and invoke cc1
  > 
  > I don't know about the problem at hand, but g77 should definitely do
  > 2.  I hadn't realized that it now doesn't.
Actually, the language specific drivers (g77, g++) aren't supposed to
call other languages unless explicitly asked for by the user (-x option).

I think the root of Philippe's problem lies elsewhere...

jeff

Re: collect2 compiles C with g77 !

[Craig Burley]

>Actually, the language specific drivers (g77, g++) aren't supposed to
>call other languages unless explicitly asked for by the user (-x option).

I don't understand this, or maybe the rationale behind it.

Why shouldn't "g77 foo.f bar.c" do what the user expects --
compile bar.c using the C compiler and foo.f using the Fortran
compiler, and link the objects into a single executable along
with the Fortran libraries?

More to the point, why are g77 and g++ considered
"language-specific drivers" but gcc is not?  (Think about
what a *user* sees when answering that question -- users
aren't interested in, and should not have to know about,
internal architectures of products they use.)

Another point -- g77 has always, since public release,
handled compiling non-Fortran languages just fine, as far
as I'm aware.  Same with g++ up through gcc 2.7, I believe,
since I originally created g77.c by simply copying g++.c
and editing it.  It might well be the case, therefore,
that existing users have scripts that use g77 or g++ to
compile multi-lingual programs, and I wouldn't recommend
we do anything to cause those scripts to stop working.

So if there is now a policy that only the gcc command itself
knows how to compile source code written in multiple
languages, I'd sure be interested to know when, why, and how
that policy was created and went into effect.  It certainly
isn't the policy I've been aware of, and I can't see how it
benefits the end user offhand.

        tq vm, (burley)

Re: collect2 compiles C with g77 !

[Paul Koning]

>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:

 >> Actually, the language specific drivers (g77, g++) aren't supposed
 >> to call other languages unless explicitly asked for by the user
 >> (-x option).

 Craig> I don't understand this, or maybe the rationale behind it.
>...
 Craig> Another point -- g77 has always, since public release, handled
 Craig> compiling non-Fortran languages just fine, as far as I'm
 Craig> aware.  Same with g++ up through gcc 2.7, I believe, since I
 Craig> originally created g77.c by simply copying g++.c and editing
 Craig> it.  It might well be the case, therefore, that existing users
 Craig> have scripts that use g77 or g++ to compile multi-lingual
 Craig> programs, and I wouldn't recommend we do anything to cause
 Craig> those scripts to stop working.

I know for a fact that there are scripts (makefiles) out there that
assume g++ is capable of taking the same switches that gcc understands
(i.e., g++ is essentially a synonym for gcc).  I had to do repairs to
those makefiles to get some packages to build recently.

	paul

g77 changes

[Dave Love]

In addition to Craig's comments I realize `g77 -v' no longer does what
we expect (see the manual).

Talking of which, the g77 manual needs an overhaul before release.  I
haven't reviewed it carefully, but at least these things need
attention:
 * Version info
 * Bug reporting procedure and addresses (and other occurrences of
   gnu.ai.mit.edu)
 * Installation instructions
 * Bug fix and operational changes since 0.5.21 that aren't in
   burley's patches (like the changes under discussion, if they must
   persist)

[I'm particularly concerned about the first two, as a fortran@gnu
muggins and responder to random posts.]

Re: g77 changes

[Jeffrey A Law]

  In message < rzqd8k47bu0.fsf@djlvig.dl.ac.uk >you write:
  > In addition to Craig's comments I realize `g77 -v' no longer does what
  > we expect (see the manual).
Good points.

  > Talking of which, the g77 manual needs an overhaul before release.  I
  > haven't reviewed it carefully, but at least these things need
  > attention:
  >  * Version info
This is a question with broader implications.  ie, we're still trying to
answer the version # question about the release as a whole :-)

  >  * Bug reporting procedure and addresses (and other occurrences of
  >    gnu.ai.mit.edu)
Yes.  So, where do y'all want but reports to go to?  fortan@gnu.org or
egcs-bugs@cygnus.com

  >  * Installation instructions
Yes.  This is a general problem -- however I think we want to shy away from
language specific install stuff.

  >  * Bug fix and operational changes since 0.5.21 that aren't in
  >    burley's patches (like the changes under discussion, if they must
  >    persist)
We should note major bugfixes and user interface changes; I don't think we
want to detail every change since 0.5.21.  But that's just my opinion.

jeff

Re: collect2 compiles C with g77 !

[Jeffrey A Law]

  In message < 199711112146.QAA18548@melange.gnu.org >you write:
  > >Actually, the language specific drivers (g77, g++) aren't supposed to
  > >call other languages unless explicitly asked for by the user (-x option).
  > 
  > I don't understand this, or maybe the rationale behind it.
  > 
  > Why shouldn't "g77 foo.f bar.c" do what the user expects --
  > compile bar.c using the C compiler and foo.f using the Fortran
  > compiler, and link the objects into a single executable along
  > with the Fortran libraries?
Actually, I probably should have said something like

"the language specific drivers don't call other languages unless explicitly
asked to".

Instead of implying that it policy of some sort.  It's just how they work,
not a statement about what is right or wrong.

Certainly "g77 foo.f bar.c" is a pretty good argument that g77 should call
out to the C driver appropriately for bar.c

Anyone want to look at the lang_specific_driver stuff and see how hard this
is to make work correctly within that framework?  We don't want to go back
to having a completely separate g77 driver -- it causes too many headaches.

jeff

Re: g77 changes

[Craig Burley]

>Yes.  So, where do y'all want but reports to go to?  fortan@gnu.org or
>egcs-bugs@cygnus.com

My take is that egcs-bugs@cygnus.com would be a better address.
First, "politically", because it would tend to reinforce the
idea that "g77 is part of gcc".  Second, practically, because
fortran@gnu.org is populated by people who are likely to be
on egcs-bugs as well (though I think I'll send a polite suggestion
to be sure ;-), whereas egcs people who aren't on the various
g77 mailing lists have already, IMO, demonstrated both a willingness
and an ability to cope with g77's special needs.

(Come to think of it, am *I* on egcs-bugs?  Since the email
address change from gnu.ai.mit.edu to gnu.org, I've had
trouble coping with mailing lists, and probably lost track
of such things.)

>  >  * Installation instructions
>Yes.  This is a general problem -- however I think we want to shy away from
>language specific install stuff.

g77 still being "beta" is partly the reason there are still
likely to be some things that are language-specific regarding
installation, such as build-time-configurable parameters (see
"Maximum Stackable Size", IIRC, in the g77 docs).

But it will be nice to have most/all of g77's special installation
instructions go away, and I'm not even thinking about the effort
I have to put in to maintain it, but rather the efforts users
have to make to cope with g77's mysterious past.  :)

        tq vm, (burley)

Re: g77 changes

[Dave Love]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 >> * Version info
 Jeffrey> This is a question with broader implications.  ie, we're
 Jeffrey> still trying to answer the version # question about the
 Jeffrey> release as a whole :-)

OK, as long as it's not misleading in the end result.  (I was raising
this under apparent threat of a release.)

 >> * Installation instructions
 Jeffrey> Yes.  This is a general problem -- however I think we want
 Jeffrey> to shy away from language specific install stuff.

Yes, one would hope most would be unnecessary, but at present it
contains instructions involving patching gcc 2.7, etc., etc.

 >> * Bug fix and operational changes since 0.5.21 that aren't in
 >> burley's patches (like the changes under discussion, if they must
 >> persist)
 Jeffrey> We should note major bugfixes and user interface changes; I
 Jeffrey> don't think we want to detail every change since 0.5.21.

There are already changes listed (typically not too many per release)
but there's probably more which needs adding and also, likely things
to be removed from the `actual bugs' list (such as Alpha fixing,
perhaps).

[I'd try to write doc if I knew enough (and had time) but...]

Re: g77 changes

[Dave Love]

>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:

 >> Yes.  So, where do y'all want but reports to go to?  fortan@gnu.org or
 >> egcs-bugs@cygnus.com

 Craig> My take is that egcs-bugs@cygnus.com would be a better
 Craig> address.

That's what I was told was policy.  Can't remember who said so, though.

Re: g77 changes

[Jeffrey A Law]

  In message < 199711172359.SAA22676@melange.gnu.org >you write:
  > >Yes.  So, where do y'all want but reports to go to?  fortan@gnu.org or
  > >egcs-bugs@cygnus.com
  > 
  > My take is that egcs-bugs@cygnus.com would be a better address.
OK.  Next question is do we want to fix the oodles and gobs of other
fortran@gnu.ai.mit.edu references?  There's a dozen or so.  Some would
probably be better with egcs, others egcs-bugs.  Maybe others still
fortran@gnu.org.

  > (Come to think of it, am *I* on egcs-bugs?  Since the email
  > address change from gnu.ai.mit.edu to gnu.org, I've had
  > trouble coping with mailing lists, and probably lost track
  > of such things.)
You're just on "egcs", via burley@gnu.ai.mit.edu.


  > g77 still being "beta" is partly the reason there are still
  > likely to be some things that are language-specific regarding
  > installation, such as build-time-configurable parameters (see
  > "Maximum Stackable Size", IIRC, in the g77 docs).
  > 
  > But it will be nice to have most/all of g77's special installation
  > instructions go away, and I'm not even thinking about the effort
  > I have to put in to maintain it, but rather the efforts users
  > have to make to cope with g77's mysterious past.  :)
I think we're in basic agreement -- most of the g77 specific install
docs shouldn't apply to egcs installs.

For the few things which are still Fortran specific, and useful, how
often do people use them?  Is the class of users that would use those
options already familiar with g77 installs and docs?


jeff

Re: g77 changes

[Jeffrey A Law]

  In message < rzqbtzikrzc.fsf@djlvig.dl.ac.uk >you write:
  >  Jeffrey> This is a question with broader implications.  ie, we're
  >  Jeffrey> still trying to answer the version # question about the
  >  Jeffrey> release as a whole :-)
  > 
  > OK, as long as it's not misleading in the end result.  (I was raising
  > this under apparent threat of a release.)
Well, this is one of the critical non-technical issues, along with some
egcs specific docs.


  >  >> * Installation instructions
  >  Jeffrey> Yes.  This is a general problem -- however I think we want
  >  Jeffrey> to shy away from language specific install stuff.
  > 
  > Yes, one would hope most would be unnecessary, but at present it
  > contains instructions involving patching gcc 2.7, etc., etc.
Well, as long as g77 development is officially happening outside egcs,
I'd like to shy away from modifying the "f" subdir too much.

As such I'd personally be happy with some egcs specific install instructions
which also mentioned that they override any/all installation information
that may be found in any of the subdirs.  Others may have different thoughts
of course :-)

  >  Jeffrey> We should note major bugfixes and user interface changes; I
  >  Jeffrey> don't think we want to detail every change since 0.5.21.
  > 
  > There are already changes listed (typically not too many per release)
  > but there's probably more which needs adding and also, likely things
  > to be removed from the `actual bugs' list (such as Alpha fixing,
  > perhaps).
  > 
  > [I'd try to write doc if I knew enough (and had time) but...]
I personally don't know enough either -- it's something that someone else
will probably have to volunteer to do -- and (IMHO) it's not something we
should hold up the first release for.

jeff

Re: collect2 compiles C with g77 !

[Jeffrey A Law]

  In message < 199711110151.CAA04239@mail.macqel.be >you write:
  > On m68k-motorola-sysv all g77/execute tests fail because collect2 tries
  > to compile a c-program with a fortran compiler :).  Details using -v and
  > -Wl,-debug options follow.
Thanks.  Odd that nobody else is having this problem.

It looks like collect2 thinks there are EH frame tables that need
initialization for various objects in libgcc2, which I guess is a
side effect of compiling libgcc2 with -fexceptions.

  >     1. Make collect2 always invoke gcc
This would be my first thought; though it looks like collect2 is
setup (for a reason?) to use whatever driver that called collect2
(ie g77, g++, gcc)

  >     2. Make g77 recognize .c suffix and invoke cc1
The one problem I can see with this is it might end up invoking cc1
with fortran options.  The Fortran folks have said this would would
be desirable so that g77 foo.f bar.c would do the expected thing.

  >     3. Make collect2 directly generate assembler, not C.
I don't think we want to stray down that path.  That would mean
including much of varasm.c/final.c in collect2 -- gross.

jeff

Re: collect2 compiles C with g77 !

[Jason Merrill]

How about passing -x c to sub-compiles?

Jason

Re: collect2 compiles C with g77 !

[Jeffrey A Law]

  In message < u97m9wgnfo.fsf@yorick.cygnus.com >you write:
  > How about passing -x c to sub-compiles?
Which would then mean we could zap the #ifdef __cplus_plus gunk in the
file collect2 builds and compiles.

My only concern was that there might be cases where it actually needed
to call the same language (c/c++) for a sub-compile that was used to
call collect2 initially.

Jeff

Re: collect2 compiles C with g77 !

[Jason Merrill]

>>>>> Jeffrey A Law <law@cygnus.com> writes:

>   In message < u97m9wgnfo.fsf@yorick.cygnus.com >you write:
>> How about passing -x c to sub-compiles?

> Which would then mean we could zap the #ifdef __cplus_plus gunk in the
> file collect2 builds and compiles.

Yep.

> My only concern was that there might be cases where it actually needed
> to call the same language (c/c++) for a sub-compile that was used to
> call collect2 initially.

For -frepo, that is the case.  And you probably want to use the same driver
anyway, because there's no reliable way to find the corresponding gcc driver.

Jason

Re: collect2 compiles C with g77 !

[Craig Burley]

>  >     2. Make g77 recognize .c suffix and invoke cc1
>The one problem I can see with this is it might end up invoking cc1
>with fortran options.  The Fortran folks have said this would would
>be desirable so that g77 foo.f bar.c would do the expected thing.

In gcc2 land (which I'm used to ;-), once g77 has been
merged into the gcc directory, the cc1 executable built
from that directory recognizes (and ignores, instead of
rejects) Fortran options.

        tq vm, (burley)