If you just want a yum repository that works - https://media.librelamp.com/ - that has my Audacity for CentOS 7 packages (and fresh GStreamer and FFmpeg and VLC)
That site does not use any cookies, tracking or otherwise. Or any third party resources that track.
I don’t like distro wars, but the reason I use CentOS is two-fold. First, I use it on my servers so using CentOS 7 on my desktop lets me run the exact same LAMP stack locally. That make fixing things easier. Second, I’m in my 40s. In my 20s I liked bleeding edge, but now I prefer stable maintained without surprise surprise updates that change interfaces, introduce new bugs, and make me pull my hair out. Server LAMP stack and multimedia stack, I always go newer than what is in CentOS 7 because the newer features really are needed.
I would have been happy with older versions of Audacity that compile with GCC 4.8.x but wxWidgets for CentOS is from EPEL and EPEL is part of the Fedora, not CentOS. They update versions. They went to wxWidgets 3 which broke older Audacity. I had to build it new. But building new meant newer GCC.
I went with GCC 5.5.0 because what I need is good C++11 support. GCC 5.x has that and 5.5.0 is the most recent in that series.
But note that with C++11 - there is actually an ABI binary compatibility with libraries compiled with GCC 4.8.x and GCC 5+. That is the cause of the build frustrations with Audacity in CentOS 7.
So… create a prefix outside of /usr that you will use as an install prefix for the problem libraries. I used /opt/gcc55 just to make it very clear that what’s in their is different ABI than what is in /usr
I compiled GCC 5.5.0 from source, but what’s in the software collections is probably okay - even newer than GCC 5. When building GCC I disabled multiarch and only built for c,c++,objc,objc++ as I do not expect to be using fortran or go or java with it.
The three problem libraries that use C++11 resulting in ABI incompatibility so you can’t build Audacity:
The linux runtime loader needs to know how to find them, so create /etc/ld.so.conf.d/gcc55.conf containing the following:
# For GCC 5.5.x Shared Libraries /opt/gcc55/lib64
All the other dependencies, at least in current versions, do not use C++11 so the ABI incompatibility issue does not exist and compiled with GCC 4.8.x that CentOS 7 has works.
Compile those three libraries with the same GCC c++ you will use to build audacity and with a prefix of /opt/gcc55 (or whatever) so they don’t end up in your /usr structure. Keep /usr for stuff that is binary compatible with GCC 4.8.x.
I also built CppUnit with GCC 5.5.0 because wxGTK3 uses it in make check - and I installed that in /opt/gcc55 as well to keep it separate from the stock CppUnit.
Interestingly, make check on wxGTK3 fails if you don’t pass the
to the c++ compiler (you can put it in CXXFLAGS). That’s suppose to be default in GCC 5.5.0 but I guess it is better to just explicitly define it. I did for flac and vamp-plugin-sdk as well.
I used latest stable versions for all three:
When they are built and installed in /opt/gcc55 you can compile audacity against them, but you have to let audacity know where to find them.
For compiling audacity, set /opt/gcc55/bin at the beginning of your path so that it finds the right GCC and the right wxGTK3 configure tool.
That will tell pkgconfig to look for pkgconfig files there first (it will still look in the default locations)
When configuring audacity, give it these flags:
That makes sure it finds the right headers. And again set
I actually install Audacity with a prefix of /usr even though it is compiled with GCC 5.5.0 because it isn’t a library, so I do not have to worry about it being linked to by accident when using GCC 4.8.x - so that is safe to install in either /usr or /usr/local so you don’t have to adjust your path for it.
Here’s a link to an image of the Audacity help showing my results:
GStreamer support is disabled. That’s probably because I actually build software inside of mock and I did not BuildRequire gstreamer1-devel. I don’t know if I will change that, not sure what GStreamer offers that FFmpeg doesn’t.
So in a nutshell :
Compile GCC 5.5.0 and install it with a prefix of /opt/gcc55
Compile the three problematic libraries that themselves use C++11 standard with a prefix of /opt/gcc55
Compile audacity with a prefix of /usr (or /usr/local) but let it know about the libraries in /opt/gcc55
I do want to figure out why themes are disabled.
Would be nice to have both opus and fdk-aac support in Audacity - but not critical, export to wav and transcoding works fine. But I believe those are features that are not in Audacity itself yet. Except maybe via FFmpeg, I’ll have to try and see.
Note that for FFmpeg I used 3.4.2
From the Audacity build log:
configure: Figuring out what libraries to enable configure: Using SYSTEM libraries for EXPAT configure: Using SYSTEM libraries for FFMPEG configure: Using SYSTEM libraries for LAME configure: Using SYSTEM libraries for LIBFLAC configure: Using SYSTEM libraries for LIBID3TAG configure: Using SYSTEM libraries for LIBMAD configure: Using LOCAL libraries for LIBNYQUIST configure: Using LOCAL libraries for LIBSBSMS configure: Using SYSTEM libraries for LIBSNDFILE configure: Using SYSTEM libraries for LIBSOUNDTOUCH configure: Using SYSTEM libraries for LIBSOXR configure: Using SYSTEM libraries for LIBTWOLAME configure: Using SYSTEM libraries for LIBVAMP configure: Using SYSTEM libraries for LIBVORBIS configure: Using LOCAL libraries for LV2 configure: Using LOCAL libraries for PORTAUDIO configure: Using LOCAL libraries for PORTSMF configure: Using LOCAL libraries for PORTMIDI configure: Using LOCAL libraries for WIDGETEXTRA