This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 3/9] posix: Allow glob to match dangling symlinks [BZ #866]
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:
>> 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)