Re: [GNU Bison 2.4.2] testsuite: Failing tests of bison 2.4.2 on Solaris 8+9 w/Sun Studio 11+12

[Dagobert Michelsen]

Hi Joel,

Am 20.04.2010 um 06:46 schrieb Joel E. Denny:
> On Thu, 15 Apr 2010, Eric Blake wrote:
> > On 04/15/2010 03:39 PM, Joel E. Denny wrote:
> > > % 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
>
> > > 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.
> >
> > It would be helpful if you could show the getopt() declarations in  
> > both
> > headers, and enough context (like how __EXTENSIONS__ affects
> > <unistd.h>), for comparison.
>
> From /usr/include/unistd.h:
>
> ------------------------------
> #if defined(__STDC__)
> ...
> #if (defined(_XOPEN_SOURCE) && (_XOPEN_VERSION - 0 >= 4)) || \
>        defined(__EXTENSIONS__)
> extern int  getopt(int, char *const *, const char *);
> ...
> #endif /* (defined(_XOPEN_SOURCE) && (_XOPEN_VERSION - 0 >= 4))... */
> ...
> #else  /* __STDC__ */
> ...
> #if (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)) || \
>        defined(_XPG4_2) || defined(__EXTENSIONS__)
> #if (defined(_XOPEN_SOURCE) && (_XOPEN_VERSION - 0 >= 4)) || \
>        defined(__EXTENSIONS__)
> extern int  getopt();
> ...
> #endif /* (defined(_XOPEN_SOURCE) && (_XOPEN_VERSION - 0 >= 4))... */
> ...
> #endif /* (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE))... */
> ------------------------------
>
> From /opt/csw/include/getopt.h:



> ------------------------------
> #if defined (__STDC__) && __STDC__
> #ifdef __GNU_LIBRARY__
> /* Many other libraries have conflicting prototypes for getopt, with
>   differences in the consts, in stdlib.h.  To avoid compilation
>   errors, only prototype getopt for the GNU C library.  */
> extern int getopt (int argc, char *const *argv, const char  
> *shortopts);
> #else /* not __GNU_LIBRARY__ */
> extern int getopt ();
> #endif /* __GNU_LIBRARY__ */
> ...
> #else /* not __STDC__ */
> extern int getopt (); <---------- line 122, where the error is  
> reported
> ...
> endif /* __STDC__ */
> ------------------------------

Here is a rationaly of why OpenCSW has an additional getopt.h:
The /opt/csw/include/getopt.h is actually from libgnugetopt. It is  
needed
for some packages without getopt_long detection during autoconfigure to
compile on Solaris, as Solaris does not have getopt_long natively. The  
source
was taken from
  http://distfiles.macports.org/libgnugetopt/

Unfortunately I was unable to find a real upstream site with  
bugtracking etc.

> To see why these headers select a different getopt prototype:
>
> % cat tmp.cc
> __STDC__
> % CC -E tmp.cc
> #1 "tmp.cc"
> 0
>
> In contrast:
>
> % g++ -E tmp.cc
> # 1 "tmp.cc"
> # 1 "<built-in>"
> # 1 "<command line>"
> # 1 "tmp.cc"
> 1
>
> > Is there anything else in /opt/csw/include that Dago really wants to
> > use?
>
> He'll have to answer that.

Yes, a lot of things as the general OpenCSW policy is to link against  
libraries
provided by OpenCSW. Think of libiconv, gettext, etc.

> On Fri, 16 Apr 2010, Eric Blake wrote:
>
> > I've done some more testing.  It turns out that gnulib _correctly_
> > rejects /opt/csw/include/getopt.h as incompatible with the current
> > compiler,
>
> But CC reports the error as being in that file.
>
> > if you use autoconf 2.64 (prior to that, if the existence and
> > compilation checks disagree, autoconf went with the existence check).
>
> We are using autoconf 2.65.
>
> > The errors I'm seeing are due to the fact that Dagobert is using  
> > CC, not
> > cc
>
> To be clear, Dago is simply running the bison test suite, which  
> requires a
> C++ compiler.
>
> > So I'm working on some patches to allow clean C++ compilation of  
> > getopt
> > (even if they won't be accepted upstream in glibc); and with luck,  
> > that
> > will also fix Dagobert's problem with CC.
>
> I updated gnulib to 2f3175, but the failure remains the same for  
> bison.
>
> Is there any more information we can provide?

Thanks for your efforts!

  -- Dago