i’m running into serious build-problems, whereas affected versions include 1.3.13, 1.3.14 and current from svn.
my build-system is a slackware64-current, wxwidgets 2.8.12. wxwidgets is a dedicated build from source installed to /usr/local/wxwidgets with the directory-structure of wx untouched (but that shouldn’t be relevant).
configuring is no problem, compiling breaks:
[...]
g++ -c -I../lib-src/portmixer/include -Wall -I/usr/local/wxwidgets//lib/wx/include/gtk2univ-unicode-release-2.8 -I/usr/local/wxwidgets//include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXUNIVERSAL__ -D__WXGTK__ -pthread -fpermissive -I../lib-src/FileDialog -I/usr/local/src/audacity-src-1.3.14-beta/lib-src/lib-widget-extra -I../lib-src/sbsms/include -I../lib-src/libnyquist -I../lib-src/libvamp -I../lib-src/ffmpeg -I../lib-src/portsmf -I../lib-src/portaudio-v19/include -fno-strict-aliasing -I./include -I. -DLIBDIR="/usr/local/audacity/lib" -D__STDC_CONSTANT_MACROS -Wall -pthread -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/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 DirManager.cpp -o DirManager.o
In file included from DirManager.cpp:88:0:
AudacityApp.h:207:4: error: 'wxLocale' does not name a type
In file included from WaveTrack.h:17:0,
from BlockFile.h:19,
from DirManager.cpp:89:
WaveClip.h:57:1: warning: type attributes ignored after type is already defined
make[1]: *** [DirManager.o] Error 1
make[1]: Leaving directory `/usr/local/src/audacity-src-1.3.14-beta/src'
make: *** [audacity] Error 2
without analyzing code i would say it’s a missing include somewhere.
Does Slackware have separate -dev packages? If so did you install the -dev package of libGTK and libwxGTK?
no, slackware doesn’t use *-dev packages; it packs everything needed into the regular packages directly.
Any reason you are not using system wxGTK?
yeah, slackware doesn’t ship wx*
furthermore i compile the “big frameworks” (just like wxwidgets, qt, etc.) myself anyway (to strip unnecessary components, to compile arch-dependent/cpu-dependent, to have multiple versions running for testing and coding-purposes, …).
Sorry, I don’t think I know what the problem is unless someone else here does. It’s not a general problem.
It may be best if you e-mail the developers’ mailing list (see “Using audacity devel” here ). You’re meant to subscribe, but if you write from the address with which you are registered on the Forum, I’ve arranged for you to post.
The ghostly wind does blow as tumble-weed rolls across the desolate street.
Sorry, no ideas from me either. Hopefully one of the developers will recognise the problem.
I’m no Linux guru, but I googled “error: ‘wxLocale’ does not name a type” and found lots of others are having the same problem with Slackware and wxWidgets. I had similar (but not with wxLocale–may not have been building project locale, it is off by default on Windows) problems when I recently moved to compiling Audacity with MS VC++ 2010 (Audacity does not build out-of-the-box on anything newer than VC++ 2008). The problem was that the newest C++ compilers are much more strict in forcing compliance. Something like:
well, this ain’t a slackware-specific problem. i also found similar problems for gentoo or arch people e.g… we all have in common, that we’re rolling release distris with bleeding edge (but stable) software. so of course we use latest gcc, latest glibc and so on. changing the compiler is definitely no option at all; no one would even think about that.
i guess the wx-lists AND the audacity-lists are the right place for this problem (unless somebody has a tip in here :)). wx because these guys potentially didn’t manage to write correct/compliant code (which is absolutely their job) and audacity because the autoconf-scripts of audacity should detect the “quirks” (let’s call it that way, although it’s just the right behavoir) and set additional compiletime-flags for gcc OR because audacity code needs some additional ifdefines for recent libs and compilers.
i’ll write to the lists next week.
i’ll also try to compile audacity against wxwidgets’ unstable branch; maybe the code has already been corrected (last wx-stable release is 3/4 year old). (did anyone already try wx 2.9 with audacity?)
i have only a little time atm, but maybe i’ll find a minute during holidays to do some code-analysis and write some patches for wx and/or audacity.
Team Audacity is especially resistant to “bleeding-edge”! You think you have it bad? They will not even support the two most recent releases of Microsoft’s Visual Studio (2010 and the new version 11–probably will be called 2012) insisting that only MS VC++ 2008 is supported. I understand this as the “bugs” in Audacity code which are exposed by the newer compilers are a hassle to fix, see: https://forum.audacityteam.org/t/success-compiling-audacity-with-vs2010/21762/1
Thanks, Edgar. Yes I saw that too, but I guessed Lightning was at the “bleeding edge” and compiling Audacity with later Widgets won’t work “as is” (and as you say Team won’t be interested in moving to latest Widgets right now).
You might get some sympathy from -devel list; I would argue that Audacity “should” compile with 2.8.12 even with latest compilers (if that is the problem).