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
