[Bug gprof/2587] Failed to build gprof under gmake patched by Apple.
https://sourceware.org/bugzilla/show_bug.cgi?id=2587 parakleta at gmail dot com changed: What|Removed |Added CC||parakleta at gmail dot com --- Comment #3 from parakleta at gmail dot com --- I don't know how the Apple specific variant of `gmake` was at the time this bug was resolved, but the relevant build rules are now part of mainline gmake http://git.savannah.gnu.org/cgit/make.git/commit/default.c?id=eda0e24ccdae279a2c12059242ef89a22c274047 but it was added as an old-style suffix rule, so this patch now does nothing (since it is not a builtin pattern rule). The two options to resolve it appear to be either disabling all builtin rules (can be done with `.MAKEFLAGS: -r`) or else change the suffix order so that '.c' comes before '.m'. The suffix order was correct before 6bf9431b7430d0c30268c62f78a940657c8d6fbe rebuilt the `makefile.in` file (maybe this was a change in the behaviour of automake?). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprof/2587] Failed to build gprof under gmake patched by Apple.
https://sourceware.org/bugzilla/show_bug.cgi?id=2587 --- Comment #6 from parakleta at gmail dot com --- Sorry, by suffix rule order this means the order of suffixes in the `.SUFFIXES:` target which is autogenerated by the `SUFFIXES` variable in the "makefile.am" file. Your change will attempt to build '.c' files from '.m' files. I'm not familiar with automake but I believe you should change the relevant line to `SUFFIXES = .c .m` and then need to rebuild the "makefile.in" file using automake. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprof/2587] Failed to build gprof under gmake patched by Apple.
https://sourceware.org/bugzilla/show_bug.cgi?id=2587 --- Comment #7 from parakleta at gmail dot com --- I've just realised that changing the order of rules may not work. We want to have '.m -> .c -> .o' as the sequence without triggering '.m -> .o', and by setting '.c' before '.m' we're saying if '.c -> .o' is possible then use that, but I suspect if the '.c' file is missing or out of date the it will try the '.m -> .o' rule before trying to build the intermediate. I think this means that either the '.c' files need to be listed as explicit dependencies of the '.o' files in the case that a '.m' file exists (so bypassing the pattern and forcing the explicit sequence '.m -> .c => .o') or else disabling the rules as per my first suggestion. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprof/2587] Failed to build gprof under gmake patched by Apple.
https://sourceware.org/bugzilla/show_bug.cgi?id=2587 --- Comment #8 from parakleta at gmail dot com --- (In reply to parakleta from comment #7) > I've just realised that changing the order of rules may not work. Ignore this. There is an explicit dependency on the "BUILT_SOURCES" existing which forces the '.m -> .c' step to occur before other dependency checking is performed so long as the 'all' target is used, so this is good enough. I think just changing the 'SUFFIXES = .m' to 'SUFFIXES = .c .m' and rebuilding the "makefile.in" should do it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprof/2587] Failed to build gprof under gmake patched by Apple.
https://sourceware.org/bugzilla/show_bug.cgi?id=2587 --- Comment #11 from parakleta at gmail dot com --- (In reply to cvs-com...@gcc.gnu.org from comment #4) > The master branch has been updated by Nick Clifton : > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=415ed2a17588f855397cc2d03aa68a79e84f77f7 > > commit 415ed2a17588f855397cc2d03aa68a79e84f77f7 > Author: Nick Clifton > Date: Wed Nov 13 11:21:39 2019 + > > Fix the rule for building C files in the gprof makefile. > > PR 2587 > * Makefile.am: Fix rule to build .c files from .m files. You still need to revert this change. -- You are receiving this mail because: You are on the CC list for the bug.
