29 Aug
2006
29 Aug
'06
3:48 p.m.
It was thus said that the Great Tony Duell once stated:
Not very far.
[spc]linus:~/source/cgi/src>gcc --version
2.7.2.3
[spc]linus:~/source/cgi/src>cp pair.c pair.blah
[spc]linus:~/source/cgi/src>gcc -c pair.blah
gcc: pair.blah: linker input file unused since linking not done
[spc]linus:~/source/cgi/src>gcc -c pair.c
[spc]linus:~/source/cgi/src>ls pair.*
pair.blah pair.c pair.h pair.o
[spc]linus:~/source/cgi/src>
That's late 1997 (still running a RedHat 5.2 system). Checking a newer
system (install just two weeks ago):
[root at spodie tmp]# gcc -c hello.blah
gcc: hello.blah: linker input file unused because linking not done
[root at spodie tmp]# gcc -c hello.c
[root at spodie tmp]# ls hello.*
hello.blah hello.c hello.o
So it looks like GCC doesn't like arbitrary extentions.
-spc (which actually surprised me ... )
And even CP/M
apps were somewhat sensitized... Ever type A:ASM FOO.ASM and
wonder why you got a disk specification error?
Doesn't it try to write the object to S:, and the listing to M: ? Neither
of which probably exist.
I remember the first time I used ZASM (a CP/M Z80 assembler) on an
RML380Z. I typed 'ZASM FOO,ZSM and got a 'BDOS ERROR ON Z: SELECT' for my
efforts....
To return to the original question, how far back do you have to go for
unix's cc(1) to require .c on C source files, .o on object files (to be
linked it), and so on?