[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #21 from Kai Tietz <ktietz at gcc dot gnu.org> ---
(In reply to xur from comment #20)
> Thanks for the comments. I'll work on this to get it fixed this time.
> 
> Let me understand your idea correctly:
> We will have two patches: The first one will check FTW-API and make
> the gcov-tool build configurable.
> if -disable-gcov-tool is specified, we will not build gcov-tool.
> if -enable-gcov-tool is specified, we will build gcov-tool
> if neither specified, we will check the FTW-API and build gcovtool if
> FTW-API is available.

No, we always check if FTW-API is present.  The presence of FTW-API should have
no impact on case that gcov-tool gets built, or not.
Instead gcov-tool should take care that for cases where FTW-API isn't used the
specific part of functionality (it is used for file-unlinking) is simply
disabled.
Otherwise the standard code-path should be used.
Btw, as I already mentioned has mingw-w64 flavor the ftw/nftw API on its master
version.  And it works OOTB with current code.  So no need to break that by
assuming wild things in configure.

> The second patch is to emulate FTW in libiberty for MINGW32?
> I'm a little confused here. libiberty is built after the configure. Do
> we need to a special handling of MINGW32 in config?
Well, if we put that into libiberty, or put it in gcov-tool directly - I would
assume that you alway have dependency to libiberty, otherwise you should add it
for this tool, as it prevents you from reinventing the wheel again.
Anyway this part is something different and should be handled via the ML and
not via the bug-tracker.


> Thanks,
> 
> -Rong