bugmake - Bugs: bug #52018, suggestion: test case for glob...

 
 

bug #52018: suggestion: test case for glob with dangling symlink

Submitter:  Paul Eggert <eggert>
Submitted:  Thu 14 Sep 2017 02:07:30 PM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  None Operating System:  POSIX-Based
Fixed Release:  4.3 Triage Status:  Small Effort
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 20 Oct 2022 12:12:01 AM UTC, comment #7: 


> So Debian Stretch aka 9, with glibc 2.24, fails, where Debian Buster aka 10, with glibc 2.28, passes, meaning that it exhibits the new behavior, where $(wildcard) matches even dangling symlinks.


It would be possible for 'make' to not have this test failure, that is, to exhibit the new behaviour of $(wildcard) even on older glibc systems. The way to do so would be to use the Gnulib module 'glob', which is documented to fix this problem: https://www.gnu.org/software/gnulib/manual/html_node/glob.html

Currently GNU make uses only part of the Gnulib module 'glob': It has the .c file, but uses a module 'make-glob' instead of 'glob'. On Debian 9.1, this module produces:
- during configuration the message "checking if system libc has GNU glob... yes"
- in config.status the substitution USE_SYSTEM_GLOB ← yes.

That's why we see this test fail on glibc < 2.27 (and likely also AIX 7.2, Solaris 11.4) systems.

But it's not all so simple to use full Gnulib modules in GNU make, see gl/README...

Bruno Haible <haible>
Wed 19 Oct 2022 04:14:51 PM UTC, comment #6: 

If I've understood this correctly, then the upshot of the new test, https://git.savannah.gnu.org/cgit/make.git/commit/?id=f9ba22e02924e0a869a6e40ef4a70ee884d1ec46, is that we should expect a "failure", which is really just documenting legacy behavior, that looks like:

martind@sirius:~/download/make-4.3.91$ make check
...
functions/wildcard ...................................... FAILED (9/10 passed)
...
martind@sirius:~/download/make-4.3.91$ cat tests/work/functions/wildcard.diff.9
*** work/functions/wildcard.base.9        Wed Oct 19 09:03:36 2022
--- work/functions/wildcard.log.9        Wed Oct 19 09:03:36 2022
***************
*** 1 ****
! __ldir
--- 1 ----
!
martind@sirius:~/download/make-4.3.91$

... from make binaries built using glibc glob on systems with glibc older than https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ccf970c7a77e86f4f5ef8ecc5e637114b1c0136a so older than 2.27.  So Debian Stretch aka 9, with glibc 2.24, fails, where Debian Buster aka 10, with glibc 2.28, passes, meaning that it exhibits the new behavior, where $(wildcard) matches even dangling symlinks.

Martin Dorey <mdorey>
Sun 05 Aug 2018 12:24:37 PM UTC, comment #5: 

I added a test as suggested below.  I can't say whether it really tests the problem case but it's not a bad test to have anyway.

Paul D. Smith <psmith>
Group administrator
Sun 24 Sep 2017 10:54:09 PM UTC, comment #4: 

You'd have to run bleeding-edge-from-git glibc to get the new behavior, or copy glob.c from bleeding-edge Gnulib and use that instead of glibc glob.

The new implementation will use gl_lstat when testing for existence, and will use gl_stat only when testing for directories. However, you shouldn't assume this; e.g., the implementation is free to use only gl_lstat if it wants to.

Your idea for a test case sounds good.

Paul Eggert <eggert>
Sun 24 Sep 2017 01:53:14 PM UTC, comment #3: 

Hm, well, I don't have a newer glibc and I don't know how the newer glob will utilize the gl_lstat element, so I don't know exactly what the test needs to do in order to stress this.  Do I just need to get the wildcard function to expand a symlink which doesn't point to a real file?  I wrote a test like that but of course it succeeds for me with my glibc, even before the changes to make's dir.c.

Paul D. Smith <psmith>
Group administrator
Sat 23 Sep 2017 09:18:21 PM UTC, comment #2: 

Heh, I guess it's in the title and I only read the problem description :).

Paul D. Smith <psmith>
Group administrator
Sat 23 Sep 2017 09:17:45 PM UTC, comment #1: 

Can you clarify what the usage is that is not being tested?  You mean, obtaining timestamps from dangling symlinks?

Paul D. Smith <psmith>
Group administrator
Thu 14 Sep 2017 02:07:30 PM UTC, original submission:  

This message follows up on my recent bug report "Do not assume glibc glob internals" <http://lists.gnu.org/archive/html/bug-make/2017-09/msg00014.html>.

In later discussion on libc-alpha, Adhemerval Zanella noted "make tests itself does not trigger ... this issue (running make tests with a newer glibc shows no regression), so it would be good also if make adds a newer tests to stress it." See:

https://sourceware.org/ml/libc-alpha/2017-09/msg00616.html

This is a good suggestion so I thought I'd pass it along. It'll require 'make' to upgrade to a recent Gnulib version of glob.c, which is a good thing for other reasons (we've been fixing some bugs and are likely to fix more soon).

Paul Eggert <eggert>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by mdorey (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by eggert (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-05 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Operating SystemNone POSIX-Based
        Fixed ReleaseNone 4.3
        Triage StatusNone Small Effort

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code