Do your cc & ld accept empty *.c files?
Stephen R. van den Berg
If you were to feed your C compiler the following C file:
------------------cut here--------------------------------
/* intentionally left empty */
------------------cut here--------------------------------
Will it happily create an object file?
And, if it does, does the linker have any problems with it, when I tell it
to link it to some other (real) object files?
It would be kind of logical. However, I could imagine that some sloppily
programmed cc or ld would dump core on those (or refuse to compile/link).
What does your cc/ld say?
--
Sincerely, be...@messua.informatik.rwth-aachen.de
Stephen R. van den Berg (AKA BuGless). be...@physik.tu-muenchen.de
Real programmers don't produce results, they return exit codes.
Trevor Cotton
MIPS RISCompilers have no problem with this. An object file is created
that can be linked.
--
--trevc--
Trevor Cotton, MIPS Computer Systems Inc.
Email: {wyse,ames,decwrl,pyramid}!mips!trevc tr...@mips.com
Brandon S. Allbery KF8NH
+---------------
| If you were to feed your C compiler the following C file:
|
| ------------------cut here--------------------------------
| /* intentionally left empty */
| ------------------cut here--------------------------------
|
| Will it happily create an object file?
| And, if it does, does the linker have any problems with it, when I tell it
| to link it to some other (real) object files?
Plexus System III ld barfed on empty .o files. (Discovered while attempting
to port gnumacs to SysIII --- not for the faint of heart, believe me!
process.o ends up empty if you don't have job control.) cc would happily
create the empty .o file, however.
(Not that anyone runs Plexus SysIII any more... I hope!)
++Brandon
--
Brandon S. Allbery KF8NH: DC to LIGHT! [44.70.4.88]
all...@NCoast.ORG uunet!usenet.ins.cwru.edu!ncoast!allbery
David G. Paschich
I'm trying to check for a very fundamental portability issue.
If you were to feed your C compiler the following C file:
------------------cut here--------------------------------
/* intentionally left empty */
------------------cut here--------------------------------
Will it happily create an object file?
And, if it does, does the linker have any problems with it, when I tell it
to link it to some other (real) object files?
In one of the few things the Apollo Domain/Os compiler does right, it
deals with an empty source file and the resulting object file without
barfing.
--
David G. Paschich Comp. Sci. Undergrad Ass'n. UC Berkeley
dpas...@soda.berkeley.edu ...!ucbvax!soda!dpassage
Dave Decot
[0]% uname -a
HP-UX hpcupt1 A.B7.00 U 9000/840 5207
[1]% touch cc.test.c
[2]% make cc.test
cc -O cc.test.c -o cc.test
cc: "cc.test.c", line 1: warning 501: Empty source file.
/bin/ld: Unsatisfied symbols:
main
*** Error code 1
Stop.
[3]%
Dave
Greg Hunt
>
> I'm trying to check for a very fundamental portability issue.
>
> If you were to feed your C compiler the following C file:
>
> ------------------cut here--------------------------------
> /* intentionally left empty */
> ------------------cut here--------------------------------
>
> Will it happily create an object file?
> And, if it does, does the linker have any problems with it, when
> I tell it to link it to some other (real) object files?
On a DG AViiON system using GNU C 1.37.31, everything works just fine.
You get a very small object file from the empty source file. The
linker has no problems linking that object with a real main function
to produce an executable. The executable runs just fine.
Just another data point for your survey ...
--
Greg Hunt Internet: hu...@dg-rtp.rtp.dg.com
DG/UX Kernel Development UUCP: {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC, USA These opinions are mine, not DG's.
John Redford
If you were to feed your C compiler the following C file:
------------------cut here--------------------------------
/* intentionally left empty */
------------------cut here--------------------------------
Will it happily create an object file?
And, if it does, does the linker have any problems with it, when I tell it
to link it to some other (real) object files?
On a SPARC 2, 4.1.1:
/bin/cc works
gcc 1.40 works
The Sparc C compiler (also cc) cant cope. (This is made by Sun...)
/bin/ld works
gnu-ld works
Sparc ld bags.