bug-bison
[Top][All Lists]
Advanced

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

Re: [GNU Bison 2.4.2] testsuite: Failing tests of bison 2.4.2 on Solaris


From: Joel E. Denny
Subject: Re: [GNU Bison 2.4.2] testsuite: Failing tests of bison 2.4.2 on Solaris 8+9 w/Sun Studio 11+12
Date: Tue, 20 Apr 2010 23:38:59 -0400 (EDT)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

On Tue, 20 Apr 2010, Eric Blake wrote:

> I'm assuming that later in configure we reject -lgnugetopt's getopt_long
> as broken (unless libgnugetopt has somehow picked up this month's glibc
> fix), meaning that we still want to declare rpl_getopt and friends;

Well, there's this:

configure:8265: checking for getopt_long_only
configure:8265: cc -o conftest -g -I/opt/csw/include -L/opt/csw/lib 
conftest.c  >&5
"conftest.c", line 111: warning: statement not reached
Undefined                       first referenced
 symbol                             in file
getopt_long_only                    conftest.o
ld: fatal: Symbol referencing errors. No output written to conftest
configure:8265: $? = 1
configure: failed program was:
...
configure:8265: result: no

> the
> conflict in getopt() is irrelevant if we are going to be declaring a
> replacement anyways.

It's relevant in that the original conflicting prototypes are included 
alongside the replacement prototypes.

> >>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__ */
> 
> since __STDC__ is 0 under CC but 1 under g++, maybe the best fix would
> be to make /opt/csw/include/getopt.h drop the check for the value of
> __STDC__?

Maybe /opt/csw/include/getopt.h needs this:

  #if defined (__STDC__) && (__STDC__ || defined (__SUNPRO_CC))

but then the __GNU_LIBRARY__ check above gives us an empty getopt argument 
list as before.  I guess we'd need to mimic /usr/include/unistd.h's check 
there too.

At some point, it starts to feel like /opt/csw/include/getopt.h's approach 
of quickly giving up on determining the best getopt argument list is 
easiest.  However, for C++, it can't give up because there's no such thing 
as an unspecified argument list.

> Or have gnulib's getopt.h explicitly define __STDC__ to 1?

Will that work for every getopt.h that gnulib's getopt.h might include?  
It seems that, in practice, the use of __STDC__ is not very standard.

> Or do we modify the logic in getopt.m4 that sets @HAVE_GETOPT_H@ to
> instead check two language-dependent values, one for C and one for C++,
> such that the #include_next <getopt.h> only occurs for languages where
> it will work?

That seems like the cleanest approach to me.




reply via email to

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