Bug 7827 - ccache doesn't handle -MFarg, -MTarg and -MQarg like GCC does
Summary: ccache doesn't handle -MFarg, -MTarg and -MQarg like GCC does
Status: CLOSED FIXED
Alias: None
Product: ccache
Classification: Unclassified
Component: ccache (show other bugs)
Version: 3.1
Hardware: Other Linux
: P3 normal
Target Milestone: 3.1.3
Assignee: Joel Rosdahl
QA Contact: Joel Rosdahl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-28 09:20 UTC by Ville Skyttä
Modified: 2012-11-26 19:57 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ville Skyttä 2010-11-28 09:20:03 UTC 
https://bugzilla.redhat.com/show_bug.cgi?id=657857

Maybe the -MF and -MT options added by Eclipse are not handled correctly by ccache?  From original bug report (this was with ccache 3.1):

| Apparently, this is a ccache bug, if you export CCACHE_DISABLE=1 or run g++
| directly:
| /usr/bin/g++ -g3 -c -MMD -MP -MF"MyFile.d" -MT"MyFile.d" -o"MyFile.o" "../MyFile.cpp"
|
| You won't see the error message. (The error will vanish if you add an space
| after MT and MF options too).
Comment 1 Joel Rosdahl 2010-11-28 09:42:24 UTC 
Yes, the problem is that GCC accepts -MFarg and MTarg (and -MQarg) without spaces (which is undocumented) but ccache doesn't.
Comment 2 Joel Rosdahl 2010-11-28 10:49:25 UTC 
Fixed in c69f951ecd6a9fe5c087f8836f7c2de6a7159896.
Comment 3 Joel Rosdahl 2010-11-28 10:53:51 UTC 
Included in version 3.1.3.
Comment 4 Steve Wills 2012-11-19 18:14:07 UTC 
Is it possible this bug came back in 3.1.8? I'm seeing this:

@g++ -c -O2 -g -pipe -pedantic -Wshadow -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-long-long  -Wno-variadic-macros -O2 -fno-omit-frame-pointer -fno-strict-aliasing -m64 -I/work/a/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.22/src/VBox/Runtime/include -I/work/a/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.22/src/libs/liblzf-3.4 -I/usr/include -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -I/work/a/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.22/src/libs/boost-1.37.0 -I/work/a/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.22/include -I/work/a/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.22/out/freebsd.amd64/release -DVBOX -DVBOX_WITH_DEBUGGER -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\"/usr/local/share/virtualbox-ose\" -DRTPATH_APP_PRIVATE_ARCH=\"/usr/local/lib/virtualbox\" -DRTPATH_SHARED_LIBS=\"/usr/local/lib/virtualbox\" -DRTPATH_APP_DOCS=\"/usr/local/share/doc/virtualbox-ose\" -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -D_REENTRANT -DBOOST_DISABLE_ASSERTS -DIN_RING3 -DLOG_DISABLED -DIN_RT_R3 -DIN_SUP_R3 -DLDR_WITH_NATIVE -DLDR_WITH_ELF32 -DLDR_WITH_PE -DRT_WITH_VBOX -DRT_NO_GIP -DRT_WITH_ICONV_CACHE -Wp,-MD,/work/a/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.22/out/freebsd.amd64/release/obj/RuntimeBldProg/common/alloc/heapoffset.o.dep -Wp,-MT,/work/a/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.22/out/freebsd.amd64/release/obj/RuntimeBldProg/common/alloc/heapoffset.o -Wp,-MP -o /work/a/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.22/out/freebsd.amd64/release/obj/RuntimeBldProg/common/alloc/heapoffset.o /work/a/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.22/src/VBox/Runtime/common/alloc/heapoffset.cpp
cc1plus: error: to generate dependencies you must specify either -M or -MM

while trying to build virtualbox. And setting CCACHE_DISABLE=1 avoids it.
Comment 5 Joel Rosdahl 2012-11-26 19:57:57 UTC 
(In reply to comment #4)
> Is it possible this bug came back in 3.1.8?

The fix was intentionally removed in 3.1.7:

    - Reverted the GCC bug compatibility introduced in ccache 3.1.5 for
      `-MT`/`-MQ` options with concatenated arguments. (The bug is fixed in
      recent GCC versions.)

The problem was that the workaround made newer GCC versions fail. Since ccache currently can't change behavior depending on compiler version, we have to choose the least troublesome behavior.