[Nix-dev] Re: Chrooted build failure with trunk

[Eelco Dolstra]

Ludovic Courtès wrote:

> ludo at gnu.org (Ludovic Courtès) writes:
> 
>> I fail to build a few packages in a chroot with the current trunk.
>> Examples include Gnash and GnuTLS:
>>
>>   libtool --mode=link gcc -Wl,--version-script,../exports  -rpath /nix/store/rk7n8vgdylgaqpix5pg8g8m3nddr2wqg-acl-2.2.47/lib -version-info 2:0:1 -o libacl.la acl_add_perm.lo acl_calc_mask.lo acl_clear_perms.lo acl_copy_entry.lo acl_copy_ext.lo acl_copy_int.lo acl_create_entry.lo acl_delete_def_file.lo acl_delete_entry.lo acl_delete_perm.lo acl_dup.lo acl_free.lo acl_from_text.lo acl_get_entry.lo acl_get_fd.lo acl_get_file.lo acl_get_perm.lo acl_get_permset.lo acl_get_qualifier.lo acl_get_tag_type.lo acl_init.lo acl_set_fd.lo acl_set_file.lo acl_set_permset.lo acl_set_qualifier.lo acl_set_tag_type.lo acl_to_text.lo acl_valid.lo acl_size.lo acl_to_any_text.lo acl_entries.lo acl_check.lo acl_error.lo acl_cmp.lo acl_extended_fd.lo acl_extended_file.lo acl_equiv_mode.lo acl_from_mode.lo __acl_t
>>  o_any_text.lo __acl_to_xattr.lo __acl_from_xattr.lo __acl_reorder_obj_p.lo __libobj.lo __apply_mask_to_mode.lo perm_copy_fd.lo perm_copy_file.lo -lattr ../libmisc/libmisc.la
>>   shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such device or address
>>   pwd: error retrieving current directory: getcwd: cannot access parent directories: Success
>>   pwd: error retrieving current directory: getcwd: cannot access parent directories: Bad address
>>   chdir: error retrieving current directory: getcwd: cannot access parent directories: Success
> 
> The problem apparently vanished somehow, but I can't think of any change
> I made that would explain it...

I get similar errors now when building in a chroot (actually warnings, the
builds in question do succeed).  I've only seen them when rebuilding stdenv,
which might be because it uses a bash linked against dietlibc.  The reason that
getcwd fails seems to be that getcwd and getdents return inconsistent inodes for
the current directory, as revealed by strace:

stat64(".", {st_dev=makedev(8, 6), st_ino=11994120, st_mode=S_IFDIR|0755,
st_nlink=2, st_uid=30001, st_gid=30000, st_blksize=1024, st_blocks=2,
st_size=1024, st_atime=2008/08/27-16:50:08, st_mtime=2008/08/27-16:50:08,
st_ctime=2008/08/27-16:50:08}) = 0

(i.e. the inode for "." is 11994120)

open("..", O_RDONLY|O_DIRECTORY)        = 3

getdents64(3, {{d_ino=11994128, d_off=191254852, d_type=DT_DIR, d_reclen=96,
d_name="nix-build-2lngynq4r41s93py8d779d860r04asa2-stdenv-linux-initial-2.drv-0"}
{d_ino=11994127, d_off=658856440, d_type=DT_DIR, d_reclen=24, d_name="."}
{d_ino=11994126, d_off=2147483647, d_type=DT_DIR, d_reclen=24, d_name=".."}},
4084) = 144

but here the current directory
"nix-build-2lngynq4r41s93py8d779d860r04asa2-stdenv-linux-initial-2.drv-0" has
inode 11994128.  It seems this is because it's a bind mount point: getdents
returns the inode of the (empty) mount point directory, and stat returns the
inode of the mounted directory.

It appears that normal bash (linked against Glibc) works properly because it
uses the getcwd() system call instead of trying to figure out the cwd itself.

-- 
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/