"crypt.c", line 176: warning: empty translation unit
Could someone please tell me what a translation unit is so I know where
to begin looking for this. The crypt.c file only has 175 lines, so I
assume the problem is something similar to unmatched parentheses, brackets,
etc., but I have no idea what it is. Thanks again in advance.
Chuck
"Translation unit" is the language legalese for what you normally think
of as a source file. So this is saying there is no real C code in
the source file. This can happen if the source file is only comments.
Another case is if you aren't compiling with the right preprocessor
macro values. Example:
337$ cat x.c
#if BAR
int foo() {
return 7;
}
#endif
338$ /usr/bin/cc -c -DBAR x.c
339$ /usr/bin/cc -c x.c
"x.c", line 6: warning: empty translation unit
Jonathan Schilling
I typically fix these by adding some harmless external reference to the
file:
#if BAR
int foo() {
return 7;
}
#else
extern int main(); /* prevent "empty translation unit" warning */
#endif
Note that the external reference has _no_ effect on the compiler output,
since it isn't actually used. The resulting "empty" x.o does not
contain the string "main".
>Bela<
In article <ff3c0649.03071...@posting.google.com>,
J. L. Schilling <jlsels...@my-deja.com> wrote:
>"Translation unit" is the language legalese for what you normally think
>of as a source file. So this is saying there is no real C code in
>the source file. This can happen if the source file is only comments.
>Another case is if you aren't compiling with the right preprocessor
>macro values. Example:
>
>337$ cat x.c
>#if BAR
>int foo() {
> return 7;
>}
>#endif
>338$ /usr/bin/cc -c -DBAR x.c
>339$ /usr/bin/cc -c x.c
>"x.c", line 6: warning: empty translation unit
>
Thanks. That explains it perfectly. The whole file is effectively
removed if CRYPT isn't defined. Now I just need to figure out how
to fix it in a way that doesn't seem like a kludge.
Chuck
Thanks, Bela. I guess that's one way to do it, but it seems like a kludge.
I was trying to do it in the Makefile, but haven't had much luck. I tried
changing this:
crypt.o: crypt.c sc.h
$(CC) ${CFLAGS} ${CRYPT} ${DOBACKUPS} -c crypt.c
to this:
crypt.o: crypt.c sc.h
if [ ${CRYPT} ]; then \
$(CC) ${CFLAGS} ${CRYPT} ${DOBACKUPS} -c crypt.c; \
fi
But then it complains because crypt.o doesn't exist. The object files,
including crypt.o, are all listed in ${OBJS}. Is there a way to redefine
that variable based on whether ${CRYPT} is defined? I guess I need to
take time to learn make better. The obvious things I tried didn't seem
to work, but I guess that's because make isn't sh or bash, or any other
shell.
Chuck
Make is a declarative language with a few procedural features bolted
on in the gmake idiom. You can probably figure out some way to get
make to stand on its head to do what you want, but by then you've
got a nearly unreadable makefile. All for what -- to clear some
innocuous warning. You're better off living with the warning.
I know that some people won't sleep well until all their warnings
are cleared ... but unless you can convince somebody to modify
crypt.c, it's not worth the effort here. You can always stick an
"echo" in the makefile that says to expect a particular warning
on the next step. If you have a management mandate to clear all
warnings, then you're in a different boat.
Jonathan Schilling
The only way to get USL-derived compilers not to warn about this is to
feed them _something_ in the file. If you don't like `extern int
main();', how about an include? It doesn't even have to be ifdef'd. In
fact you can just move one of the includes that's inside the `#ifdef
CRYPT' above it. Or add an include of something innocuous like
unistd.h.
>Bela<
Chuck