Chuck Martin wrote:

> In article <20030711231222.GT24551@sco.com>,
> Bela Lubkin wrote:
> >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".
>
> 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.

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<

Okay. Thanks for the input.

Chuck

In article <20030722173539.GF24551@sco.com>,
Bela Lubkin wrote:
>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.

Thanks. I at least have several ideas to consider now.

Chuck