[vox-tech] compiler error causing me great sadness
Peter Jay Salzman
p at dirac.org
Thu Sep 30 12:03:22 PDT 2004
Ken,
Thank you (again!) for such a wonderful response. This email is a gem.
On Wed 29 Sep 04, 10:27 PM, Ken Herron <kherron+lugod at fmailbox.com> said:
> --On Wednesday, September 29, 2004 11:06:50 PM -0400 Peter Jay Salzman
> <p at dirac.org> wrote:
>
> > #ifndef _FSIGNAL_H_
> > #define _FSIGNAL_H_
> >
> > #define __GNU_SOURCE
> > #include <signal.h>
> > #include <stdio.h>
>
> I think you want _GNU_SOURCE there, not __GNU_SOURCE. Though "#define
> _POSIX_C_SOURCE 199309L" should be adequate.
>
>
> >It's kind of a mess, but when I include __USE_POSIX and
> >__USE_POSIX199309, I get "constant redefinition" errors. So instead, I
> >add:
>
> You aren't supposed to define the __USE_* macros yourself. See
> <features.h>. Actually, when I ran your fsignal.h through "gcc -E" the
> postprocessed C contained the siginfo_t definition. If you're not getting
> it, then perhaps you've set one of the standard-selection macros to an
> old standard such that __USE_POSIX199309 isn't supposed to be defined.
Thanks for telling me this. I didn't know anything about __USE_* macros
until I started grunging around in system header files, and noticed they
seemed to pull in what I wanted.
But the features.h header you mentioned is a _great_ resource. Thanks for
pointing it out!
> >How am I supposed to figure out how to get a definition for siginfo_t?
> >Am I really supposed to grub around in the libc header files???
>
> No, of course not. There are standards for this stuff, though programming
> books don't always do a good job of explaining them. For example, on a
> modern system running:
>
> echo '#include <signal.h>' | gcc -E -
>
> should get you a copy of the siginfo_t definition, but:
>
> echo '#include <signal.h>' | gcc -E -D_POSIX_SOURCE -
>
> because _POSIX_SOURCE implies a specific revision of the POSIX standard
> that predates the siginfo_t type.
This is a really nice trick to have in my bag of tricks! Again, thanks for
showing this to me!
Interestingly, this compiled whether _GNU_SOURCE was defined in fsignal.h or
not:
fsignal.h:
#ifndef _FSIGNAL_H_
#define _FSIGNAL_H_
#include <stdio.h>
#include <signal.h>
void fpe_trap_enable(void);
void fpe_print_cause(FILE *file, siginfo_t *info);
void fpe_callback(int sig_number, siginfo_t *info, void *data);
void int_callback(int sig_number);
void Initialize_Signals(void);
#endif
avataralt.c:
#define _GNU_SOURCE <------ this was the key
#include "fsignal.h"
int main(void)
{
function(args);
return 0;
}
The program compiles just fine, even when I don't define _GNU_SOURCE in
fsignal.h.
The key is that _GNU_SOURCE needs to be defined in each .c file that includes
fsignal.h, but not fsignal.h itself (although putting it in fsignal.h doesn't
HURT anything. It just doesn't do much good).
So, my next question --- when #defining things for the sake of pulling in
definitions from headers, is it a general rule that you put the #defines in
the .c files and not the .h files?
It looks true in this case.
If someone wants to play with the code to verify, I can send a tar.bz2 file.
Pete
--
Make everything as simple as possible, but no simpler. -- Albert Einstein
GPG Instructions: http://www.dirac.org/linux/gpg
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D
More information about the vox-tech
mailing list