Potential bug in library search for libiconv in static build

2011-04-03 Thread gmail

Hello,

This is my first contact and mail with bash mailing list, to summarize 
i'm a coder maintening a personnal home server using several GNU tools 
since the late 90's.



I configure BASH-4.2.0 in a chroot jail (gcc 4.5.2/libc 2.13/binutils 
2.21/make 3.82) with an athlon architecture on ext3 FS with 
--enable-static-link --with-libiconv-prefix=/ and, as root,  and notice 
the configure script can't find the jail's static libiconv :


[root@pompomgalli] mkdir bash-4.2_static_build && cd 
bash-4.2_static_build


[root@pompomgalli] ../bash-4.2_static/configure --prefix=/ 
--without-bash-malloc --with-curses  --enable-static-link 
--with-libiconv-prefix=/


checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu

Beginning configuration for bash-4.2-release for i686-pc-linux-gnu

checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for strerror in -lcposix... no
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes



checking for ld used by GCC... /bin/ld
checking if the linker (/bin/ld) is GNU ld... yes
checking for shared library run path origin... done



checking for __argz_count... yes
checking for __argz_stringify... yes
checking for __argz_next... yes
checking for __fsetlocking... yes
checking for iconv... no, consider installing GNU libiconv
checking for nl_langinfo and CODESET... yes
checking for LC_MESSAGES... yes
checking for bison... bison
checking version of bison... 2.4.3, ok

 

[root@pompomgalli]




I then check if the libiconv library was accessible :





[root@pompomgalli] # ls -ld /lib/libiconv.* /lib

drwxr-xr-x 13 root root   12288 Apr  3 12:14 /lib
-rw-r--r-- 1 root root 1233398 Apr  3 12:14 /lib/libiconv.a
-rw-r--r-- 1 root root 917 Apr  3 12:14 /lib/libiconv.la
lrwxrwxrwx 1 root root  17 Apr  3 12:14 /lib/libiconv.so -> 
libiconv.so.2.5.0
lrwxrwxrwx 1 root root  17 Apr  3 12:14 /lib/libiconv.so.2 -> 
libiconv.so.2.5.0

-rw-r--r-- 1 root root 1191794 Apr  3 12:14 /lib/libiconv.so.2.5.0





Apparently, the static libiconv.a should had been seen by the configure 
script. I check then the config.log :






[root@pompomgalli] # less config.log

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by bash configure 4.2-release, which was
generated by GNU Autoconf 2.63.  Invocation command line was

  $ ../bash-4.2_static/configure --prefix=/ --without-bash-malloc 
--with-curses --enable-static-link --with-libiconv-prefix=/


## - ##
## Platform. ##
## - ##

hostname = pompomgalli
uname -m = i686
uname -r = 2.6.37.3-Zilog80
uname -s = Linux
uname -v = #15 Mon Mar 28 20:53:38 CEST 2011

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = i686
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: .
PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin
PATH: /usr/local/bin
PATH: /usr/local/sbin


## --- ##
## Core tests. ##
## --- ##

configure:2094: checking build system type
configure:2112: result: i686-pc-linux-gnu
configure:2134: checking host system type
configure:2149: result: i686-pc-linux-gnu
configure:2806: checking for gcc
configure:2833: result: gcc
configure:3065: checking for C compiler version
configure:3073: gcc --version >&5
gcc (GCC) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


configure:3077: $? = 0
configure:3084: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.5.2/lto-wrapper

Target: i686-pc-linux-gnu
Configured with: ../gcc-4.5.2/configure --enable-clocale=gnu 
--enable-threads=posix --enable-__cxa_atexit 
--enable-languages=c,c++,java --disable-libstdcxx-pch --prefix=/usr

Thread model: posix
gcc version 4.5.2 (GCC)
conf

bash decode prompt string broken for 'W'

2011-04-03 Thread Marty Pauley
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/shar
uname output: Linux gohan 2.6.37-2-amd64 #1 SMP Sun Feb 27 10:12:22
UTC 2011 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.1
Patch Level: 5
Release Status: release

Description:
The "\W" escape in the prompt is expanded incorrectly for some
directories.  The problem is caused by the use of strcpy with
overlapping strings; but strcpy has undefined behaviour when the
strings overlap.

Repeat-By:
Set PS1 to include the "\W" escape, then cd to /home or /media to see
the problem: "home" is displayed as "hmee" and "media" is displayed as
"meiia".  A transcript from my bash session is below:

bash-4.1$ PS1='\W$ '
~$ cd /home
hmee$ cd /media
meiia$ cd /etc
etc$ cd
~$ exit


Fix:
The patch below fixes the problem.

--- y.tab.c.orig2011-04-04 01:12:23.0 +0900
+++ y.tab.c 2011-04-04 01:19:48.0 +0900
@@ -7481,7 +7481,8 @@
  {
t = strrchr (t_string, '/');
if (t)
- strcpy (t_string, t + 1);
+ for ( temp = t_string; *t; temp++ )
+   *temp = *++t;
  }
  }
 #undef ROOT_PATH