Bug 2073222 - ccache doesn't invalidate cache on compiler updates
Summary: ccache doesn't invalidate cache on compiler updates
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: ccache
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michael Cullen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-04-07 23:55 UTC by Ian McInerney
Modified: 2022-12-13 17:33 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-12-13 17:33:12 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ian McInerney 2022-04-07 23:55:30 UTC
Description of problem:

I am building Audacity using all the Fedora flags (including the LTO flags), and I am receiving a very strange error. One of the shared libraries that it builds contains two files (a header and its C++ source) which are the following:


Meter.h begin code>>>

/*!********************************************************************

Audacity: A Digital Audio Editor

@file Meter.h

Paul Licameli split from MeterPanelBase.h

**********************************************************************/

#ifndef __AUDACITY_METER__
#define __AUDACITY_METER__

//! AudioIO uses this to send sample buffers for real-time display updates
class AUDIO_DEVICES_API Meter /* not final */
{
public:
   virtual ~Meter();

   virtual void Clear() = 0;
   virtual void Reset(double sampleRate, bool resetClipping) = 0;
   virtual void UpdateDisplay(unsigned numChannels,
                      unsigned long numFrames, const float *sampleData) = 0;
   virtual bool IsMeterDisabled() const = 0;
   virtual float GetMaxPeak() const = 0;
   virtual bool IsClipping() const = 0;
   virtual int GetDBRange() const = 0;
};

#endif

<<< end code

Meter.cpp begin code >>>

/*!********************************************************************

Audacity: A Digital Audio Editor

@file Meter.cpp

Paul Licameli split from MeterPanelBase.cpp

**********************************************************************/

#include "Meter.h"

#include <string>

Meter::~Meter()
{
}

<<< end code


When building these and linking them against a few other C++ files into the shared library, GCC throws this error and terminates:

[ 44%] Linking CXX shared library ../../shared/Debug/lib-audio-devices.so
lto1: fatal error: bytecode stream in file ‘CMakeFiles/lib-audio-devices.dir/Meter.cpp.o’ generated with LTO version 11.0 instead of the expected 11.2
compilation terminated.
lto-wrapper: fatal error: /usr/bin/c++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [libraries/lib-audio-devices/CMakeFiles/lib-audio-devices.dir/build.make:159: shared/Debug/lib-audio-devices.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:1337: libraries/lib-audio-devices/CMakeFiles/lib-audio-devices.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....


If I just add #include <string> inside Meter.cpp, then GCC no longer throws this LTO error and the compilation succeeds.


Version-Release number of selected component (if applicable):

gcc-11.2.1-9.fc35.x86_64
gcc-c++-11.2.1-9.fc35.x86_64

Comment 1 Ian McInerney 2022-04-08 00:55:41 UTC
I have encountered this error several more times when building Audacity, and one of them was saying the bytecode included in the object file for an empty cpp file was version 11.0 instead of version 11.2. That was again fixed by adding a random standard library header include.

So far I have had to add this hack to 7 files in my build tree to work around the error (all of them had basically no compiled content, and specifically no standard library headers), but now I hit a wall when it threw this error on a static library from the build process (and doesn't say what inside the static library triggered it, just that the library had bytecode from 11.0).

Comment 2 Ian McInerney 2022-04-09 23:27:27 UTC
Turns out ccache was enabled. This I guess becomes more of a feature request for ccache to not use the cached version of files (and force a recompilation) when compiler versions change like this.

Comment 3 Orion Poplawski 2022-10-01 22:30:54 UTC
No development like that is going to happen downstream.  This is going to need to be taken up with ccache upstream.

Comment 4 Ben Cotton 2022-11-29 18:43:00 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 5 Ben Cotton 2022-12-13 17:33:12 UTC
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.