bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

getopt.h broken on FreeBSD


From: Sergey Poznyakoff
Subject: getopt.h broken on FreeBSD
Date: Mon, 19 Oct 2009 13:46:00 +0300

Hi,

We've got one more problem with getopt.h. It manifests
itself when compiling lex-generated parsers on FreeBSD.
What happens is the following: the system getopt.h defines
getopt_long, struct option and the accompanying stuff,
but does not define __need_getopt. Consequently, gnulib's
getopt.h includes it and attempts to redefine struct option
afterwards. This works so far as config.h is included before
getopt.h or unistd.h, but fails if it was not:

In file included from ../../gnu/unistd.h:56,
                 from grecs-lex.c:12:
../../gnu/getopt.h:184: error: redefinition of 'struct option'

The error is triggered by the fact that the default flex
skeleton begins with

 #include <stdio.h>
 #include <unistd.h>

and gives no way to insert anything before this.

I see the following possible solutions:

1. Define __GETOPT_PREFIX directly in getopt.in.h, instead of config.h.

The comment at line 40 says that 'Standalone applications should
#define __GETOPT_PREFIX', so its seems a natural solution, given
that only standalone applications use gnulib.

2. Use custom skeleton file for flex.

It works OK, but introduces a dependency on the flex version in use.

3. Ask flex authors to conditionally #include <config.h> in their
default skeleton file.

This will fix the problem in the long run (if they accept it),
but the question persists on how to fix it right now.

4. Override the .l.c rule in the Makefile.am like that:

.l.c:
        $(AM_V_LEX)$(am__skiplex) $(SHELL) $(YLWRAP) $< $(LEX_OUTPUT_ROOT).c 
address@hidden -- $(LEXCOMPILE) 
        $(AM_V_at)echo "#ifdef HAVE_CONFIG_H" > $@; \
        echo " #include <config.h>" >> $@; \
        echo "#endif" >> $@; \
        cat address@hidden >> $@; \
        rm address@hidden

This is what I'm using at the moment. The drawback is that it
unnecessarily complicates the Makefile.am.

5. Don't use config.h at all, defining everything in the cc's command
line.

The drawbacks of this approach are obvious.

What do you think?

Regards,
Sergey





reply via email to

[Prev in Thread] Current Thread [Next in Thread]