From fce86b22a2367f1be1f9aae5e1ba3d18d1371b74 Mon Sep 17 00:00:00 2001 From: Michele Calgaro Date: Tue, 8 Dec 2020 22:26:17 +0900 Subject: Renaming of files in preparation for code style tools. Signed-off-by: Michele Calgaro --- doc/artsbuilder/faq.docbook | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/artsbuilder/faq.docbook') diff --git a/doc/artsbuilder/faq.docbook b/doc/artsbuilder/faq.docbook index 8bb7ae4c..65a14c87 100644 --- a/doc/artsbuilder/faq.docbook +++ b/doc/artsbuilder/faq.docbook @@ -414,7 +414,7 @@ Short answer: no, &arts; will not work if you compile it with gcc-3.0. Long answer: In the official release, there are two gcc-3.0 bugs which affect &arts;. The first, gcc-3.0 bug c++/2733 is relatively harmless (and has to do -with problems with the asm statement). It breaks compilation of convert.cc. It +with problems with the asm statement). It breaks compilation of convert.cpp. It has been fixed in the gcc-3.0 CVS, and will no longer be a problem with gcc-3.0.1 and higher. A workaround has also been added to the CVS version of KDE/aRts. @@ -1018,7 +1018,7 @@ succeeds, which eventually leads to consuming all CPU power and reporting might get supplied with wrong information how much to write. Artsd will then stop with an assertion like: -artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int): +artsd: audiosubsys.cpp:458: void Arts::AudioSubSystem::handleIO(int): Assertion `len == can_write' failed. Aborted -- cgit v1.2.1