Re: [bug-gnu-libiconv] Attempting to compile configure libiconv with only c99

[address@hidden]

> On January 10, 2016 at 12:28 PM "Randall S. Becker"
> <address@hidden> wrote:
> > Daiki Ueno writes:
> > > "Randall S. Becker" <address@hidden> writes:
> > > This may or may not be a defect, but I need some help. I am trying
> > > to
> > > build libiconv (1.14) on an HPE NonStop server that has c89 and
> > > c99;
> > > neither of which support the GCC extension #include_next, and
> > > porting
> > > GCC is not an option. This seems to be more an issue in libcharset
> > > and
> > > srclib that are on the tarball. There does not seem to be an
> > > option
> > > documented (or support for) in configure to use standard
> > > mechanisms
> > > for resolving #include loops. Does a recipe exist for building on
> > > this
> > > type of system? I need to change config.sub to support the
> > > platform
> > > regardless, so options there are available - if that helps. The
> > > bug
> > > seems to be that libiconv will only build on systems supporting
> > > the
> > extension, is that the case now?
> > 
> > According to the documentation of the 'include_next' module in
> > Gnulib
> (used
> > by libiconv), #include_next is only used when the compiler supports
> > it,
> > otherwise #include is used.  See:
> > http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/include_next.m4
> > 
> > If it doesn't work on your system, I would suggest to report it to
> > bug-
> > address@hidden, with the logs (including config.log) and the changes
> > you
> > made in config.sub.
> 
> The situation is that our c99 compiler properly reports that
> #include_next
> is not a known preprocessor directive, but that does not translate
> into a
> non-zero completion code - changing that behaviour is not likely not
> going
> to be a viable option. The test done by configure is insufficient to
> detect
> this.  ...

Randall, it is good to see another UNIX(tm) person around that lives in
a tightly standardized world where software must be portable and must be
compliant with reasonable specifications. At the very least software
needs to be C99 spec clean and who knows, perhaps someday when the 
compilers exist we will move onwards to C11. For now we should need at
least ISO/IEC 9899:1999 compliance.  I don't live in the GNU world where
nearly anything goes and it often does.  That isn't really fair because
a truely massive amount of work is done by amazingly qualified people to
release great software to an often thankless open source world. I feel
that programmers in the open source world are the scribes of the future
who will one day be seen in the same light as the monastic scribes that
wrote endless volumes into a consistent well formed language with very
clear rules on punctuation, word spacing and visual format.  However the
internet changes everything in the past few decades and now we have an
uncontrolled horde pouring out code in whatever seems to work. For them.
More often than not this is on Linux and the compiler is GCC and we all
should know that the GCC compiler is not ( yet ) compliant with a tight
international specification such as C99. 

The GCC compiler is a thing of beauty in the open source world and I 
have been building and porting is over to the tightly controlled Solaris
UNIX world since the 2.5.1 days in the mid 1990's.  It works well and 
the C99 spec[1] compliance within GCC is "substantially complete" but it
isn't there.  Not yet.[2]  Real close however.

So here you are working within a tightly constrained environment with a
compiler that is entirely compliant with the specifications. I work with
systems that are entirely within POSIX.1-2001 and SUSv3 and not much is
allowed into my production datacenter which lay outside of strict rules.
Sure, there are web sites running Apache and they have support for PHP
and other things in the "front end".  The bits that the user may see in
a browser out there somewhere. However the back end production world is
a tightly controlled world.  Not open to GNU C de-facto standards which
most of the scribes out there are living in. IT is a tough world to be
sure and here you are stuck in it.

Your HPE NonStop server has a tightly compliant C99 compiler in much the
same way that my Solaris servers have Oracle Studio 12.4.  Total and 
complete C99 compliance can be easily enforced with the flip of a flag.
Looking at libiconv-1.14 there seems to be no major problems over here
in the Solaris UNIX world with the Oracle Studio 12.4 compilers and yes
I am using CC=/opt/solarisstudio12.4/bin/c99 and the -Xc strict flag as 
well as defines -D_TS_ERRNO and -D_POSIX_PTHREAD_SEMANTICS.

I just extracted the source tarball ( again ) for libiconv-1.14 and ran
a dirt simple configure like so : 

$ ./configure --prefix=/usr/local --enable-dependency-tracking \
> --without-libiconv-prefix --without-libintl-prefix

The compiler and CFLAGS being used are : 


$ echo $CC
/opt/solarisstudio12.4/bin/c99

$ echo $CFLAGS 
-m64 -xtarget=ultra2e -xcache=16/32/1:256/64/1 -errfmt=error
-erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE

You can surf the Oracle Studio documentation to see that these flags
enforce strict compliance with the C99 standard and really, there is not
room for conjecture or debate here.  What I am saying is that the source
for libiconv-1.14 compiles fine here with the Oracle Studio 12.4 C99 
compiler. The only problem I run into is within the testsuite wherein I
hit "something" odd and I see : 

./check-stateless . EUC-KR
./check-stateless . CP949
./check-stateless . JOHAB
./check-stateful . ISO-2022-KR
/usr/local/bin/gmake check-extra
make[2]: Entering directory
`/usr/local/build/libiconv-1.14_SunOS5.10_sparcv9.002/tests'
make[2]: Nothing to be done for `check-extra'.
make[2]: Leaving directory
`/usr/local/build/libiconv-1.14_SunOS5.10_sparcv9.002/tests'
./check-translit . Quotes UTF-8 ISO-8859-1
./check-translit . Quotes UTF-8 ASCII
./check-translit . Translit1 ISO-8859-1 ASCII
./check-translitfailure . TranslitFail1 ISO-8859-1 ASCII
./check-subst
make[1]: *** [check] Error 139
make[1]: Leaving directory
`/usr/local/build/libiconv-1.14_SunOS5.10_sparcv9.002/tests'
make: *** [check] Error 2

I don't know what happened there, yet, but it is in the testsuite and
not the codebase so it worries me very little.  I am not sure what is
happening in the HPE NonStop world with your C99 compiler but over here
in the seriously pedantic and strict Solaris UNIX world everything
compiles fine.  So libiconv is cool
and the code is good. Not sure why you are using gnulib at all and the
problems seem to be there. I don't see gnulib as a need.

I hate to say this but are you sure about that compiler and gnulib ?

You really can do a build of GCC there and get excellent results. If you
are willing to make the effort. There are some hard dependencies for the
GCC 5.x compiler and perhaps the 4.9.x compiler would be more easy to 
bootstrap first. 

In summary, I suspect your compiler is being more pedantic than required
and perhaps it is unable to figure out what to do with the gnulib source
code but the libiconv code is just fine by my stringent tests. 

Dennis 



[1] The following 552 page PDF is the current C99 
       ISO/IEC 9899:TC3 International Standard  :

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

    Scope : 

        This International Standard specifies the form and establishes
        the interpretation of programs written in the C programming
        language.

        It specifies : 

        — the representation of C programs;
        — the syntax and constraints of the C language;
        — the semantic rules for interpreting C programs;
        — the representation of input data to be processed
           by C programs;
        — the representation of output data produced
           by C programs;
        — the restrictions and limits imposed by a conforming 
           implementation of C.


[2] https://gcc.gnu.org/c99status.html