I am having a problem I don't understand compiling emacs with the
studio 10 compiler.  The first error I get is:

"/usr/include/stdio.h", line 299: identifier redeclared: getsubopt
	current : function(pointer to pointer to char, pointer to
	pointer to char, pointer to pointer to char) returning int
	previous: function(pointer to pointer to char, pointer to
	const pointer to char, pointer to pointer to char) returning
	int : "/usr/include/stdlib.h", line 165


The declaration in stdio.h around line 299 is:

#if !defined(_XOPEN_SOURCE)
extern int	getsubopt(char **, char *const *, char **);
#endif /* !defined(_XOPEN_SOURCE) */


And in stdlib.h around line 165 I see:

extern int getsubopt(char **, char *const *, char **);


To me, both of these declarations look like function(pointer to
pointer to char, pointer to const pointer to char, pointer to pointer
to char) returng int.  Why is the compiler giving this error?

Jim Smith <3.141592six@gmail.com> wrote:
> I am having a problem I don't understand compiling emacs with the
> studio 10 compiler.  The first error I get is:
> 
> "/usr/include/stdio.h", line 299: identifier redeclared: getsubopt
> 	current : function(pointer to pointer to char, pointer to
> 	pointer to char, pointer to pointer to char) returning int
> 	previous: function(pointer to pointer to char, pointer to
> 	const pointer to char, pointer to pointer to char) returning
> 	int : "/usr/include/stdlib.h", line 165
> 
> 
> The declaration in stdio.h around line 299 is:
> 
> #if !defined(_XOPEN_SOURCE)
> extern int	getsubopt(char **, char *const *, char **);
> #endif /* !defined(_XOPEN_SOURCE) */
> 
> 
> And in stdlib.h around line 165 I see:
> 
> extern int getsubopt(char **, char *const *, char **);
> 
> 
> To me, both of these declarations look like function(pointer to
> pointer to char, pointer to const pointer to char, pointer to pointer
> to char) returng int.  Why is the compiler giving this error?

That's interesting. Let's reformat the error message
to make it more readable:

"/usr/include/stdio.h", line 299: identifier redeclared: 
getsubopt 

current : function(
	pointer to pointer to char, 
	pointer to pointer to char, 
	pointer to pointer to char) returning int

previous: function(
	pointer to pointer to char, 
	pointer to const pointer to char, 
	pointer to pointer to char) returning int 
: "/usr/include/stdlib.h", line 165


Note the difference in the "const"ness of the pointer 
of the second parameter.
However, this looks surprising given the header file 
stdio.h and stdlib.h.
Maybe you want to look at a preprocessed file 
and see if the compiler sees the correct header file.
You can get the preprocessed file by adding -E option to the compiler.
-- 
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"

Seongbae Park <Seongbae.Park@Sun.COM> writes:

> Jim Smith <3.141592six@gmail.com> wrote:
>> I am having a problem I don't understand compiling emacs with the
>> studio 10 compiler.  The first error I get is:
>> 
>> "/usr/include/stdio.h", line 299: identifier redeclared: getsubopt
>> 	current : function(pointer to pointer to char, pointer to
>> 	pointer to char, pointer to pointer to char) returning int
>> 	previous: function(pointer to pointer to char, pointer to
>> 	const pointer to char, pointer to pointer to char) returning
>> 	int : "/usr/include/stdlib.h", line 165
>> 
>> 
>> The declaration in stdio.h around line 299 is:
>> 
>> #if !defined(_XOPEN_SOURCE)
>> extern int	getsubopt(char **, char *const *, char **);
>> #endif /* !defined(_XOPEN_SOURCE) */
>> 
>> 
>> And in stdlib.h around line 165 I see:
>> 
>> extern int getsubopt(char **, char *const *, char **);
>> 
>> 
>> To me, both of these declarations look like function(pointer to
>> pointer to char, pointer to const pointer to char, pointer to pointer
>> to char) returng int.  Why is the compiler giving this error?
>
> That's interesting. Let's reformat the error message
> to make it more readable:
>
> "/usr/include/stdio.h", line 299: identifier redeclared: 
> getsubopt 
>
> current : function(
> 	pointer to pointer to char, 
> 	pointer to pointer to char, 
> 	pointer to pointer to char) returning int
>
> previous: function(
> 	pointer to pointer to char, 
> 	pointer to const pointer to char, 
> 	pointer to pointer to char) returning int 
> : "/usr/include/stdlib.h", line 165
>
>
> Note the difference in the "const"ness of the pointer 
> of the second parameter.
> However, this looks surprising given the header file 
> stdio.h and stdlib.h.
> Maybe you want to look at a preprocessed file 
> and see if the compiler sees the correct header file.
> You can get the preprocessed file by adding -E option to the compiler.

In the current emacs cvs source in the lib-src directory I ran:

 cc -E -DHAVE_CONFIG_H -I. -I../src
 -I/usr/local/src/EMACS/emacs/lib-src
 -I/usr/local/src/EMACS/emacs/lib-src/../src
 /usr/local/src/EMACS/emacs/lib-src/getopt.c

and I get, in part:


[snip]

# 137 "/usr/include/stdio.h"

[snip]

# 299
extern int	getsubopt(char **, char * *, char **);
# 301

 
# 304
extern char	*cuserid(char *);
extern int	getopt(int, char * *,  char *)

[snip]

so there are "const"s missing from getsubopt and getopt that are there
in /usr/include/stdio.h

Jim Smith  wrote:

>>> extern int	getsubopt(char **, char *const *, char **);
> extern int	getsubopt(char **, char * *, char **);

Now where does that '#define const' come from?

Marc wrote:
> Jim Smith  wrote:
> 
> 
>>>>extern int	getsubopt(char **, char *const *, char **);
>>
>>extern int	getsubopt(char **, char * *, char **);
> 
> 
> Now where does that '#define const' come from?

Here:  ./emacs/lib-src/getopt.c

#if !defined __STDC__ || !__STDC__
/* This is a separate conditional since some stdc systems
    reject `defined (const)'.  */
# ifndef const
#  define const
# endif
#endif

Marc <marc.glisse@gmail.com> writes:

> Jim Smith  wrote:
>
>>>> extern int	getsubopt(char **, char *const *, char **);
>> extern int	getsubopt(char **, char * *, char **);
>
> Now where does that '#define const' come from?

Ok thanks. That is it.  Sorry for the waste of time.

Jim Smith <3.141592six@gmail.com> wrote:
>>> The declaration in stdio.h around line 299 is:
>>> 
>>> #if !defined(_XOPEN_SOURCE)
>>> extern int	getsubopt(char **, char *const *, char **);
>>> #endif /* !defined(_XOPEN_SOURCE) */
....

> In the current emacs cvs source in the lib-src directory I ran:
> 
>  cc -E -DHAVE_CONFIG_H -I. -I../src
>  -I/usr/local/src/EMACS/emacs/lib-src
>  -I/usr/local/src/EMACS/emacs/lib-src/../src
>  /usr/local/src/EMACS/emacs/lib-src/getopt.c
> 
> and I get, in part:
> 
> [snip]
> 
> # 137 "/usr/include/stdio.h"
> 
> [snip]
> 
> # 299
> extern int	getsubopt(char **, char * *, char **);
> # 301
> 
>  
> # 304
> extern char	*cuserid(char *);
> extern int	getopt(int, char * *,  char *)
> 
> [snip]
> 
> so there are "const"s missing from getsubopt and getopt that are there
> in /usr/include/stdio.h

This output is contradicting to your first post.
Does your /usr/include/stdio.h include "const" ?
Your first post sounded like it is "char *const*" 
but this -E output says it's not.
If /usr/include/stdio.h has a correct declaration,
then either your cpp(or cc) is lying 
that it's including /usr/include/stdio.h but it's not,
or it's somehow dropping const from it.
Both hypothesis don't sound very plausible...
-- 
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"

Seongbae Park <Seongbae.Park@Sun.COM> writes:

> Jim Smith <3.141592six@gmail.com> wrote:
>>>> The declaration in stdio.h around line 299 is:
>>>> 
>>>> #if !defined(_XOPEN_SOURCE)
>>>> extern int	getsubopt(char **, char *const *, char **);
>>>> #endif /* !defined(_XOPEN_SOURCE) */
> ...
>
>> In the current emacs cvs source in the lib-src directory I ran:
>> 
>>  cc -E -DHAVE_CONFIG_H -I. -I../src
>>  -I/usr/local/src/EMACS/emacs/lib-src
>>  -I/usr/local/src/EMACS/emacs/lib-src/../src
>>  /usr/local/src/EMACS/emacs/lib-src/getopt.c
>> 
>> and I get, in part:
>> 
>> [snip]
>> 
>> # 137 "/usr/include/stdio.h"
>> 
>> [snip]
>> 
>> # 299
>> extern int	getsubopt(char **, char * *, char **);
>> # 301
>> 
>>  
>> # 304
>> extern char	*cuserid(char *);
>> extern int	getopt(int, char * *,  char *)
>> 
>> [snip]
>> 
>> so there are "const"s missing from getsubopt and getopt that are there
>> in /usr/include/stdio.h
>
> This output is contradicting to your first post.
> Does your /usr/include/stdio.h include "const" ?
> Your first post sounded like it is "char *const*" 
> but this -E output says it's not.
> If /usr/include/stdio.h has a correct declaration,
> then either your cpp(or cc) is lying 
> that it's including /usr/include/stdio.h but it's not,
> or it's somehow dropping const from it.
> Both hypothesis don't sound very plausible...

As others pointed out, the problem was a "#define const" in the
source.

For the record, adding "-Dconst=const" to CFLAGS allowed the
compilation to proceed.

Thanks to all for the help.

Jim Smith <3.141592six@gmail.com> writes:

>I am having a problem I don't understand compiling emacs with the
>studio 10 compiler.  The first error I get is:

>"/usr/include/stdio.h", line 299: identifier redeclared: getsubopt
>	current : function(pointer to pointer to char, pointer to
>	pointer to char, pointer to pointer to char) returning int
>	previous: function(pointer to pointer to char, pointer to
>	const pointer to char, pointer to pointer to char) returning
>	int : "/usr/include/stdlib.h", line 165


>The declaration in stdio.h around line 299 is:

>#if !defined(_XOPEN_SOURCE)
>extern int	getsubopt(char **, char *const *, char **);
>#endif /* !defined(_XOPEN_SOURCE) */


>And in stdlib.h around line 165 I see:

>extern int getsubopt(char **, char *const *, char **);


>To me, both of these declarations look like function(pointer to
>pointer to char, pointer to const pointer to char, pointer to pointer
>to char) returng int.  Why is the compiler giving this error?


SOmething in your code did:

#define	const 	/* nothing */

between includ stdlib.h and stdio.h

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Seongbae Park wrote:
[snip]
> That's interesting. Let's reformat the error message
> to make it more readable:
> 
> "/usr/include/stdio.h", line 299: identifier redeclared:
> getsubopt
> 
> current : function(
>         pointer to pointer to char,
>         pointer to pointer to char,
>         pointer to pointer to char) returning int
> 
> previous: function(
>         pointer to pointer to char,
>         pointer to const pointer to char,
>         pointer to pointer to char) returning int
> : "/usr/include/stdlib.h", line 165

Is there a way to do the reformatting automatically ?

----

Bye,
Roland

P.S.: BTW: What about adding an option to output error messages/warning
in XML format that scripts can process them better ?

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

Roland Mainz <roland.mainz@nrubsig.org> wrote:
> Seongbae Park wrote:
> [snip]
>> That's interesting. Let's reformat the error message
>> to make it more readable:
>> 
>> "/usr/include/stdio.h", line 299: identifier redeclared:
>> getsubopt
>> 
>> current : function(
>>         pointer to pointer to char,
>>         pointer to pointer to char,
>>         pointer to pointer to char) returning int
>> 
>> previous: function(
>>         pointer to pointer to char,
>>         pointer to const pointer to char,
>>         pointer to pointer to char) returning int
>> : "/usr/include/stdlib.h", line 165
> 
> Is there a way to do the reformatting automatically ?

I don't know any.

> P.S.: BTW: What about adding an option to output error messages/warning
> in XML format that scripts can process them better ?

It sounds interesting, but I'm not sure who would use it though.
-- 
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"

Seongbae Park <Seongbae.Park@Sun.COM> writes:

> Roland Mainz <roland.mainz@nrubsig.org> wrote:
>
>> P.S.: BTW: What about adding an option to output error messages/warning
>> in XML format that scripts can process them better ?
>
> It sounds interesting, but I'm not sure who would use it though.

Nicely put :-)

-- 
Dragan Cvetkovic, 

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!

Roland Mainz wrote:

>> That's interesting. Let's reformat the error message
>> to make it more readable:
>> "/usr/include/stdio.h", line 299: identifier redeclared:
>> getsubopt
>> 
>> current : function(
>>         pointer to pointer to char,
>>         pointer to pointer to char,
>>         pointer to pointer to char) returning int
> 
> Is there a way to do the reformatting automatically ?

I guess sending the messages to perl -pe 's/([,\(])/\1\n\t/g' is not a
good enough heuristic. Anyway, it gives a nice little shell programmation
exercise�: execute cc, send the messages through some reformatting
program, and exit with the same exit code as cc did.

> P.S.: BTW: What about adding an option to output error messages/warning
> in XML format that scripts can process them better ?

Wow, now that would help make colouring the output feasible...

Marc wrote:
> > P.S.: BTW: What about adding an option to output error messages/warning
> > in XML format that scripts can process them better ?
> 
> Wow, now that would help make colouring the output feasible...

The idea is more that scripts can process the compiler messages without
doing blind guessing. I've seen (and fixed) too often automated build
scripts which tried to parse&analyse the messages - which worked
perfectly until the first unexpected message appeared. And then the
script needed fixing again. And then for the next unknown thing again...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

Seongbae Park wrote:
> > P.S.: BTW: What about adding an option to output error messages/warning
> > in XML format that scripts can process them better ?
> 
> It sounds interesting, but I'm not sure who would use it though.

The idea is more that scripts can process the compiler messages without
doing blind guessing. I've seen (and fixed) too often automated build
scripts which tried to parse&analyse the messages - which worked
perfectly until the first unexpected message appeared. And then the
script needed fixing again. And then for the next unknown thing again.
Over and over again.
Having a language-independent way (e.g. C, C++, JAVA, Fortran etc.) to
define some things in XML (e.g. what is message text, what's a variable,
what's a line number etc.) would help a lot in such cases since the
scripts would no longer have to do any guessing and just pick the infos
they need from the XML stream...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)