[bug-gnu-libiconv] Re: Unable to build libiconv 1.13.1 on OpenSolaris

[Bruno Haible]

Hi Dr. David,

I suggested to file a gcc bug report (or possibly a GNU as bug report) for
the link error you faced.

> my previous experience with several of the gcc 
> developers has been less than positive.

... and you cite four cases where you have disagreements over policy.

> I find some of the gcc development decisions absurd. 11 years after the C99 
> standard was ratified, gcc still does not fully support the standard.
> http://gcc.gnu.org/c99status.html

But not much is missing. The biggest point is probably the missing extended
identifiers. I guess few packages are trying to use that?

GNU clisp supports non-ASCII characters in function names for 10 or 11 years,
but people are not writing programs with Japanese or Chinese identifiers even
now. So maybe I wasted my time implementing that?

> I can not understand the logic for the default mode of compilation being some 
> GNU dialect of C
> 
> http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/C-Dialect-Options.html#C-Dialect-Options
> 
> `gnu89'
>      GNU dialect of ISO C90 (including some C99 features). This is the 
> default 
> for C code.
> 
> When (if?) C99 is fully supported, there will be another set of GNUisms, as 
> once 
> again the default will be to enable GNU-specific features which are not part 
> of 
> the language standard.

Yes, sure. Every vendor does this. GCC tries to help GNU projects and the Linux
kernel community through extensions. You think that standards are the most
important guideline; others think that providing features to help their users
is more important. This is a policy decision that you won't be able to argue
against.

> Of course I'm aware of options like -pedantic and -ansi, but the fact is most 
> people distribute code without checking it with such options.

Aha! Your point is about controlling the kind of code that people distribute.
The Automake target 'distcheck' is meant to control this. If you ask the
Automake people to consider an Automake option that will ensure that only C90
compliant C code is used, they might listen.

> I'm told /usr/local is "a standard" so I can expect problems if I chose 
> not to install things in /usr/local.

That answer was nonsense. The "standard" is that the options described in the
INSTALL file are honoured. The INSTALL file says that a --prefix option is
supported. There is a caveat, though, regarding the search paths (for include
files and for libraries); if you don't do anything special, you need to be
careful not to install any user packages with the same --prefix as you used
to configure gcc.

> One bug in particular, where gcc builds the stage one compiler, but fails to 
> build stage 2, has hit many people on Solaris. But despite numerous reports 
> of 
> this, the GCC developers refuse to acknowledge it as a bug. But it has caught 
> out so many people, one might hope they would try to resolve it.

Then maybe you should argue that it is a documentation bug, and try to submit
a documentation fix?

In summary, getting people to agree over policy is much harder than getting
a bug fixed by analyzing and reporting it.

Bruno