Re: signal warnings fixed; now what's a translation unit? - SCO

This is a discussion on Re: signal warnings fixed; now what's a translation unit? - SCO ; In article , 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: signal warnings fixed; now what's a translation unit?

  1. Re: signal warnings fixed; now what's a translation unit?

    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.

    Chuck


  2. Re: signal warnings fixed; now what's a translation unit?

    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<


  3. Re: signal warnings fixed; now what's a translation unit?

    Okay. Thanks for the input.

    Chuck


  4. Re: signal warnings fixed; now what's a translation unit?

    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


+ Reply to Thread