Re: [PATCH 3/9] posix: Allow glob to match dangling symlinks [BZ #866]

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 14/09/2017 07:05, Szabolcs Nagy wrote:
> On 13/09/17 13:22, Adhemerval Zanella wrote:
>> On 13/09/2017 06:14, Paul Eggert wrote:
>>> Adhemerval Zanella wrote:
>>>> Another approach that does not involve adding compat symbols (which adds
>>>> a lot of code complexity inside glibc build and do not solve 'make' builds
>>>> against new glibc) would to make GLOB_ALTDIRFUNCS to follow the old semantic
>>>> of using gl_stat instead of gl_lstat while making glob without GLOB_ALTDIRFUNCS
>>>> works as intended.  And add another flag, GLOB_ALTDIRFUNCS2, which actually
>>>> uses gl_lstat.
>>>
>>> Although that's clever, it is a gratuitous source-code incompatibility with BSD, which is not a good thing. To some extent it's just GLOB_FOLLOW and GLOB_NOFOLLOW in disguise, and disguise is not a good thing in APIs. So I think I still prefer the compat symbol approach.
>>>
>>> We'll get GNU 'Make' fixed, and I wouldn't worry overly much about people building unpatched 'Make' with new glibc. I filed a Make bug report is here:
>>>
>>> http://lists.gnu.org/archive/html/bug-make/2017-09/msg00014.html
>>
>> Right, I am mainly trying to avoid bring more internal glob implementation
>> complexity to glibc, but since you says the unpatched 'Make' built
>> against newer glibc shouldn't be a problem I think we can this way.
>> I will work on it.
>>
> 
> i think breaking make is a serious issue now for
> anyone trying to do toolchain dev (in native chroots).
> and if this gets into a released version of glibc
> then it will be an issue for distros.
> 
> i think old make binaries should keep working with
> glibc 2.27 whatever it takes and it's best to fix
> this breakage sooner than later (it's a pain to
> carry patched make around).

Yes, that was the consensus and the idea is to provide a compat symbol
that does not call gl_lstat.

As a side note, make tests itself does not trigger it 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.

> 
> (this is not different than the stupid malloc hook
> usage was in emacs and that was dragged out over
> several years until glibc was fixed to wait for
> a stable emacs release that is fixed, the same
> should be done for make)
>