I’m trying to rebuild the 1.3.12 source RPM on CentOS 5.5 with a copy of flac-devel-1.1.2-28.el5_0.1. This seems to hit code in ImportFLAC.cpp and ExportFLAC.cpp that doesn’t compile but was fairly easy to patch.
--- audacity-src-1.3.12-orig/src/export/ExportFLAC.cpp 2011-03-24 02:00:59.000000000 +0000
+++ audacity-src-1.3.12-beta/src/export/ExportFLAC.cpp 2011-03-24 02:02:45.000000000 +0000
@@ -347,7 +347,9 @@
}
updateResult = progress->Update(mixer->MixGetCurrentTime()-t0, t1-t0);
}
+#ifndef LEGACY_FLAC
f.Detach(); // libflac closes the file
+#endif
encoder.finish();
delete progress;
--- audacity-src-1.3.12-orig/src/import/ImportFLAC.cpp 2011-03-24 02:32:27.000000000 +0000
+++ audacity-src-1.3.12-beta/src/import/ImportFLAC.cpp 2011-03-24 02:33:02.000000000 +0000
@@ -211,7 +211,9 @@
case FLAC__METADATA_TYPE_APPLICATION: // no idea what to do with this
case FLAC__METADATA_TYPE_SEEKTABLE: // don't need a seektable here
case FLAC__METADATA_TYPE_CUESHEET: // convert this to labels?
+#ifndef LEGACY_FLAC
case FLAC__METADATA_TYPE_PICTURE: // ignore pictures
+#endif
case FLAC__METADATA_TYPE_UNDEFINED: // do nothing with this either
break;
}
Now the build just craps out with a related error but not one I understand how to fix since the file explicitly says it is built without using LEGACY_FLAC.
g++ -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I../lib-src/portmixer/include -I../lib-src/portaudio-v19/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../lib-src/FileDialog -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/home/trevor/rpmbuild/BUILD/audacity-src-1.3.12-beta/lib-src/lib-widget-extra -I../lib-src/sbsms/include -I../lib-src/libnyquist -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/home/trevor/rpmbuild/BUILD/audacity-src-1.3.12-beta/lib-src/portsmf -fno-strict-aliasing -I./include -I. -DLIBDIR="/usr/lib64" -D__STDC_CONSTANT_MACROS -Wall -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 ondemand/ODDecodeFlacTask.cpp -o ondemand/ODDecodeFlacTask.o
ondemand/ODDecodeFlacTask.cpp: In member function 'virtual bool ODFlacDecoder::ReadHeader()':
ondemand/ODDecodeFlacTask.cpp:236: error: no matching function for call to 'ODFLACFile::init(FILE*)'
/usr/include/FLAC++/decoder.h:317: note: candidates are: FLAC::Decoder::File::State FLAC::Decoder::File::init()
ondemand/ODDecodeFlacTask.cpp:239: error: 'FLAC__STREAM_DECODER_INIT_STATUS_OK' was not declared in this scope
make[1]: *** [ondemand/ODDecodeFlacTask.o] Error 1
make[1]: Leaving directory `/home/trevor/rpmbuild/BUILD/audacity-src-1.3.12-beta/src'
make: *** [audacity] Error 2
error: Bad exit status from /home/trevor/rpmbuild/tmp/rpm-tmp.94270 (%build)
Anyone got any suggestions as to how to proceed? Thanks.
I’m not sure, but I think that you may be hitting a bug in “on demand” loading of Flac files, but this is an experimental feature that does not work yet and should not be enabled. I would recommend that you try the current 1.3.13 code which is available from SVN http://audacityteam.org/community/developers#svn
I checked out trunk and tarred it up and substituted it in the RPM source files, hacked out patch3 and patch7 which seem to have been fixed in svn already, rebuilt from scratch and got the same error.
I went by the comment in the source file which I read as saying that LEGACY_FLAC was not available in this file.
//Note:we are not using LEGACY_FLAC defs (see ImportFlac.cpp FlacImportFileHandle::Init()
//this code is based on that function.
and in this case, I would expect that the #ifndef that you posted would always match. I commented the line out in a separate patch that’s applied by rpmbuild. My patches so far to the source to make it compile with FLAC < 1.1.3 are as follows:
--- audacity-src-1.3.12-orig/src/import/ImportFLAC.cpp 2011-03-24 02:32:27.000000000 +0000
+++ audacity-src-1.3.12-beta/src/import/ImportFLAC.cpp 2011-03-24 02:33:02.000000000 +0000
@@ -211,7 +211,9 @@
case FLAC__METADATA_TYPE_APPLICATION: // no idea what to do with this
case FLAC__METADATA_TYPE_SEEKTABLE: // don't need a seektable here
case FLAC__METADATA_TYPE_CUESHEET: // convert this to labels?
+#ifndef LEGACY_FLAC
case FLAC__METADATA_TYPE_PICTURE: // ignore pictures
+#endif
case FLAC__METADATA_TYPE_UNDEFINED: // do nothing with this either
break;
}
--- audacity-src-1.3.12-orig/src/ondemand/ODDecodeFlacTask.cpp 2011-03-24 02:44:58.000000000 +0000
+++ audacity-src-1.3.12-beta/src/ondemand/ODDecodeFlacTask.cpp 2011-03-24 02:47:17.000000000 +0000
@@ -76,7 +76,7 @@
case FLAC__METADATA_TYPE_APPLICATION: // no idea what to do with this
case FLAC__METADATA_TYPE_SEEKTABLE: // don't need a seektable here
case FLAC__METADATA_TYPE_CUESHEET: // convert this to labels?
- case FLAC__METADATA_TYPE_PICTURE: // ignore pictures
+ // case FLAC__METADATA_TYPE_PICTURE: // ignore pictures
case FLAC__METADATA_TYPE_UNDEFINED: // do nothing with this either
break;
}
--- audacity-src-1.3.12-orig/src/ondemand/ODDecodeFlacTask.cpp 2011-03-26 21:50:45.000000000 +0000
+++ audacity-src-1.3.12-beta/src/ondemand/ODDecodeFlacTask.cpp 2011-03-26 21:51:20.000000000 +0000
@@ -237,7 +237,7 @@
bool result = mFile->init(mHandle.fp())?true:false;
mHandle.Detach();
- if (result != FLAC__STREAM_DECODER_INIT_STATUS_OK) {
+ if (result == FLAC__STREAM_DECODER_UNINITIALIZED) {
return false;
}
--- audacity-src-1.3.12-orig/src/export/ExportFLAC.cpp 2011-03-24 02:00:59.000000000 +0000
+++ audacity-src-1.3.12-beta/src/export/ExportFLAC.cpp 2011-03-24 02:02:45.000000000 +0000
@@ -347,7 +347,9 @@
}
updateResult = progress->Update(mixer->MixGetCurrentTime()-t0, t1-t0);
}
+#ifndef LEGACY_FLAC
f.Detach(); // libflac closes the file
+#endif
encoder.finish();
delete progress;
I have eventually got this to build with FLAC support. Once I figured out the magic switch, it didn’t need my patches though I do not think that they hurt and probably should be included back into svn - especially the ones to ExportFLAC and ImportFLAC.cpp as those are plainly bugs.
The magic switch is to change --with-libflac=system to --with-libflac=local in the %configure in the audacity.spec file
I’m not sure how that would work. I think that would always be undefined as the code in that file does not contain the magic #ifdef’s that actually set (or not) LEGACY_FLAC. If you look in the ExportFLAC.cpp and ImportFLAC.cpp files, both contain identical code that evaluates other flac supplied #defines and then #define’s LEGACY_FLAC based on those. The ODDecodeFlac.cpp file does not do that so LEGACY_FLAC will never be defined. Might as well comment that line which is what I did before (almost certainly wrongly).
[quote=“TrevorPH”]
I have eventually got this to build with FLAC support. Once I figured out the magic switch, it didn’t need my patches though I do not think that they hurt and probably should be included back into svn - especially the ones to ExportFLAC and ImportFLAC.cpp as those are plainly bugs.
[/quote]
It would appear so, but we are in the middle of 1.3.13 release candidates at the moment.
[quote=“TrevorPH”]
The magic switch is to change --with-libflac=system to --with-libflac=local in the %configure in the audacity.spec file
[/quote]
You mean and swap out the libflac 1.2.1 we distribute in the lib-src directory with 1.1.3?
What are the benefits of legacy FLAC?
Gale
The idea seems to be that the flac interface changed between 1.1.2 (which is what is shipped with RHEL5/CentOS5) and 1.1.3. The LEGACY_FLAC stuff is meant to allow compilation with both types of API but I don’t think it’s been tested or perhaps was tested and subsequently broken. So the benefit to me is that it might actually compile If it compiled then it would use the shared flac libraries that are already installed on my system.
I am also assuming that with --with-libflac=local it uses the copy of the flac headers and libs that are shipped with the audacity source and statically links them from lib-src/libFLAC[++].a/. At least, without building a version without stripping it that’s what I guess. Certainly the copy that I’ve built appears to have flac support and it seems to work - at least I have imported a flac file or three and exported at least one and they seem to work OK. If I run ‘ldd -v /usr/bin/audacity | grep -i flac’ then I see no external references to flac libs. If you say that the version in lib-src is 1.2.1 then I suspect that my /usr/bin/audacity includes a statically linked copy of flac 1.2.1. Probably makes it larger but if it works then I don’t much care.
I’m amazed the current release of anything works on REHL 5. Flac 1.2.1 has been out for several years, so no-one in development would ever build against anything older (or probably have access to it). The back compatibility patches were supplied by a distribution packager (who presumably couldn’t version bump libflac), but as they aren’t tested, I’m not surprised they are bitrotting. Patches to fix this are welcome …
If it compiled then it would use the shared flac libraries that are already installed on my system.