Building audio analysis library Essentia failed with Gaia support - c++

I am trying to build Essentia (https://github.com/MTG/essentia), an audio analysis library, with Gaia (https://github.com/MTG/gaia) support in Debian 9.0 from source. Before that, one of its dependencies, namely Gaia, was successfully built, also, from source. It was installed in /usr/local/.
When it comes to Essentia, compilation of sources fails with the following errors:
[...]
In file included from ../src/algorithms/essentia_algorithms_reg.cpp:21:0:
../src/algorithms/highlevel/gaiatransform.h: At global scope:
../src/algorithms/highlevel/gaiatransform.h:37:10: error: ‘TransfoChain’ in namespace ‘gaia2’ does not name a type
gaia2::TransfoChain _history;
^~~~~~~~~~~~
../src/algorithms/highlevel/gaiatransform.h: In constructor ‘essentia::standard::GaiaTransform::GaiaTransform()’:
../src/algorithms/highlevel/gaiatransform.h:47:5: error: ‘init’ is not a member of ‘gaia2’
gaia2::init();
^~~~~
../src/algorithms/highlevel/gaiatransform.h:47:5: note: suggested alternative:
In file included from ../src/essentia/algorithmfactory.h:27:0,
from ../src/algorithms/essentia_algorithms_reg.cpp:1:
../src/essentia/essentia.h:46:6: note: ‘essentia::init’
void init();
^~~~
The file where the error lies is /src/algorithms/essentia_algorithms_reg.cpp and here is the command which the file is compiled with:
/usr/bin/g++ -pipe -Wall -std=c++03 -msse -msse2 -mfpmath=sse -O2 -fPIC -pthread -Isrc -I../src -Isrc/essentia -I../src/essentia -Isrc/essentia/scheduler -I../src/essentia/scheduler -Isrc/essentia/streaming -I../src/essentia/streaming -Isrc/essentia/streaming/algorithms -I../src/essentia/streaming/algorithms -Isrc/essentia/utils -I../src/essentia/utils -Isrc/3rdparty -I../src/3rdparty -Isrc/3rdparty/spline -I../src/3rdparty/spline -Isrc/3rdparty/vamp-plugin-sdk-2.4 -I../src/3rdparty/vamp-plugin-sdk-2.4 -I/usr/include/x86_64-linux-gnu -I/usr/include/taglib -I/usr/local/include -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/local/include/gaia2/ -DHAVE_AVCODEC=1 -DHAVE_AVFORMAT=1 -DHAVE_AVUTIL=1 -DHAVE_AVRESAMPLE=1 -DHAVE_SAMPLERATE=1 -DHAVE_TAGLIB=1 -DHAVE_YAML=1 -DHAVE_FFTW=1 -DHAVE_GAIA2=1 -D__STDC_CONSTANT_MACROS -DPYTHONDIR="/usr/local/lib/python2.7/dist-packages" -DPYTHONARCHDIR="/usr/local/lib/python2.7/dist-packages" -DHAVE_PYEMBED=1 -DHAVE_PYEXT=1 -DHAVE_PYTHON_H=1 ../src/algorithms/essentia_algorithms_reg.cpp -c -o/home/hamidi/essentia/build/src/algorithms/essentia_algorithms_reg.cpp.1.o -fPIC -v
g++'s -v option gave me the actual paths visited by the linker (nothing bad in there, I think, but for the sake of completeness):
#include "..." search starts here:
#include <...> search starts here:
src
../src
src/essentia
../src/essentia
src/essentia/scheduler
../src/essentia/scheduler
src/essentia/streaming
../src/essentia/streaming
src/essentia/streaming/algorithms
../src/essentia/streaming/algorithms
src/essentia/utils
../src/essentia/utils
src/3rdparty
../src/3rdparty
src/3rdparty/spline
../src/3rdparty/spline
src/3rdparty/vamp-plugin-sdk-2.4
../src/3rdparty/vamp-plugin-sdk-2.4
/usr/include/taglib
/usr/include/qt4
/usr/include/qt4/QtCore
/usr/local/include/gaia2/
/usr/include/c++/6
/usr/include/x86_64-linux-gnu/c++/6
/usr/include/c++/6/backward
/usr/lib/gcc/x86_64-linux-gnu/6/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
Here are the files (github repo) involved in the error:
MTG/gaia/blob/master/src/gaia.h
MTG/gaia/blob/master/src/transformation.h#L106
/MTG/essentia/blob/master/src/algorithms/highlevel/gaiatransform.h

It is finally an error that occurred while configuring Gaia that caused the problem. Actually, rather than using merely the following options for configuration:
./waf configure --with-python-bindings --with-asserts --with-cyclops
the option --with-stlfacade was added by inadvertence. This option is not compatible when using Gaia in conjunction with Essentia.

Related

Can't compile a simple c++ file with g++ on MacOS 13, XCode 14

I'm on a new M2 Mac Mini. I have this simple test c++ file:
% cat conftest.cpp
#include <limits>
#include <cmath>
#include <algorithm>
int main(int argc, char **argv) { return 0;}
I need to compile it with c++ rather than clang++ (the actual problem is building a conan dependency that does this, so I can't easily switch it).
I have XCode 14.2 (latest, I think) and this c++
% g++ --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
From my reading, I know that since Catalina XCode's g++ doesn't automatically find the standard header and lib dirs the way clang does on Mac, so I think I need to set CPATH and LIBPATH.
% echo $LIBRARY_PATH
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
% echo $CPATH
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
Unfortunately, compiling this gives an error, which appears to be a conflict between cmath and algorithm because removing either of those makes it compile and link OK:
% /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ conftest.cpp
In file included from conftest.cpp:4:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:653:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional:499:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional/bind_back.h:15:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional/perfect_forward.h:17:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/tuple:159:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional_base:22:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/exception:83:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cstdlib:130:9: error: target of using declaration conflicts with declaration already in scope
using ::abs _LIBCPP_USING_IF_EXISTS;
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdlib.h:132:6: note: target of using declaration
int abs(int) __pure2;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:338:1: note: conflicting declaration
using ::abs _LIBCPP_USING_IF_EXISTS;
^
I must be missing something simple. That test program compiles and runs fine on godbolt and Windows. Any ideas, anyone?
The issue here is one of wrapping. When you invoke the toolchain compiler directly, it uses a specific set of headers for the toolchain itself, and omits the headers for the platform. When we use -### to see all the include paths specified for the toolchain compiler, we see the following from the direct toolchain compiler:
So compiling with /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++:
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1"
"/usr/local/include"
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include"
"/usr/include"
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include"
Compiling with the /usr/bin/c++ wrapper, we get the following headers:
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"
"-I/usr/local/include"
"-stdlib=libc++"
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1"
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include"
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include"
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include"
It's adding in the headers for macOS, because it assumes it's building for MacOS, because it's the local wrapper.
We can successfully compile using the toolchain compiler, when we pass in an additional -isysroot option as extracted using:
-isysroot $(xcrun --sdk macosx --show-sdk-path)
so:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -isysroot $(xcrun --sdk macosx --show-sdk-path) -o conftest conftest.cpp
builds and runs cleanly. In the case of trying to get dependencies to build properly you're going to need to pick the appropriate compiler for the target.
If you want to work around building, the two variables that matter in this case are generally CPPFLAGS and CXXFLAGS - flags for the preprocessor and C++ compiler. You should be able to set CPPFLAGS to:
-isysroot $(xcrun --sdk macosx --show-sdk-path)
and it should build for you, if the standard makefile logic is in effect in the tools you're using.
$ export CPPFLAGS="-isysroot $(xcrun --sdk macosx --show-sdk-path)"
$ export CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
$ make conftest
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk conftest.cpp -o conftest

Controlling scons environment checking options

I'm trying to build mongodb (open source version 4.2) which uses python and scons for building. The problem relates to scons rather than mongodb.
My build fails very early with Couldn't find OpenSSL crypto.h header and library. Verbose details are:
file /.../SConstruct,line 3042:
Configure(confdir = build/scons/opt/sconf_temp)
scons: Configure: Checking for SSLeay_version(0) in C library crypto...
build/scons/opt/sconf_temp/conftest_d6743137aeb7fb2674cc9632f9989034_0.c <-
|
|
|#include "openssl/crypto.h"
|
|int
|main() {
| SSLeay_version(0);
|return 0;
|}
|
gcc -o build/scons/opt/sconf_temp/conftest_d6743137aeb7fb2674cc9632f9989034_0.o -c -std=c11 -ffp-contract=off -fno-omit-frame-pointer -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -O2 -Wno-unused-local-typedefs -Wno-unused-function -Wno-deprecated-declarations -Wno-unused-const-variable -Wno-unused-but-set-variable -Wno-missing-braces -Wno-exceptions -fstack-protector-strong -fno-builtin-memcmp -fPIE -DNDEBUG -D_XOPEN_SOURCE=700 -D_GNU_SOURCE build/scons/opt/sconf_temp/conftest_d6743137aeb7fb2674cc9632f9989034_0.c
cc1: error: command-line option '-Wno-exceptions' is valid for C++/ObjC++ but not for C [-Werror]
cc1: all warnings being treated as errors
scons: Configure: no
I'm using Arch Linux which has multiple OpenSSL packages, and the default 3.0 is not compatible with mongodb source. I also have OpenSSL 1.1 and 1.0 installed, and can switch with e.g. gcc -I/usr/include/openssl-1.1.
Unfortunately I have not found a way to instruct SConstruct to use this flag in the command lines it generates to check the environment. I have tried CFLAGS, CCFLAGS, CPPPATH both as environment variables and scons command line parameters.
I also tried reverse enginering it, and tracked this to Conftest and TryBuild but it's not obvious how I can influance theses from the command line, so I'm trying my luck with you guys before going deeper in scons code.
If you look at the SConstruct and search for openssl, you'll find this blurb under the logic to detect on macOS
NOTE: Recent versions of macOS no longer ship headers for the system OpenSSL libraries.
NOTE: Either build without the --ssl flag, or describe how to find OpenSSL.
NOTE: Set the include path for the OpenSSL headers with the CPPPATH SCons variable.
NOTE: Set the library path for OpenSSL libraries with the LIBPATH SCons variable.
NOTE: If you are using HomeBrew, and have installed OpenSSL, this might look like:
\tscons CPPPATH=/usr/local/opt/openssl/include LIBPATH=/usr/local/opt/openssl/lib ...
NOTE: Consult the output of 'brew info openssl' for details on the correct paths."""
I'd bet if you did the same but pointed at the proper locations on your system for the openssl libs and header files, you'd be able to build.
(see: https://github.com/mongodb/mongo/blob/r4.2.0/SConstruct#L3015 )

failed to compile debug in wxwidgets windows 10

I want to develop apps across multiple platform. I am new with wxwidgets. I want to compile debug but it produce an error. this is my command result. please help me. so far i've done apps using wpf mvvm c# but it can only be run in windows env. so i'm changing to c++ knowing that it can be compiled in any environment. please help me.
C:\wxWidgets-3.0.2\build\msw>mingw32-make SHELL=CMD.exe -f makefile.gcc USE_XRC=1 BUILD=debug UNICODE=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-fno-keep-inline-dllexport"
if not exist ..\..\lib\gcc_dll\mswud mkdir ..\..\lib\gcc_dll\mswud
g++ -c -o gcc_mswuddll\monodll_any.o -g -O0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE -I..\..\lib\gcc_dll\mswud -I..\..\include -W -Wall -DWXBUILDING -I..\..\src\tiff\libtiff -I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex -I..\..\src\expat\lib -I..\..\src\stc\scintilla\include -I..\..\src\stc\scintilla\lexlib -I..\..\src\stc\scintilla\src -D__WX__ -DSCI_LEXER -DLINK_LEXERS -DwxUSE_BASE=1 -DWXMAKINGDLL -Wno-ctor-dtor-privacy -fno-keep-inline-dllexport -MTgcc_mswuddll\monodll_any.o -MFgcc_mswuddll\monodll_any.o.d -MD -MP ../../src/common/any.cpp
In file included from C:/TDM-GCC-32/lib/gcc/mingw32/5.1.0/include/c++/type_traits:35:0,
from ..\..\include/wx/strvararg.h:25,
from ..\..\include/wx/string.h:46,
from ..\..\include/wx/any.h:19,
from ../../src/common/any.cpp:18:
C:/TDM-GCC-32/lib/gcc/mingw32/5.1.0/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
In file included from ..\..\include/wx/string.h:46:0,
from ..\..\include/wx/any.h:19,
from ../../src/common/any.cpp:18:
..\..\include/wx/strvararg.h:350:18: error: 'is_enum' in namespace 'std' does not name a template type
typedef std::is_enum<T> is_enum;
^
..\..\include/wx/strvararg.h:354:54: error: 'is_enum' was not declared in this scope
enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value };
^
..\..\include/wx/strvararg.h:354:68: error: template argument 1 is invalid
enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value };
^
makefile.gcc:6428: recipe for target 'gcc_mswuddll\monodll_any.o' failed
mingw32-make: *** [gcc_mswuddll\monodll_any.o] Error 1
C:\wxWidgets-3.0.2\build\msw>
Have you been following the usual build instructions without any changes? Something exceedingly strange is happening, as HAVE_TYPE_TRAITS is somehow defined for you (look at the condition in the file wx/strvararg.h just above the line that the error points you to), yet this shouldn't be the case with the unmodified wxWidgets sources because it's only defined when using C++11, i.e. when __cplusplus >= 201103L, yet the compiler you use (g++ 5.1) defines __cplusplus as 199711L by default.
If you had tried to build it differently, e.g. using configure, you must clean everything before building it again, i.e. just destroy the entire source directory and re-expand the archive if you had downloaded it or do git clean -fdx if you had cloned the Git repository.
You'll need to set the C++ standard to 11. Add -std=c++11 to your compile command line (I didn't paste the whole line as it's very long.):
mingw32-make SHELL=CMD.exe -f makefile.gcc -std=c++11 USE_XRC=1 BUILD=debug U...

--with-sysroot is not honored during a compile on OS X?

I have a C++ project. I am testing a cross-compile with Autotools on OS X for iOS. I configure with:
$ echo $IOS_SYSROOT
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk
$ CXXFLAGS="-DNDEBUG -g2 -O3 -arch arm64" ./configure --with-sysroot="$IOS_SYSROOT" --build=`config.guess` --host=aarch64-ios
When make'ing it results in (line breaks added for clarity):
libtool: compile: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-DHAVE_CONFIG_H -I. ... -DNDEBUG -g2 -O3 -arch arm64 -MT adhoc.lo -MD -MP -MF .deps/adhoc.Tpo -c adhoc.cpp -o adhoc.o
In file included from adhoc.cpp:2:
In file included from /usr/include/c++/4.2.1/iosfwd:44:
In file included from /usr/include/c++/4.2.1/bits/c++config.h:41:
In file included from /usr/include/c++/4.2.1/bits/os_defines.h:61:
In file included from /usr/include/unistd.h:71:
In file included from /usr/include/_types.h:27:
In file included from /usr/include/sys/_types.h:32:
/usr/include/sys/cdefs.h:658:2: error: Unsupported architecture
#error Unsupported architecture
...
Notice the wrong header files are being used. The build system's headers are used rather than the iPhone headers. I'm fairly certain --with-sysroot is not being honored. Searching for the keywords seems to indicate its a widespread problem with Autoconf (based on all the bug reports trying to use the feature).
Manually adding CXXFLAGS="-sysroot=$IOS_SYSROOT -arch arm64 ... seems to fix the issue. This seems to be the same problem (or nearly the same problem) detailed at Bug 79885: --with-build-sysroot= does not get honored throughout the build.
There does not seem to be a AC_SYSROOT (or similar) to copy --with-sysroot into AM_CXXFLAGS. Searching the Autoconf site for the keywords is not returning useful hits: "--with-sysroot" site:https://www.gnu.org/software/autoconf/manual.
How are we supposed to handle Autoconf's --with-sysroot option? What is the practice packagers are supposed to follow?
Here are the Autoconf prject files: cryptopp-autotools. There are two files of interest, and they are configure.ac and Makefile.am. I'm not sure what applies to this problem at the moment.
Here's the message where Autoconf tells users to use it:
$ ./configure --help | grep sysroot
--with-sysroot[=DIR] Search for dependent libraries within DIR (or the
compiler's sysroot if not specified).
I'd prefer to supress the message if Autoconf cannot wire-in --with-sysroot properly. Otherwise, users are going to be filling bug reports against us.

AC_CHECK_HEADER fail if the header install path has api in it

One of the header file for example BamReader.h from the bamtools package is install at
/usr/local/include/bamtools/api
I have tried to set the include flag to either:
CXXFLAGS="$CXXFLAGS -I/usr/local/include/bamtools"
or
CXXFLAGS="$CXXFLAGS -I/usr/local/include/bamtools/api"
AC_CHECK_HEADERS([BamReader.h], [bamtools_found=yes], [AC_MSG_ERROR([Unable to find bambools header])])
If I check the config.log file, the first one gave me an error:
configure:3837: g++ -c -g -O2 -I/usr/local/include/bamtools conftest.cpp >&5
conftest.cpp:54:23: fatal error: BamReader.h: No such file or directory
compilation terminated.
The second gave me the following error:
configure:3837: g++ -c -g -O2 -I/usr/local/include/bamtools/api conftest.cpp >&5
In file included from conftest.cpp:54:0:
/usr/local/include/bamtools/api/BamReader.h:13:28: fatal error: api/api_global.h: No such file or directory
#include "api/api_global.h"^M
^
compilation terminated.
configure:3837: $? = 1
The problem is with BamReader.h trying to include api/api_global.h
I got a simple fix by putting the api into the AC_CHECK_HEADERS the it worked.
CXXFLAGS="$CXXFLAGS -I/usr/local/include/bamtools"
AC_CHECK_HEADERS([api/BamReader.h], [bamtools_found=yes], [AC_MSG_ERROR([Unable to find bambools header])])
configure output
checking api/BamReader.h usability... yes
Essentially, you have to use the library by appending api/ to every header. Please comment: is this a good practice?