Hi Joel, > I'm adding bug-gnulib because this portability problem is larger than > bison.
OK, I will give my opinion about it. > I can reproduce the problem independently of bison as follows: > > % cat > tmp.cc > #define __EXTENSIONS__ 1 > #include <unistd.h> > #include <getopt.h> > % CC -I/opt/csw/include tmp.cc > "/opt/csw/include/getopt.h", line 122: Error: Only one of a set of overloaded > functions can be extern "C". > 1 Error(s) detected. > % CC -V > CC: Sun C++ 5.9 SunOS_sparc Patch 124863-19 2009/12/02 > % uname -a > SunOS current9s 5.9 Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise-T5220 > > The trouble is that, because of the __EXTENSIONS__ definition, > /usr/include/unistd.h defines getopt with a different prototype than does > /opt/csw/include/getopt.h. > > Dago is setting CPPFLAGS=-I/opt/csw/include before configuring bison <unistd.h> is a standard feature of POSIX and Solaris. __EXTENSIONS__ is a standard feature of Solaris, see [1]. <getopt.h> is not a standard feature of Solaris, but has been installed through CSW packages (not from Sun). The three, taken together, clash. Whom to blame? The answer is clear IMO: The non-standard one, /opt/csw/include/getopt.h, ought to be fixed. Or Dagobert should not use -I/opt/csw/include. Which of these, that's something Dagobert and the CSW people have to negotiate among themselves. > Should gnulib be extended to handle this case? gnulib attempts to give people one way to compile packages on each platform. If using "cc" does not work on OSF/1, but "cc -nodtk" works, there is no need for gnulib to support "cc". If using "gcc -Wall -Werror" does not work on some platform, but "gcc -Wall" does, there is no need for gnulib to support "gcc -Wall -Werror". If using "cc -D__EXTENSIONS__ -I/opt/csw/include" does not work on Solaris, but "cc -D__EXTENSIONS__" works, there is no need for gnulib to support "cc -D__EXTENSIONS__ -I/opt/csw/include". Bruno [1] http://docs.sun.com/app/docs/doc/816-0220/6m6nkors4?a=view
