Compilation bug in standard C++ headers

English Applications
1

I’ve checked out latest FFADO code from subversion and trying to build it from source. When the build process reaches some files that include <algorithm>, we get the following error:


scons: Reading SConscript files ...

 * Usage of additional flags is not supported by the ffado-devs.
 * Use at own risk!
 *
 * Flags in use:
 *   CC = gcc
 *   CXX = g++
 *   CFLAGS = 
 *   CXXFLAGS = 
 *   LDFLAGS = 

Checking for a working C-compiler (cached) yes
Checking for a working C++-compiler (cached) yes
Checking for pkg-config (at least version 0.0.0)... (cached) yes
Checking for libxml++-3.0... (cached) no
Checking for jack... (cached) yes
Checking for jack < 1.9.0... (cached) no
Checking for jack >= 1.9.9... (cached) yes
Installed Jack Audio Connection Kit (JACK) supports FFADO setbuffersize API
Checking for libraw1394 (2.0.5 or higher)...     (cached) yes
Checking for libconfig++ (0 or higher)...     (cached) yes
Checking for libxml++-2.6 (2.13.0 or higher)...     (cached) yes
Checking for libiec61883 (1.1.0 or higher)...     (cached) yes
Checking for lrint(3.2) in C library m... (cached) yes
Checking for lrintf(3.2) in C library m... (cached) yes
Checking whether 'which pyuic4' executes (cached) yes
Checking for the python module 'dbus.mainloop.qt' (cached) yes
Checking whether 'which pyuic4' executes (cached) yes
Checking for the python module 'PyQt4' (cached) yes
Checking whether 'which pyuic5' executes (cached) yes
Checking for the python module 'PyQt5' (cached) yes
have_dbus = 1, have_pyqt4 = 1, have_pyqt5 = 1
Checking whether 'xdg-desktop-menu --help' executes (cached) yes
Checking whether 'xdg-icon-resource --help' executes (cached) yes
Checking for dbus-1 (1.0 or higher)...     (cached) yes
Checking for dbus-c++-1 (0 or higher)...     (cached) yes
Checking for alsa (0 or higher)...     (cached) yes
Checking whether 'which dbusxx-xml2cpp' executes (cached) yes
Checking for variable session_bus_services_dir in package dbus-1...     (cached) yes
Trying to find the system triple: (cached) x86_64-unknown-linux-gnu
Doing a debug build
Detected DIST_TARGET = x86_64
User space is 64-bit
Doing a 64-bit x86_64 build for AMD FX(tm)-8350 Eight-Core Processor
Will install the service-file
scons: done reading SConscript files.
scons: Building targets ...
scons: `src' is up to date.
g++ -o support/dbus/test-dbus.o -c -m64 -std=c++11 -Wall -g -fPIC -Wno-unused-but-set-variable -DDEBUG -DDEBUG_MESSAGES -DDBUS_HAS_THREADS_INIT_DEFAULT -DDBUS_API_SUBJECT_TO_CHANGE -I. -Isrc -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/dbus-c++-1 -I/usr/include/libxml++-2.6 -I/usr/lib64/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include support/dbus/test-dbus.cpp
In file included from /usr/lib64/gcc/x86_64-suse-linux/4.8/include/x86intrin.h:30:0,
                 from /usr/include/c++/4.8/x86_64-suse-linux/bits/opt_random.h:33,
                 from /usr/include/c++/4.8/random:51,
                 from /usr/include/c++/4.8/bits/stl_algo.h:65,
                 from /usr/include/c++/4.8/algorithm:62,
                 from src/ffadotypes.h:54,
                 from src/debugmodule/../fbtypes.h:27,
                 from src/debugmodule/debugmodule.h:30,
                 from support/dbus/controlclient.h:27,
                 from support/dbus/test-dbus.cpp:30:
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h: In function ‘__m64 _mm_cvtsi32_si64(int)’:
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h:61:54: error: can’t convert between vector values of different size
   return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
                                                      ^
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h: In function ‘int _mm_cvtsi64_si32(__m64)’:
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h:104:53: error: cannot convert ‘__m64 {aka int}’ to ‘__vector(2) int’ for argument ‘1’ to ‘int __builtin_ia32_vec_ext_v2si(__vector(2) int, int)’
   return __builtin_ia32_vec_ext_v2si ((__v2si)__i, 0);
                                                     ^
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h: In function ‘__m64 _mm_packs_pi16(__m64, __m64)’:
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h:143:69: error: cannot convert ‘__v4hi {aka short int}’ to ‘__vector(4) short int’ for argument ‘1’ to ‘__vector(8) char __builtin_ia32_packsswb(__vector(4) short int, __vector(4) short int)’
   return (__m64) __builtin_ia32_packsswb ((__v4hi)__m1, (__v4hi)__m2);
                                                                     ^
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h: In function ‘__m64 _mm_packs_pi32(__m64, __m64)’:
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h:158:69: error: cannot convert ‘__m64 {aka int}’ to ‘__vector(2) int’ for argument ‘1’ to ‘__vector(4) short int __builtin_ia32_packssdw(__vector(2) int, __vector(2) int)’
   return (__m64) __builtin_ia32_packssdw ((__v2si)__m1, (__v2si)__m2);
                                                                     ^
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h: In function ‘__m64 _mm_packs_pu16(__m64, __m64)’:
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h:173:69: error: cannot convert ‘__v4hi {aka short int}’ to ‘__vector(4) short int’ for argument ‘1’ to ‘__vector(8) char __builtin_ia32_packuswb(__vector(4) short int, __vector(4) short int)’
   return (__m64) __builtin_ia32_packuswb ((__v4hi)__m1, (__v4hi)__m2);
                                                                     ^
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h: In function ‘__m64 _mm_unpackhi_pi8(__m64, __m64)’:
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/mmintrin.h:187:70: error: cannot convert ‘__v8qi {aka char}’ to ‘__vector(8) char’ for argument ‘1’ to ‘__vector(8) char __builtin_ia32_punpckhbw(__vector(8) char, __vector(8) char)’
   return (__m64) __builtin_ia32_punpckhbw ((__v8qi)__m1, (__v8qi)__m2);

It seems like STL headers are incompatible with currently used out-of-box GCC.
GCC version:


gcc --version
gcc (SUSE Linux) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This also does not work under Leap 42.3. I’ve downgraded in hope that it’s not reproducible under 42.2 but it is.

2

Try to add “–std=gnu++11” to the compiler flags, like the openSUSE package does.
I.e. run something like:

scons COMPILE_FLAGS="--std=gnu++11"

Or compile it with gcc 5, 6, or 7. (5 and 6 are available in Leap 42.2 too, 7 only in 42.3), where this should be the default.

Just a guess based on what is in openSUSE’s spec file though. (and similar compiler errors I have seen in the recent past)

3

I’ve done ‘export CXX flags’. Due to some unknown reaons SCONS still decides to use c++11:


scons --config=force
scons: Reading SConscript files ...

 * Usage of additional flags is not supported by the ffado-devs.
 * Use at own risk!
 *
 * Flags in use:
 *   CC = gcc
 *   CXX = g++
 *   CFLAGS = 
 *   CXXFLAGS = -Wno-deprecated-declarations -fpermissive --std=gnu++11
 *   LDFLAGS =

And then I see:


g++ -o src/DeviceStringParser.os -c -Wno-deprecated-declarations -fpermissive --std=gnu++11 -m64 -std=c++11 -Wall -g -fPIC -fPIC -DDEBUG -DDEBUG_MESSAGES -DENABLE_BEBOB -DENABLE_FIREWORKS -DENABLE_OXFORD -DENABLE_MOTU -DENABLE_DICE -DENABLE_RME -DENABLE_GENERICAVC -I. -Isrc -I/usr/include/libxml++-2.6 -I/usr/lib64/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include src/DeviceStringParser.cpp
building 'config.h' from 'config.h.in'

–std=gnu++11 -m64 -std=c++11

In SConscript there’s nothing related to -std=c++11, I can not find why scons decides to use c++11 standard. I want even to try C++98 but how to force it not to use c++11?

4

Finally, seems that this helped:


export CXXFLAGS="-Wno-deprecated-declarations -fpermissive --std=gnu++11"
scons --config=force COMPILE_FLAGS="--std=gnu++11"
5

It’s similar in the openSUSE build log, but --std=gnu++11 comes after -std=c++11… (which is probably why it works)

Maybe try export CXXFLAGS=“–std=gnu++11” and then pass CUSTOM_ENV=True to scons.

In SConscript there’s nothing related to -std=c++11, I can not find why scons decides to use c++11 standard.

Me neither. Maybe that’s some default of scons?

And there even is: (line 355ff.)

    # libxml++-2.6 requires a c++11 compiler as of version 2.39.1.  The 
    # gnu++11 standard seems to work both with these later libxml++ versions
    # and ffado itself, although a significant number of warnings are
    # produced.  Add the necessary option to CXXFLAGS if required.
    if conf.CheckPKG('libxml++-2.6 >= 2.39.1'):
        env.Append(CXXFLAGS = '-std=gnu++11')

That’s from 2.3.0…

May I ask why you are trying to compile the latest code from subversion?
If you just want a newer version, you can install the rpm packages from multimedia:apps which are also available for Leap…
https://software.opensuse.org/search?q=ffado

6

Ah, great. :slight_smile:

7

Finally, I’ve installed source package and looked at the rpmbuild output.

Finally I’ve ended up with this build script:


#!/bin/bash

scons -c
scons --config=force -j 8 \
    PREFIX=/usr \
    LIBDIR=/usr/lib64 \
    MANDIR=/usr/share/man \
    UDEVDIR=/usr/lib/udev/rules.d \
    ENABLE_GENERICAVC=yes \
    SERIALIZE_USE_EXPAT=no \
    DEBUG=no \
    ENABLE_ALL=yes \
    PYPKGDIR=/usr/lib/python2.7/site-packages \
    ENABLE_OPTIMIZATIONS=yes \
    ENABLE_SETBUFFERSIZE_API_VER=auto \
    BUILD_TESTS=yes \
    ENABLE_DICE=true \
    COMPILE_FLAGS='-O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fno-strict-aliasing -ggdb -Wno-deprecated-declarations --std=gnu++11'

Because default build does not override installation binaries and tries to install library to /usr/local/lib.

8

Sure, that’s “normal”.

/usr/ is for distribution files, while local changes should be done in /usr/local/.
Otherwise, updates will overwrite your changes…

/usr/local/ should normally be preferred over /usr/ by the system/applications though.

If you do want to replace the stuff in /usr/, it’s probably better to build an rpm package yourself and install that.

9

No, I’m planning to make some additional device work with FFADO, so will recompile this often. So I’ll do it currently manually instead of using rpmbuild service.
Anyway, thanks for help.