Re: configure fails with gcc 4.6.0 LTO
On Sat, Mar 19, 2011 at 09:52:05PM +, Zeev Tarantov wrote: > configure:3122: checking for C compiler default output file name > configure:3144: x86_64-pc-linux-gnu-gcc -g -O2 -flto > -DDEFAULT_PATH_VALUE='"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"' > -DSTANDARD_UTILS_PATH='"/bin:/usr/bin:/sbin:/usr/sbin"' > -DSYS_BASHRC='"/etc/bash/bashrc"' > -DSYS_BASH_LOGOUT='"/etc/bash/bash_logout"' > -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -Wl,-flto > conftest.c >&5 > x86_64-pc-linux-gnu-gcc: error: \: No such file or directory > x86_64-pc-linux-gnu-gcc: error: \: No such file or directory > x86_64-pc-linux-gnu-gcc: error: \: No such file or directory > x86_64-pc-linux-gnu-gcc: error: \: No such file or directory > lto-wrapper: > /usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0-pre/x86_64-pc-linux-gnu-gcc > returned 1 exit status I'm not sure how much of the distortion we're seeing here is being caused by a mail user agent, versus how much is caused by the experimental gcc he's using, etc. My guess, without knowing anything about this version of gcc, is that the command that ./configure is supposed to execute is really something like: x86_64-pc-linux-gnu-gcc -g -O2 -flto \ -DDEFAULT_PATH_VALUE='"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"' \ -DSTANDARD_UTILS_PATH='"/bin:/usr/bin:/sbin:/usr/sbin"' \ and so on, where the backslashes are supposed to be at the ends of the lines, to indicate continuation. And somewhere along the way, they're being doubled so that they're becoming literal words. imadev:/tmp$ /net/appl/gcc-3.3/bin/gcc -g -O2 -DFOO=BAR \\ -DQWERTY=UIOP \\ hello.c gcc: \: No such file or directory gcc: \: No such file or directory Kinda like that. Maybe it's gcc 4.6-prewhatever that's doing it. Maybe he's actually using some sort of "build system wrapper" that's broken. I don't know. I just recognize the symptom, not the cause.
trap problem on bash 4.2
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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include
-I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux fedora14 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec
23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 4.2
Patch Level: 8
Release Status: release
Description:
I am a programmer working in Japan.
I encountered an incompatibility between bash 4.2 and 4.1.
--- cut here ---
#!/bin/bash
# tset_trap.bash
RESET_SIGTERM="$1"
subshell() {
ID1=$BASH_SUBSHELL
if [ -n "$RESET_SIGTERM" ] ; then
#trap "" SIGTERM### workaround
trap - SIGTERM ### doubt
echo "reset SIGTERM"
fi
( # exec subshell
SELF_PID=$!
[ -n "$BASHPID" ] && SELF_PID=$BASHPID
local -a p=(`head -1 /proc/$SELF_PID/stat`)
PARENT=${p[3]}
ID2=$BASH_SUBSHELL
echo "ROOT=$ROOT_PID SUB${ID1}=$PARENT SUB${ID2}=$SELF_PID"
grep -H SigIgn /proc/$PARENT/status
grep -H SigIgn /proc/$SELF_PID/status
pstree -p $ROOT_PID
) &
wait
}
ROOT_PID=$$
trap "" SIGTERM
grep -H SigIgn /proc/$ROOT_PID/status
subshell | gawk '{printf("%s %s\n", strftime("%F %T"), $0) ; fflush()}' &
trap - SIGTERM
wait
Repeat-By:
Please run 'test_trap.bash' .
The next is a result on bash 4.2.
# rpm -q bash
bash-4.2.8-1.fc15.x86_64
# ./test_trap.bash 1
/proc/5399/status:SigIgn: 4004
2011-03-21 21:16:15 reset SIGTERM
2011-03-21 21:16:15 ROOT=5399 SUB1=5401 SUB2=5403
2011-03-21 21:16:15 /proc/5401/status:SigIgn: 4006
2011-03-21 21:16:15 /proc/5403/status:SigIgn: 4006
2011-03-21 21:16:15 test_trap.bash(5399)-+-gawk(5402)
2011-03-21 21:16:15
`-test_trap.bash(5401)---test_trap.bash(5403)---pstree(5407)
We can not reset SIGTERM in subshell.
On bash 4.1 or older version, we can reset it.
The next is a result on bash 4.1.
# rpm -q bash
bash-4.1.7-3.fc14.x86_64
# ./test_trap.bash 1
/proc/5634/status:SigIgn: 4004
2011-03-21 21:24:07 reset SIGTERM
2011-03-21 21:24:07 ROOT=5634 SUB1=5636 SUB2=5638
2011-03-21 21:24:07 /proc/5636/status:SigIgn: 0006
2011-03-21 21:24:07 /proc/5638/status:SigIgn: 0006
2011-03-21 21:24:07 test_trap.bash(5634)-+-gawk(5637)
2011-03-21 21:24:07
`-test_trap.bash(5636)---test_trap.bash(5638)---pstree(5642)
On Linux, we can see signal mask in /proc//status.
Best Regards,
s-taka (Satoshi Takahashi)
Re: configure fails with gcc 4.6.0 LTO
On Mon, Mar 21, 2011 at 8:32 AM, Greg Wooledge wrote: > On Sat, Mar 19, 2011 at 09:52:05PM +, Zeev Tarantov wrote: >> configure:3122: checking for C compiler default output file name >> configure:3144: x86_64-pc-linux-gnu-gcc -g -O2 -flto >> -DDEFAULT_PATH_VALUE='"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"' >> -DSTANDARD_UTILS_PATH='"/bin:/usr/bin:/sbin:/usr/sbin"' >> -DSYS_BASHRC='"/etc/bash/bashrc"' >> -DSYS_BASH_LOGOUT='"/etc/bash/bash_logout"' >> -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -Wl,-flto >> conftest.c >&5 >> x86_64-pc-linux-gnu-gcc: error: \: No such file or directory >> x86_64-pc-linux-gnu-gcc: error: \: No such file or directory >> x86_64-pc-linux-gnu-gcc: error: \: No such file or directory >> x86_64-pc-linux-gnu-gcc: error: \: No such file or directory >> lto-wrapper: >> /usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0-pre/x86_64-pc-linux-gnu-gcc >> returned 1 exit status > > I'm not sure how much of the distortion we're seeing here is being > caused by a mail user agent, versus how much is caused by the experimental > gcc he's using, etc. > > My guess, without knowing anything about this version of gcc, is that > the command that ./configure is supposed to execute is really something > like: > > x86_64-pc-linux-gnu-gcc -g -O2 -flto \ > -DDEFAULT_PATH_VALUE='"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"' > \ > -DSTANDARD_UTILS_PATH='"/bin:/usr/bin:/sbin:/usr/sbin"' \ > > and so on, where the backslashes are supposed to be at the ends of the > lines, to indicate continuation. And somewhere along the way, they're > being doubled so that they're becoming literal words. > > imadev:/tmp$ /net/appl/gcc-3.3/bin/gcc -g -O2 -DFOO=BAR \\ -DQWERTY=UIOP \\ > hello.c > gcc: \: No such file or directory > gcc: \: No such file or directory > > Kinda like that. > > Maybe it's gcc 4.6-prewhatever that's doing it. Maybe he's actually using > some sort of "build system wrapper" that's broken. I don't know. I just > recognize the symptom, not the cause. the Gentoo ebuild double quotes the flags in env CPPFLAGS so that gcc sets the strings correctly when compiling. the failure only happens when LDFLAGS contains -flto which says to me that gcc doesnt parse arguments the same as when executing other helpers. LDFLAGS=-flto CPPFLAGS=-DD=\'\"\"\' ./configure but still not a bash issue -mike
Bash truncates HISTFILE when disk is full
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux dragonfly 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:29 UTC 2011 i686 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.1 Patch Level: 5 Release Status: release Description: Bash truncates HISTFILE (~/.bash_history) to zero bytes when the filesystem is full. Repeat-By: Use bash with a full HISTFILE (ie, one that has HISTFILESIZE lines in it) and a full disk. The HISTFILE is empty afterwords. Long, drawn out, concrete example including making a new test user with a home directory on a separate filesystem so it can be easily and harmlessly filled up: $ # Create a new user with a home dir on a small temporary filesystem $ sudo adduser bashbug Adding user `bashbug' ... Adding new group `bashbug' (1002) ... Adding new user `bashbug' (1002) with group `bashbug' ... Creating home directory `/home/bashbug' ... Copying files from `/etc/skel' ... Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully Changing the user information for bashbug Enter the new value, or press ENTER for the default Full Name []: Room Number []: Work Phone []: Home Phone []: Other []: Is the information correct? [Y/n] $ dd if=/dev/zero of=/dev/shm/bashbug-home bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0.0332525 s, 315 MB/s $ mke2fs /dev/shm/bashbug-home mke2fs 1.41.12 (17-May-2010) /dev/shm/bashbug-home is not a block special device. Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) Stride=0 blocks, Stripe width=0 blocks 2560 inodes, 10240 blocks 512 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=10485760 2 block groups 8192 blocks per group, 8192 fragments per group 1280 inodes per group Superblock backups stored on blocks: 8193 Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 31 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. $ sudo mount -o loop /dev/shm/bashbug-home /dev/shm/bashbug-home-mnt $ sudo mv -v /home/bashbug/* /home/bashbug/.??* /dev/shm/bashbug-home-mnt/ `/home/bashbug/examples.desktop' -> `/dev/shm/bashbug-home-mnt/examples.desktop' removed `/home/bashbug/examples.desktop' `/home/bashbug/.bash_logout' -> `/dev/shm/bashbug-home-mnt/.bash_logout' removed `/home/bashbug/.bash_logout' `/home/bashbug/.bashrc' -> `/dev/shm/bashbug-home-mnt/.bashrc' removed `/home/bashbug/.bashrc' `/home/bashbug/.profile' -> `/dev/shm/bashbug-home-mnt/.profile' removed `/home/bashbug/.profile' $ sudo chown bashbug:bashbug /dev/shm/bashbug-home-mnt $ sudo umount /dev/shm/bashbug-home-mnt $ sudo mount -o loop /dev/shm/bashbug-home /home/bashbug $ df Filesystem 1K-blocks Used Available Use% Mounted on ... /dev/loop0991199 9300 2% /home/bashbug $ $ $ $ $ # Fill up .bash_history and let bash trim it to HISTFILESIZE $ sudo -u bashbug -i bashbug$ yes | head -n 3000 > .bash_history bashbug$ echo $HISTFILE $HISTSIZE $HISTFILESIZE # The defaults /home/bashbug/.bash_history 1000 2000 bashbug$ wc -l .bash_history 3000 .bash_history bashbug$ logout $ wc -l /home/bashbug/.bash_history 2000 /home/bashbug/.bash_history $ $ $ $ $ # Fill up the filesystem $ sudo bash -c 'yes > /home/bashbug/full' yes: standard output: No space left on device yes: write error $ $ $ $ $ # On next use, .bash_history becomes empty: $ sudo -u bashbug -i bashbug$ whoami # Any command bashbug bashbug$ logout $ ls -l /home/bashbug/.bash_history -rw-r--r-- 1 bashbug bashbug 0 2011-03-20 17:08 /home/bashbug/.bash_history Fix: Bash should write out the new HISTFILE before destro
