I was pleased to see the announcement of bash-3.1 last week, and I
have now done installations on about 20 flavors of Unix, after getting
readline-5.1 in place first.
Most of the builds were problem free, but I have a few issues to
report.
------------------------------------------------------------------------
Machinetype: Intel Pentium III (600 MHz); NetBSD 1.6 (GENERIC)
Remote gcc version: gcc (GCC) 3.4.3
Remote g++ version: g++ (GCC) 3.4.3
Configure environment: CC=gcc CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib
...
checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
...
gcc -c -DHAVE_CONFIG_H -DSHELL -I/usr/local/include -I. -I../.. -I../..
-I../../include -I../../lib -g -O2 smatch.c
smatch.c: In function `is_wcclass':
smatch.c:299: error: `wctype_t' undeclared (first use in this function)
configure, and the code in smatch.c, concluded that since wctype.h was
present, wctype_t must be too, but that assumption is patently false
on NetBSD 1.6, which has no support at all for that type:
% find /usr/include -name '*.h' | xargs grep wctype
/usr/include/g++/std/straits.h:#include <cwctype>
/usr/include/wctype.h:/* $NetBSD: wctype.h,v 1.4 2001/01/20
17:40:09 itojun Exp $ */
/usr/include/wctype.h: * citrus Id: wctype.h,v 1.4 2000/12/21
01:50:21 itojun Exp
I manually edited config.h:
% diff config.h.~1~ config.h
907c907
< #define HAVE_WCTYPE_H 1
---
> /* #define HAVE_WCTYPE_H 1 */
then removed all *.o files and restarted the "make all check". It
succeeded and I can now exhibit this happy result:"
% bash --version
GNU bash, version 3.1.0(1)-release (i386-unknown-netbsdelf1.6)
Copyright (C) 2005 Free Software Foundation, Inc.
------------------------------------------------------------------------
Machinetype: Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM);
GNU/Linux Red Hat Enterprise Linux AS 4
Remote gcc version: gcc (GCC) 3.3.5
Remote g++ version: g++ (GCC) 3.3.5
Configure environment: CC=gcc CFLAGS=-m32 CXX=g++ CXXFLAGS=-m32
LDFLAGS="-Wl,-rpath,/usr/local/lib"
...
gcc -Wl,-rpath,/usr/local/lib -rdynamic -m32 -o mkbuiltins mkbuiltins.o -ldl
/usr/bin/ld: warning: i386:x86-64 architecture of input file `mkbuiltins.o' is
incompatible with i386 output
./mkbuiltins -externfile builtext.h -structfile builtins.c \
-noproduction -D . ./alias.def ./bind.def ./break.def ./builtin.def
./caller.def ./cd.def ./colon.def ./command.def ./declare.def ./echo.def
./enable.def ./eval.def ./getopts.def ./exec.def ./exit.def ./fc.def
./fg_bg.def ./hash.def ./help.def ./history.def ./jobs.def ./kill.def ./let.def
./read.def ./return.def ./set.def ./setattr.def ./shift.def ./source.def
./suspend.def ./test.def ./times.def ./trap.def ./type.def ./ulimit.def
./umask.def ./wait.def ./reserved.def ./pushd.def ./shopt.def ./printf.def
./complete.def
make[1]: *** [builtext.h] Segmentation fault (core dumped)
This was an attempt to build a 32-bit version of bash on the
64-bit/32-bit AMD64.
Since the 64-bit build succeeded, I used that one. However, it would
be nice for the 32-bit one to work as well: we are experimenting to
see whether the AMD64 could be used as a build master for 32-bit IA-32
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 -lc" FC=f77 F77=f77
cc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"alphaev56"' -DCONF_OSTYPE='"osf4.0f"'
-DCONF_MACHTYPE='"alphaev56-dec-osf4.0f"' -DCONF_VENDOR='"dec"'
-DLOCALEDIR='"/usr/local/share/locale"' -DPACKAGE='"bash"' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -o bashversion
./support/bashversion.c buildversion.o
ld:
Unresolved:
snprintf
The problem here is that the Makefile command line for building
bashversion is missing $(LIBS). OSF/1 is the only one of my 20+
flavors of Unix that lacks snprintf(), but I have it available in a
local library that the configure-time LIBS flag supplied.
------------------------------------------------------------------------
Machinetype: Sun Ultra Enterprise 450/400 (4 UltraSPARC-II CPUs, 400
MHz); Solaris 7
Remote cc version: cc: WorkShop Compilers 5.0 98/12/15 C 5.0
Configure environment: CC=cc CFLAGS=-I/usr/local/include CXX=CC
CXXFLAGS=-I/usr/local/include LDFLAGS="-R/usr/local/lib -L/usr/local/lib"
cc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"sparc"' -DCONF_OSTYPE='"solaris2.7"'
-DCONF_MACHTYPE='"sparc-sun-solaris2.7"' -DCONF_VENDOR='"sun"'
-DLOCALEDIR='"/usr/local/share/locale"' -DPACKAGE='"bash"' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I/usr/local/include
-I/usr/local/include -c subst.c
...
"subst.c", line 1778: integral constant expression expected
"subst.c", line 1819: integral constant expression expected
...
cc: acomp failed for subst.c
make: *** [subst.o] Error 2
I was able to build and install bash-3.1 on this system with gcc
2.95.3, so the failure with the native compilers is not a show
stopper. This is a fairly old system in any event, and will be
retired in the next few months.
However, similar errors happened with native cc on Solaris 10, and are
explained further below.
------------------------------------------------------------------------
Machinetype: Compaq AlphaServer ES40 Sierra/667 (32 EV6.7 21264A
CPUs, 667 MHz, 8GB RAM); OSF/1 5.1
Remote c89 version: Compaq C V6.3-028 on Compaq Tru64 UNIX V5.1 (Rev. 732)
Configure environment: CC=c89 CFLAGS="-ieee -I$HOME/alpha/local/include"
CXX=cxx CXXFLAGS="-ieee -I$HOME/alpha/local/include"
LDFLAGS="-L$HOME/alpha/local/lib -Wl,-rpath,$HOME/alpha/local/lib
-Wl,-oldstyle_liblookup"
c89 -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"alphaev67"' -DCONF_OSTYPE='"osf5.1"'
-DCONF_MACHTYPE='"alphaev67-dec-osf5.1"' -DCONF_VENDOR='"dec"'
-DLOCALEDIR='"/uufs/inscc.utah.edu/common/home/mthnhb/alpha/local/share/locale"'
-DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib
-I/uufs/inscc.utah.edu/common/home/mthnhb/alpha/local/include -ieee
-I/uufs/inscc.utah.edu/common/home/mthnhb/alpha/local/include -c subst.c
cc: Error: subst.c, line 1778: In the declaration of "sep",
"__getmbcurmax(...)" is not constant, but occurs in a context that requires a
constant expression. (needconstexpr)
char sep[MB_CUR_MAX + 1];
-----------^
cc: Error: subst.c, line 1819: In the declaration of "sep",
"__getmbcurmax(...)" is not constant, but occurs in a context that requires a
constant expression. (needconstexpr)
char sep[MB_CUR_MAX + 1];
-----------^
This is the same source code that raised errors with the Solaris 7 and
10 native compilers, and the fix is probably easy.
On Solaris 7, I find
% grep MB_CUR_MAX /usr/include/*.h
/usr/include/stdlib.h:#define MB_CUR_MAX __ctype[520]
/usr/include/stdlib.h:#define MB_CUR_MAX _ctype[520]
On Solaris 10, I find
% grep MB_CUR_MAX /usr/include/*/*.h
/usr/include/X11/XlcPubI.h: int mb_cur_max; /* ANSI
C MB_CUR_MAX */
/usr/include/Xm/XmosP.h:#include <stdlib.h> /* Needed for MB_CUR_MAX,
mbtowc, mbstowcs and mblen */
/usr/include/Xm/XmosP.h:#undef MB_CUR_MAX
/usr/include/Xm/XmosP.h:#define MB_CUR_MAX 1 /* temp fix for ultrix */
/usr/include/Xm/XmosP.h:#include <stdlib.h> /* Needed for MB_CUR_MAX,
mbtowc, mbstowcs and mblen */
/usr/include/Xm/XmosP.h:#undef MB_CUR_MAX
/usr/include/Xm/XmosP.h:#define MB_CUR_MAX 1 /* temp fix for ultrix */
/usr/include/iso/stdlib_iso.h:#define MB_CUR_MAX __ctype[520]
/usr/include/iso/stdlib_iso.h:#define MB_CUR_MAX _ctype[520]
On OSF/1 5.1, I find
% grep MB_CUR_MAX /usr/include/*.h
/usr/include/stdlib.h:#define MB_CUR_MAX __getmbcurmax() /* max
bytes in multibyte char */
The text of the 1999 ISO C Standard says:
>> ...
>> MB_CUR_MAX
>>
>> which expands to a positive integer expression with type
>> size_t that is the maximum number of bytes in a multibyte
>> character for the extended character set specified by the
>> current locale (category LC_CTYPE), which is never greater
>> than MB_LEN_MAX.
>> ...
Since it does not say CONSTANT integer expression, and the 1989 ISO C
Standard has similar wording, the three systems are standard
conforming, and the bash code is wrong to assume that MB_CUR_MAX can
be used as an array dimension.
I was able to get a successful build of bash-3.1 with gcc on OSF/1 5.1.
------------------------------------------------------------------------
-------------------------------------------------------------------------------
- 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: [EMAIL PROTECTED] -
- 155 S 1400 E RM 233 [EMAIL PROTECTED] [EMAIL
PROTECTED] -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
