[Bug libc/30509] New: testroot.root not updated when it should be

[Bug libc/30509] New: testroot.root not updated when it should be

[ppluzhnikov at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30509

            Bug ID: 30509
           Summary: testroot.root not updated when it should be
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: ppluzhnikov at google dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

I was looking at test failures after "make && make check", and found errors I
didn't expect.

Using 

rm string/tst-strerror.out
make objdir=`pwd` -C ../glibc/string check

I see:
/home/paul/glibc-build/string/tst-strerror: /lib64/libc.so.6: version
`GLIBC_ABI_DT_RELR' not found (required by
/home/paul/glibc-build/string/tst-strerror)
/home/paul/glibc-build/string/tst-strerror: /lib64/libc.so.6: version
`GLIBC_2.38' not found (required by /home/paul/glibc-build/string/tst-strerror)

Turns out that testroot.root/lib64 was not updated since (probably) the first
time I did "make check" in this build directory:

ls -l testroot.root/lib64/libc.so.6 testroot.root/lib64/libc-2.33.9000.so
-rwxr-xr-x 1 paul paul 14568704 Jun 20  2021
testroot.root/lib64/libc-2.33.9000.so
lrwxrwxrwx 1 paul paul       17 Jun 20  2021 testroot.root/lib64/libc.so.6 ->
libc-2.33.9000.so

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30509] testroot.root not updated when it should be

[ppluzhnikov at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30509

Paul Pluzhnikov <ppluzhnikov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dj at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30509] testroot.root not updated when it should be

[ppluzhnikov at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30509

--- Comment #1 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
It's actually the testroot.pristine/ that isn't updated.

In general, the intent of commit 561b0bec444 appears to be "install once &&
test repeatedly", and if you want to re-test after changes, you must 'rm
testroot.pristine/install.stamp'.

I think that is exceedingly error prone: the following sequence is usual:

- edit somefile.c
- make && make check

and would use newly-built libc.so for non-containerized tests, but would use
earlier built libc.so for containerized ones.

Should $(objpfx)testroot.pristine/install.stamp itself depend on
$(objpfx)libc.so, $(objpfx)elf/ld.so etc?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30509] testroot.root not updated when it should be

[dj at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30509

--- Comment #2 from dj at redhat dot com <dj at redhat dot com> ---
When we added the test-in-container functionality, we discussed this problem in
some detail.  At that time, we decided that the time required to install a
fresh testroot was too much to do for every iteration of editing a file,
especially if the file you're editing is the test case itself.

If you can come up with a way to optimize the re-install time of the testroot,
we can re-discuss this on the mailing list.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30509] testroot.root not updated when it should be

[ppluzhnikov at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30509

--- Comment #3 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
(In reply to dj@redhat.com from comment #2)
> When we added the test-in-container functionality, we discussed this problem
> in some detail.

Could you link to that discussion, so I don't repeat all the arguments you've
already discussed?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30509] testroot.root not updated when it should be

[dj at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30509

--- Comment #4 from dj at redhat dot com <dj at redhat dot com> ---
Hmmm... I can't seem to find it in the archives (it was back in 2018).  It
might have been discussed in a video call or something.  I recall that the
development cycle time was very important to developers.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30509] testroot.root not updated when it should be

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30509

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
I don't have a link to that discussion, either.

On the other hand, running a full container install for each “make t=… test”
makes test development (as opposed to library development) very, very slow.
It's also impossible to iterate quickly using ”make -j`nproc` && make -j`nproc`
subdirs=… check” for library development (if no impact on container tests is
expected). I think it was the latter part about which I complained, the cycle
time regression was just too massive.

On the other hand, the current situation is very confusing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30509] testroot.root not updated when it should be

[ppluzhnikov at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30509

--- Comment #6 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
(In reply to Florian Weimer from comment #5)

> makes test development (as opposed to library development) very, very slow.

Sorry, I didn't understand this part.

Container only needs to be updated when $(objpfx)libc.so etc. change.
If you are iterating over tst-*.c, I would expect "make" to not update the
container by virtue of regular dependency tracking.

> On the other hand, the current situation is very confusing.

Confusing is maybe tolerable.

Error-prone is (IMHO) intolerable: make a change; make check -- all PASS;
commit patch; break containerized test(s).

Nobody notices for a while, until "make clean" or a "make; make check" in a
fresh build directory.

---

One possible workaround is to rebuild testroot.pristine/ by default, but have
some way to suppress this rebuild (when you know there is no impact on the
container).

-- 
You are receiving this mail because:
You are on the CC list for the bug.