bug#35691: [bug-guix] remote configure failure due to bad pathnames for crt*.o

[Nelson H. F. Beebe]

I built a new virtual machine (VM) on 2-May-2019 from the
newly-announced GUIX 1.0 release in the

         guix-system-install-1.0.0.x86_64-linux.iso 

image file. The VM runs on VirtManager (QEMU/KVM) on CentOS 7.

I initially tried to select 3 desktop managers, but later in the
installation, one of them died and the system could not recover, nor
could it boot from the virtual disk.  I tried again, choosing only
xfce as the desktop manager, and that succeeded.

Since them, I've been busy trying to understand the GUIX model of
UNIX, and testing software installations with a goal to being able to
announce a TeX Live 2019 port to GUIX 1.0 (I'm part of the TeX Live
development team).  My build reports for TeX Live appear here:

        http://www.math.utah.edu/pub/texlive-utah-2019/

On GUIX 1.0, I found that I could take arbitrary GNU packages (and
many of my own) and invoke the usual commands

        tar xf FOO-x.y.z.tar.gz
        cd FOO-x.y.z
        ./configure && make all check && make install

AS LONG AS I am logged in on a terminal window via ssh from another
system.

However, if I instead execute those commands remotely with

        % ssh guix10.vm.example.com 'cd FOO-x.y.z ; ./configure && make all 
check && make install'

then the configure script fails like this:

        checking whether the C compiler works... no
        configure: error: in `/local/build/cc/dw-2.00':
        configure: error: C compiler cannot create executables
        See `config.log' for more details
        ...

The config.log file contains these messages:

        ld: cannot find crt1.o: No such file or directory
        ld: cannot find crti.o: No such file or directory
        collect2: error: ld returned 1 exit status

In separate experiments, I verified that my shell enviroment (as
reported by "env | sort") was the same in both cases.

I then installed the strace package and ran

        % ssh guix10.vm.example.com 'cd FOO-x.y.z ; strace -f -o foo.strace 
./configure'

That identified the problem:

        % fgrep crt1.o foo.strace | grep 'lib.*crt'
        ...
        28734 
access("/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/libcrt1.o", 
R_OK) = -1 ENOENT (No such file or directory)

There is a missing path separator in the word "libcrt1.o"; the correct
file is this one:

        $ ls -l 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/crt1.o
        -r--r--r-- 2 root root 2024 Dec 31  1969 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/crt1.o

The bad pathname may be generated by GUIX's ld, but it is unclear to
me why it works in an interactive login, but fails as shown in an ssh
batch command execution.

Until this problem is fixed, I cannot incorporate GUIX in my massive
build farm testing on 250+ flavors of Unix that I routinely do for
many GNU, and other, packages.


-------------------------------------------------------------------------------
- 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: address@hidden  -
- 155 S 1400 E RM 233                       address@hidden  address@hidden -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------