WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> I found the problem!
> It's related to the use of precompiled headers. We need to use
> '-fpch-deps' in order to get the full dependencies, otherwise all the
> dependencies from the pch file are omitted.
> I'm currently preparing a webrev which fixes the problem. It would be
> nice if somebody could meanwhile open a bug for the problem (e.g.
> "Usage of gcc with precompiled headers produces wrong build
> dependencies") and provide a bug-id.
> On Fri, Jun 8, 2012 at 7:50 PM, Volker Simonis <volker.simonis@...> wrote:
>> Yes, that's really strange. You're right, the dependency file should
>> contain ".. the names of all the included files" (gcc -man page).
>> So it seems to be a bug in gcc and how it handles '-MMD' although I
>> couldn't find a bug report for it and I can't believe that nobody else
>> has noticed this before. I've tried gcc 4.4.3 and 4.1.2 and they both
>> produce a wrong dependency file which only contains the direct
>> includes of the processed .cpp file (with "-c -MMD -MP -MF
>> ../generated/dependencies/frame.o.d -o frame.o").
>> If I compile with "-c -MM -MP -MF ../generated/dependencies/frame.o.d
>> -o frame.o" the generated dependency file is much bigger and looks ok,
>> but of course I get no object file. I also get he same wrong behavior
>> for -MD vs -M. The only reason behind -MD and -MMD is that it "..can
>> be used to generate a dependency output file as a side-effect of the
>> compilation process" (from the GCC man page) - but that doesn't seem
>> to work..
>> Does anybody has an explanation for this behavior?
>> On Fri, Jun 8, 2012 at 6:25 PM, Keith McGuigan
>> <keith.mcguigan@...> wrote:
>>> I don't understand why gcc doesn't put frame_x86.inline.hpp into the
>>> generated/dependencies/frame.o.d file. Isn't the point of -MMD to calculate
>>> the full closer of header files used for listing as a dependency? Is this a
>>> bug in gcc or are we using it wrong?
>>> I notice that Sun Studio compiler does put the arch-specific header file in
>>> the generated dependency file. Weird.
>>> - Keith
>>> On 6/8/2012 11:58 AM, Volker Simonis wrote:
>>>> I've just stumbled across the problem that changing the implementation
>>>> of an inline function in HotSpot does not necessarily rebuild all the
>>>> call sites of that function. This is because because of the way how
>>>> the build dependencies are handled within the HotSpot. As an example
>>>> you may have a look at frame.cpp:
>>>> frame.cpp includes frame.inline.hpp
>>>> frame.inline.hpp includes frame_x86.inline.hpp
>>>> However frame.cpp only depends on frame.inline.hpp directly (i.e.
>>>> frame.cpp only includes frame.inline.hpp directly and this is where
>>>> the dependencies generated by gcc with '-MMD' are computed from).
>>>> So if an inline function in frame_x86.inline.hpp will be changed (e.g.
>>>> the constructor frame::frame()), frame.cpp will not be recompiled in
>>>> an incremental build, although it uses the constructor frame::frame().
>>>> This makes incremental builds useless (or dangerous, depending on the
>>>> view point) when inline functions are changed.
>>>> I think this is a non-trivial problem which is deeply rooted in the
>>>> way how C++ implements inlining and the way how inline functions are
>>>> defined in HotSpot (i.e. .hpp, .inline.hpp, _<cpu>.hpp and
>>>> _<cpu>.inline.hpp files). I don't have a solution for it but just
>>>> wanted to ask if somebody else already stumbled upon this problem
>>>> and/or has solution for it?