m4-1.4.7 build feedback

[Nelson H. F. Beebe]

Yesterday, I completed builds of m4-1.4.7 in 114 build environments on
about 25 different Unix platforms with a variety of C and C++
compilers.  Of these, 100 were successful, and passed all of the
validation tests, and I have installed this version of m4 on each
system.

Of the 14 failures, most were compiler related, but I'll summarize
them anyway for the record.

============================================================
Machinetype:            Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM); 
FreeBSD 6.1-RELEASE #0
Configure environment:  CC=/usr/bin/c89 CFLAGS=-I/usr/local/include 
CXX=/usr/bin/g++

if /usr/bin/c89 -DHAVE_CONFIG_H -I. -I. -I..  -I../lib -I../lib   
-I/usr/local/include -MT m4.o -MD -MP -MF ".deps/m4.Tpo" -c -o m4.o m4.c; \
        then mv -f ".deps/m4.Tpo" ".deps/m4.Po"; else rm -f ".deps/m4.Tpo"; 
exit 1; fi
c89: illegal option -- M
usage: c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] ...
           [-o outfile] [-U name] ... operand ...

       where operand is one or more of file.c, file.o, file.a
       or -llibrary
make[2]: *** [m4.o] Error 1

This also happens with c99.  Their manual pages say

        NAME
             c89 -- POSIX.2 C language compiler

        SYNOPSIS
             c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L 
directory] ...
                 [-o outfile] [-U name] ... operand ...

        DESCRIPTION
             This is the name of the C language compiler as required by the 
IEEE Std
             1003.2 (``POSIX.2'') standard.

        NAME
             c99 -- standard C language compiler

        SYNOPSIS
             c99 [-cEgs] [-D name[=value]] ... [-I directory] ... [-L 
directory] ...
                 [-o outfile] [-O optlevel] [-U name] ... operand ...

        DESCRIPTION
             This is the name of the C language compiler as required by the 
IEEE Std
             1003.1-2001 (``POSIX.1'') standard.

They recognize only the very limited set of options show in the
synopses, but under the hood, they invoke /usr/bin/cc, which is
gcc 3.4.4.

Tests with c89 and c99 show that they define the symbol __GNUC__ to 3,
so configure concludes they are gcc:

        checking for gcc... /usr/bin/c89
        checking whether we are using the GNU C compiler... yes
        checking dependency style of /usr/bin/c89... gcc3

The src/Makefile has the rule

.c.o:
        if $(COMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ $<; \
        then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Po"; else rm -f 
"$(DEPDIR)/$*.Tpo"; exit 1; fi

but that fails because of the limited option repertoire of c89 and
c99.

It is probably not worth trying to fix this, although doing so would
likely enhance portability to a wider range of c89 and c99 compilers
on other systems.

========================================================================
Machinetype:            DEC Alpha 4100-5/466 (4 21164 EV5 CPUs, 466 MHz, 2GB 
RAM);          OSF/1 4.0F
Remote cc version:      DEC C V5.9-005 on Digital UNIX V4.0 (Rev. 1229)
Configure environment:  CC=cc CFLAGS="-ieee -I/usr/local/include" CXX=cxx 
CXXFLAGS="-ieee -I/usr/local/include" LDFLAGS="-Wl,-rpath,/usr/local/lib 
-Wl,-oldstyle_liblookup -L/usr/local/lib" LIBS="-lsnprintf" FC=f77 F77=f77

Checking ./108.format
@ ../doc/m4.texinfo:3779: Origin of test
./108.format: stdout mismatch
3c3
< 56790
---
> f
Skipped checks were:
  ./070.changeword ./071.changeword ./072.changeword ./073.changeword 
./074.changeword
Failed checks were:
  ./108.format:out
make[1]: Leaving directory `/export/home/0023/build-alpha-osf1/m4-1.4.7/checks'
make[1]: *** [check] Error 1

Here what happens when I run the newly-built m4 manually:

        % ./src/m4 ./checks/108.format

        The string "The brown fox jumped over the lazy dog" uses 38 characters
        f
        300

The problem statement in the test file is this one:

        format(`%.0f', `56789.9876')

I'm not sure why this outputs f instead of 56790.  m4 does not appear
to be using the printf() library function, because this test program
produces correct output:

        % cat fmtbug.c
        #include <stdio.h>
        #include <stdlib.h>

        int
        main(void)
        {
            printf("%.f\n", 56789.9876);
            printf("%.0f\n", 56789.9876);

            return (EXIT_SUCCESS);
        }

        %  cc fmtbug.c && ./a.out
        56790
        56790

For now, I've installed this version of m4.  I'm now rebuilding and
testing several earlier versions of m4 on this system to see if the
bug is present there as well.

========================================================================
Machinetype:            Intel Pentium 4 (2660 MHz);     GNU/Linux 
2.6.16-1.2133_FC5 (Fedora Core release 5 (Bordeaux))
Remote lsbcc version:   cc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
Configure environment:  CC=/opt/lsb/bin/lsbcc CXX=/opt/lsb/bin/lsbc++ 
LDFLAGS="-L/usr/local/lib -Wl,-rpath,/usr/local/lib" FC=gfortran F77=gfortran

/opt/lsb/bin/lsbcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c close-stream.c
In file included from __fpending.h:25,
                 from close-stream.c:27:
/usr/include/stdio_ext.h:47: error: expected `=', `,', `;', `asm' or 
`__attribute__' before `extern'
/usr/include/stdio_ext.h: In function `__freading':
....

Builds of software with the Linux Standards Base compiler, lsbcc, are
of considerable interest, because it makes possible binary portability
across a wide range of GNU/Linux distributions, and even other
operating systems, on the same platform, provided that they support
the LSB API.  Because m4 is a core utility on Unix, GNU, and POSIX
systems, it would be highly desirable to be able to build it in the
quite-constrained LSB environment.

See

        http://www.freestandards.org/en/LSB

for a description of LSB, and downloads: I used this one

        
http://ftp.freestandards.org/pub/lsb/bundles/released-3.1.0/sdk/lsb-sdk-3.1.0-4.i486.tar.gz

on the above system.   There are further comments about lsb here:

        http://www.math.utah.edu/faq/compilers/compilers.html

As an experiment, I did a "make clean", then edited config.h to
comment out the definition of HAVE_STDIO_EXT_H.  Then I did a "make"
to see whether the build would succeed.  It did not, because regex.h
uses size_t in typedef statements before it gets a definition from
<stddef.h>.  I fixed that by this simple change:

 % diff -c regex.h.~1~ regex.h
*** regex.h.~1~ Sat Sep 23 22:28:37 2006
--- regex.h     Tue Sep 26 08:14:23 2006
***************
*** 22,27 ****
--- 22,28 ----
  #define _REGEX_H 1

  #include <sys/types.h>
+ #include <stddef.h>

  /* Allow the use in C++ code.  */
  #ifdef __cplusplus

With that single change, a "make clean all check" run succeeded, and
all tests passed.

This fix seems definitely worthwhile to make in the m4 source code.

========================================================================
Machinetype:            Intel Pentium 4 (2660 MHz);     GNU/Linux 
2.6.16-1.2133_FC5 (Fedora Core release 5 (Bordeaux))
Remote c89 version:     gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
Remote suncc version:   cc: Sun C 5.9 Linux_i386 Build27_2 2006/08/02
Configure environment:  CC=/opt/sun/sunstudiomars/bin/sunc89 
CFLAGS=-I/usr/local/include CXX=/opt/sun/sunstudiomars/bin/sunCC 
CXXFLAGS=-I/usr/local/include LDFLAGS="-R/usr/local/lib -L/usr/local/lib"

/opt/sun/sunstudiomars/bin/sunc89 -DHAVE_CONFIG_H -I. -I. -I..     
-I/usr/local/include -c verror.c
"verror.h", line 36: warning: attribute parameter "printf" is undefined
"verror.h", line 48: warning: attribute parameter "printf" is undefined
"/usr/include/stdlib.h", line 712: syntax error before or at: _Pragma
c89: acomp failed for verror.c
make[3]: Leaving directory `/local/build/sunc89/m4-1.4.7/lib'

This build is with the new free Sun compilers ported from GNU/Linux to
Solaris.  Here is some information from a posting that I made to
another mailing list on 15-Sep-2006:

>> ...
>>      More details can be found here:
>>
>>         http://developers.sun.com/prodtech/cc/downloads/express.jsp
>>         http://developers.sun.com/prodtech/cc/downloads/express_readme.html
>>
>> PS-1:   The only personal information required to download the compilers is
>>         your email address.
>>
>> PS-2:   A word of warning for installers and systems managers: in
>>         previous releases, the Sun compiler suite on GNU/Linux
>>         unbundled into /opt/sun only.
>>
>>         In this new release, it also creates two other trees: /db and
>>         /usr/OpenMotif-2.1.31.  Neither exists in standard GNU/Linux
>>         installations, so there is no conflict with existing files.
>>
>>         I had to manually propagate those two extra directories to our
>>         many client machines that otherwise get /opt and /usr/local
>>         mirrored nightly from master servers.
>>
>>         Here are the disk space requirements:
>>
>>                 % du -skh /opt/sun /db /usr/OpenMotif-2.1.31/
>>                 1001M   /opt/sun
>>                 4.3M    /db
>>                 20M     /usr/OpenMotif-2.1.31/
>>
>> PS-3:   For some reason, the compiler manual pages are not included in
>>         the GNU/Linux distribution, but they can be found online at
>>
>>                 
>> http://developers.sun.com/prodtech/cc/documentation/ss11/index.html
>> ...

/opt/sun/sunstudiomars/bin/sunc89 -DHAVE_CONFIG_H -I. -I. -I..     
-I/usr/local/include -c verror.c
"verror.h", line 36: warning: attribute parameter "printf" is undefined
"verror.h", line 48: warning: attribute parameter "printf" is undefined
"/usr/include/stdlib.h", line 712: syntax error before or at: _Pragma
c89: acomp failed for verror.c

m4-1.4.7 compiles without problems with suncc and sunc99, and passes
its validation tests.

Nothing needs to be done here, but I thought is useful to report the
availability of these free compilers, because they have two decades of
development behind them on SPARC, and have proved highly reliable.
The IA-32 and AMD64 code generators are relatively new, and the most
recent release for GNU/Linux has these improvements from the same
posting cited above:

>> ...
>> In addition to the support for more platforms, the compilers now
>> recognize several gcc-specific features, including -m32 and -m64 to
>> set the memory-addressing model, -xMD, -xMF, and -xMMD to generate
>> Makefile dependencies, #include_next, and the __attributes__
>> qualifier.  The compilers now have aliases with the prefix "sun":
>> suncc, sunCC, sunf90, sunf77, sunf95, sunc89, sunc99, and sunas,
>> making it easy for them to coexist in the standard search path without
>> shadowing the vendor-provided compilers in /usr/bin.
>>
>> These changes should make the Sun compilers work much better in a
>> GNU/Linux environment, and I have been routinely using them in
>> software builds in several different compilation environments on
>> GNU/Linux systems on IA-32 and AMD64 CPUs, using the automated build
>> tool described in Chapter 8 of our book ``Classic Shell Scripting'':
>>
>>         http://www.math.utah.edu/~beebe/books/css
>>
>> If GNU/Linux compatibility support is installed on FreeBSD, NetBSD,
>> and OpenBSD systems (see "man compat_linux" on those system for
>> details), it should be possible to run the Sun compilers on those
>> operating systems as well.  While I plan to make such experiments,
>> I have yet to do.
>>
>> If a similar compatibility layer ever gets added to Apple Mac OS X on
>> their new Intel-based products, then those systems as well may be able
>> to run the Sun compilers in the future.
>> ...

========================================================================

A build on GNU/Linux IA-32 with the Portland Group compilers, pgcc and
pgCC, version 5.1-3, compilation failed because INT_MAX is not
defined. This same compiler header file error has foiled the builds of
numerous other packages.  However, a build on another system with the
newer 6.2-3 release of these compilers succeeded, and passed all of
the validation tests.

Finally, problems that I found with the latest PathScale compiler
release 2.5 have produced two bug reports to the vendor: one is a
missing library symbol, and the other is a code generation error that
causes a core dump in the 108.format test (curiously, the same one
that gives incorrect output on the DEC Alpha OSF/1 system).

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: address@hidden  -
- 155 S 1400 E RM 233                       address@hidden  address@hidden -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------