public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rainer@emrich-ebersheim.de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h Date: Wed, 24 Sep 2014 14:34:00 -0000 [thread overview] Message-ID: <bug-61889-4-ItcVUjgBBg@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-61889-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #8 from Rainer Emrich <rainer@emrich-ebersheim.de> --- (In reply to xur from comment #7) > OK. I'll fix this and submit another patch. What is the status for that? > > On Wed, Aug 20, 2014 at 11:26 AM, ktietz at gcc dot gnu.org > <gcc-bugzilla@gcc.gnu.org> wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 > > > > --- Comment #6 from Kai Tietz <ktietz at gcc dot gnu.org> --- > > Yes, I remember. I didn't comment on it. > > The following checks aren't ok. > > '#if !defined(_WIN32)' > > > > you should disable those parts *only* if ftw API isn't present. This you should > > check by a HAVE_FTW_H configure-check-macro. To disable it just because _WIN32 > > is defined is wrong. > > Quoting Kai Tietz: Issue got fixed on mingw-w64's side by providing on trunk ftw/nftw API. Nevertheless there is still an issue with the use of "mkdir": g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/. -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../include -I./../intl -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libcpp/include -I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include -I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include -I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libdecnumber -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libdecnumber/bid -I../libdecnumber -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libbacktrace -DCLOOG_INT_GMP -I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include -DCLOOG_INT_GMP -I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include -o gcov-tool.o -MT gcov-tool.o -MMD -MP -MF ./.deps/gcov-tool.TPo ../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c ../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c:95:21: error: macro "mkdir" requires 2 arguments, but only 1 given if (mkdir (out) == -1 && errno != EEXIST) ^ ../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c: In function 'void gcov_output_files(const char*, gcov_info*)': ../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c:95:27: error: ISO C++ forbids comparison between pointer and integer [-fpermissive] if (mkdir (out) == -1 && errno != EEXIST) ^ This clashes with the macro definition for mkdir in system.h: /* Some systems have mkdir that takes a single argument. */ #ifdef MKDIR_TAKES_ONE_ARG # define mkdir(a,b) mkdir (a) #endif Removing the wrong #if !defined(_WIN32) solves the issue for gcov-tool.c: Index: gcc/gcov-tool.c =================================================================== --- gcc/gcov-tool.c (Revision 215554) +++ gcc/gcov-tool.c (Arbeitskopie) @@ -89,11 +89,7 @@ gcov_output_files (const char *out, stru /* Try to make directory if it doesn't already exist. */ if (access (out, F_OK) == -1) { -#if !defined(_WIN32) if (mkdir (out, S_IRWXU | S_IRWXG | S_IRWXO) == -1 && errno != EEXIST) -#else - if (mkdir (out) == -1 && errno != EEXIST) -#endif fatal_error ("Cannot make directory %s", out); } else unlink_profile_dir (out); At a second point the issue is more complex. In libgcc/libgcov-driver-system.c there is the following code: #ifdef TARGET_POSIX_IO && mkdir (filename, 0755) == -1 #else && mkdir (filename) == -1 #endif libgcov-driver-system.c is used in two places, in the gcc directory and in the the libgcc directory for libgcov. In the first case the macro for mkdir is defined in the second it isn't. An ugly hack solves this issue and lets me at least build gcc-5.0.0 on x86_64-w64-mingw32. Index: libgcc/libgcov-driver-system.c =================================================================== --- libgcc/libgcov-driver-system.c (Revision 215554) +++ libgcc/libgcov-driver-system.c (Arbeitskopie) @@ -66,6 +66,9 @@ create_file_directory (char *filename) #ifdef TARGET_POSIX_IO && mkdir (filename, 0755) == -1 #else +#ifdef mkdir +#undef mkdir +#endif && mkdir (filename) == -1 #endif /* The directory might have been made by another process. */ Someone with more insight should have a look on this, please!
next prev parent reply other threads:[~2014-09-24 14:34 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-23 14:04 [Bug gcov-profile/61889] New: [4.10 " rainer@emrich-ebersheim.de 2014-07-23 14:24 ` [Bug gcov-profile/61889] " rguenth at gcc dot gnu.org 2014-07-23 15:17 ` ktietz at gcc dot gnu.org 2014-08-03 21:05 ` rainer@emrich-ebersheim.de 2014-08-20 17:36 ` [Bug gcov-profile/61889] [5 " ktietz at gcc dot gnu.org 2014-08-20 18:26 ` ktietz at gcc dot gnu.org 2014-08-20 19:44 ` xur at google dot com 2014-09-24 14:34 ` rainer@emrich-ebersheim.de [this message] 2014-09-24 14:45 ` rainer@emrich-ebersheim.de 2014-10-09 19:13 ` fxcoudert at gcc dot gnu.org 2014-10-13 19:29 ` rainer@emrich-ebersheim.de 2014-10-13 19:30 ` StaffLeavers at arm dot com 2014-10-13 19:32 ` StaffLeavers at arm dot com 2014-10-13 19:33 ` StaffLeavers at arm dot com 2014-10-13 19:33 ` fxcoudert at gcc dot gnu.org 2014-10-13 19:34 ` StaffLeavers at arm dot com 2014-10-13 21:32 ` xur at google dot com 2014-10-13 21:40 ` fxcoudert at gcc dot gnu.org 2014-10-13 21:45 ` xur at google dot com 2014-10-13 22:03 ` ktietz at gcc dot gnu.org 2014-10-13 22:37 ` xur at google dot com 2014-10-14 13:45 ` ktietz at gcc dot gnu.org 2015-01-21 14:55 ` jakub at gcc dot gnu.org 2015-02-10 3:41 ` tbsaunde at gcc dot gnu.org 2015-02-10 10:29 ` jakub at gcc dot gnu.org 2015-02-10 11:10 ` ktietz at gcc dot gnu.org 2015-02-10 11:12 ` jakub at gcc dot gnu.org 2015-02-10 11:38 ` rainer@emrich-ebersheim.de 2015-02-10 11:39 ` ktietz at gcc dot gnu.org 2015-02-10 11:46 ` rainer@emrich-ebersheim.de 2015-02-10 14:13 ` ktietz at gcc dot gnu.org 2015-02-10 14:15 ` ktietz at gcc dot gnu.org 2015-02-10 14:16 ` ktietz at gcc dot gnu.org 2015-02-12 8:55 ` terry.guo at arm dot com 2015-02-12 9:22 ` ktietz at gcc dot gnu.org 2015-02-12 9:41 ` terry.guo at arm dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-61889-4-ItcVUjgBBg@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).