bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45165: binutils-mesboot0 fails at configure, cannot find lex


From: Carl Dong
Subject: bug#45165: binutils-mesboot0 fails at configure, cannot find lex
Date: Wed, 16 Dec 2020 12:49:45 -0500

More clues:

I ran the following one-liner:

for i in $(seq 0 65535); do sudo chown $i:$i 
/tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14/config.cache && 
/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh -c "test 
-w /tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14/config.cache" && 
echo "Winner: $i" && break; done

This is designed to iterate through all possible uid values, chown the 
config.cache file, and test if that uid makes the “test” builtin think that it 
is writable. If there is one, it’ll print “Winner: <uid>” and exit

The result: Nothing was printed and the exit status was 1

Not sure where to go from here.

Cheers,
Carl Dong

> On Dec 15, 2020, at 7:46 PM, Carl Dong <contact@carldong.me> wrote:
> 
> Hi all,
> 
> I think I have a new lead!
> 
> Here’s what I did:
> 1. cd /tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14
> 2. env -i bash --rcfile environment-variables
> 3. Ran the configure command from the log, just to check:
>       ./configure --disable-nls --disable-shared --disable-werror 
> --build=i386-unknown-linux --host=i386-unknown-linux 
> --target=i386-unknown-linux --with-sysroot=/ 
> --prefix=/gnu/store/jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14
> 
> Indeed it did still output "not updating unwritable cache ./config.cache”
> 
> However, when I tried `test -w config.cache`, there was no status code…
> 
> This led me to look at ./configure’s shebang, which is:
>       /gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh
> 
> Then I did:
>       /gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh 
> -c "test -w config.cache”
> 
> Which _did_ exit with status=1 !
> 
> So I believe that this is a problem with the “test” builtin in 
> /gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b
> 
> So I ran:
>       env -i bash --rcfile environment-variables -c 'strace -v -e trace=file 
> /gnu/store/m89p469fxwn4hj7an9givd1ry 9vk7j2l-bash-mesboot0-2.05b/bin/sh -c 
> "test -w config.cache”'
> 
> And the output:
> execve("/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh",
>  ["/gnu/store/m89p469fxwn4hj7an9giv"..., "-c", "test -w config.cache"], 
> ["PWD=/tmp/guix-build-binutils-mes"..., "SHLVL=0", "_=/usr/bin/strace"]) = 0
> [ Process PID=2049037 runs in 32 bit mode. ]
> open("/dev/tty", O_RDWR)                = 3
> stat("/tmp/guix-build-binutils-mesboot0-2.14.drv-0", {st_dev=makedev(0, 
> 0x2f), st_ino=2546749, st_mode=S_IFDIR|0755, st_nlink=3, st_uid=1000, 
> st_gid=1000, st_blksize=4096, st_blocks=0, st_size=80, st_atime=1608079054 /* 
> 2020-12-15T19:37:34.095396729-0500 */, st_atime_nsec=95396729, 
> st_mtime=1607635957 /* 2020-12-10T16:32:37.842047431-0500 */, 
> st_mtime_nsec=842047431, st_ctime=1607636165 /* 
> 2020-12-10T16:36:05.793930344-0500 */, st_ctime_nsec=793930344}) = 0
> stat(".", {st_dev=makedev(0, 0x2f), st_ino=2546749, st_mode=S_IFDIR|0755, 
> st_nlink=3, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=0, 
> st_size=80, st_atime=1608079054 /* 2020-12-15T19:37:34.095396729-0500 */, 
> st_atime_nsec=95396729, st_mtime=1607635957 /* 
> 2020-12-10T16:32:37.842047431-0500 */, st_mtime_nsec=842047431, 
> st_ctime=1607636165 /* 2020-12-10T16:36:05.793930344-0500 */, 
> st_ctime_nsec=793930344}) = 0
> stat("config.cache", 0xfff9affc)        = -1 ENOENT (No such file or 
> directory)
> +++ exited with 1 +++
> 
> I had a hunch that the mode is most likely the problem. So I tried the 
> following:
> 
> chmod 664 config.cache -> status is still 1
> chmod 646 config.cache -> status is now 0!!
> 
> So somehow the “test” builtin for my bash-mesboot0 doesn’t think that it has 
> owner or group permissions to write to a file that itself created?
> 
> Let me know what you guys think could be the case!
> 
> Cheers,
> Carl Dong
> 
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]