das@LOCUS.UCLA.EDU (08/05/86)
Under SysV, 4.1, and 4.2,
cc -c -o blah blah1.c blah2.c
produces two object files, named blah1.o and blah2.o
cc -c -o blah blah.c
produces one object file, named blah.o
Under 4.3,
cc -c -o blah blah1.c blah2.c
produces two object files, named blah1.o and blah2.o
cc -c -o blah blah.c
produces one object file, named blah, not blah.o!!!!
While normal people don't usually specify both the -c flag and -o filename,
some shell scripts do (e.g. the C++ script "CC"). Obviously, someone decided
that -o should mean "If there's a single obvious output file, -o should
rename it," rather than "-o should rename the a.out file", since
cc -S -o blah blah.c
puts the assembly language output in blah, not blah.s (again, only when exactly
one source file is named).
I think the change is a mistake, since it breaks existing software and there's
no compelling reason I can see to prefer the new meaning of -o over the old.
Justifications?
-- David Smallberg, das@locus.ucla.edu, {sdcrdcf,ucbvax}!ucla-cs!das
-- David Smallberg, das@locus.ucla.edu, {sdcrdcf,ucbvax}!ucla-cs!dasrs@mirror.UUCP (08/05/86)
] "cc -o foo -c blah.c" now creates foo, instead of "blah.o"
HURRAH! Justification? I have source I want to conditionally-compile,
and I don't want to play games in my Makefile:
.c.o: ; $(CC) $(CFLAGS) $<
.c.do: ; $(CC) -DDEBUG $(CFLAGS) -o $@ $<
The old way "-o is ignored if -c is specified" is inconsistent; the new
way "-o specifies the output file name" is reasonable, sensible, and
orthogonal.
----
Rich $alz {mit-eddie, ihnp4, wjh12, cca, cbosgd, seismo}!mirror!rs
Mirror Systems 2067 Massachusetts Avenue Cambridge, MA 02140
Telephone: 617-661-0777
"Hi, mom!"chris@umcp-cs.UUCP (Chris Torek) (08/06/86)
In article <377@curly.ucla-cs.ARPA>, das@LOCUS.UCLA.EDU writes: >... Under 4.3, > cc -c -o blah blah.c >produces one object file, named blah, not blah.o!!!! ... I think >the change is a mistake, since it breaks existing software and >there's no compelling reason I can see to prefer the new meaning >of -o over the old. Justifications? I have no real idea why the change was installed; most likely Berkeley got a request for it and saw no good reason *not* to implement it. I remember a few years ago being surprised that `cc -c -o x.o c.c' did not work this way. It is, however, trivial to change it back. In /usr/src/bin/cc.c, find the four lines if (cflag && nc==1 && outfile) av[2] = outfile; else av[2] = setsuf(clist[i], 'o'); and remove the first three. Alternatively, use a shell script to filter out `-o' whenever there is at least one `-c': #! /bin/sh # # cc - front end for /bin/cc to remove `extra' -o arguments (untested). # # Could use some speed improvement. Note that this does not handle # whitespace in file names properly. # realcc=/bin/cc fullargs=; nooargs=; cflag=false; noo=true for i do case "$i" in -c) cflag=true; nooargs="$nooargs $i"; noo=true;; -o) noo=false;; *) if $noo; then nooargs="$nooargs $i"; fi; noo=true;; esac fullargs="$fullargs $i" done if $cflag; then exec $realcc $nooargs; else exec $realcc $fullargs; fi -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
stevesu@copper.UUCP (Steve Summit) (08/07/86)
In article <377@curly.ucla-cs.ARPA>, David Smallberg writes: > Under 4.3, > cc -c -o blah blah.c > produces one object file, named blah, not blah.o!!!! > > Obviously, someone decided that -o should mean "If there's a single obvious > output file, -o should rename it," I think the change is a mistake, since it > breaks existing software and there's no compelling reason I can see to > prefer the new meaning of -o over the old. Justifications? And in article <2743@umcp-cs.UUCP>, Chris Torek writes: > I have no real idea why the change was installed; most likely > Berkeley got a request for it and saw no good reason *not* to > implement it. I remember a few years ago being surprised that > `cc -c -o x.o c.c' did not work this way. I'm sorry about the broken Makefiles, but I'm happy to see this change, as it can be extremely useful. (I've been using cc drivers with this change for about a year now.) Currently, I am doing software development on a Sequent Balance 8000, but I also want to build Vax versions of my programs, using a cross-compiler. My Makefiles can do things like: .SUFFIXES: .ovax .c.ovax: vaxcc $(CFLAGS) -c $*.c -o $*.ovax This lets me keep sources, native object (.o) files, and Vax object (.ovax) files in the same directory. Without a working -o switch on cc -c, you have to do things like .c.ovax: cp $*.c tmp.c vaxcc $(CFLAGS) -c tmp.c mv tmp.o $*.ovax Besides littering your directory with files called tmp.c, this method does not work if you try to do a "parallel make," making use of the Balance 8000's multi-processor architecture to do several compilations at once. (Yes, there are slightly more clever ways to name the tmp files so that they do not step on each other.) I'd vote for keeping the new feature and fixing the broken Makefiles. Perhaps it would help if cc -c -o generated a warning when given more than one input file, rather than silently ignoring the -o. (That might warn you that something was amiss, if you had an old-fashioned Makefile that used -c and -o but expected the -o not to make any difference.) Steve Summit tektronix!copper!stevesu