Results 1 to 9 of 9

Thread: Compilation bug in standard C++ headers

  1. #1

    Angry Compilation bug in standard C++ headers

    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:

    Code:
    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:
    Code:
    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. #2

    Default : Compilation bug in standard C++ headers

    Try to add "--std=gnu++11" to the compiler flags, like the openSUSE package does.
    I.e. run something like:
    Code:
    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)
    Last edited by wolfi323; 17-Jan-2018 at 06:27.

  3. #3

    Angry Re: Compilation bug in standard C++ headers

    I've done 'export CXX flags'. Due to some unknown reaons SCONS still decides to use c++11:
    Code:
    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:
    Code:
    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. #4

    Thumbs up Re: Compilation bug in standard C++ headers

    Finally, seems that this helped:
    Code:
    export CXXFLAGS="-Wno-deprecated-declarations -fpermissive --std=gnu++11"
    scons --config=force COMPILE_FLAGS="--std=gnu++11"

  5. #5

    Default Re: Compilation bug in standard C++ headers

    Quote Originally Posted by v_sadko4u View Post
    I've done 'export CXX flags'. Due to some unknown reaons SCONS still decides to use c++11:

    And then I see:

    --std=gnu++11 -m64 -std=c++11
    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.)
    Code:
        # 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
    Last edited by wolfi323; 17-Jan-2018 at 06:50.

  6. #6

    Default Re: Compilation bug in standard C++ headers

    Quote Originally Posted by v_sadko4u View Post
    Finally, seems that this helped:
    Code:
    export CXXFLAGS="-Wno-deprecated-declarations -fpermissive --std=gnu++11"
    scons --config=force COMPILE_FLAGS="--std=gnu++11"
    Ah, great.

  7. #7

    Lightbulb Re: Compilation bug in standard C++ headers

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

    Finally I've ended up with this build script:
    Code:
    #!/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. #8

    Default Re: Compilation bug in standard C++ headers

    Quote Originally Posted by v_sadko4u View Post
    Because default build does not override installation binaries and tries to install library to /usr/local/lib.
    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. #9

    Cool Re: Compilation bug in standard C++ headers

    Quote Originally Posted by wolfi323 View Post
    If you do want to replace the stuff in /usr/, it's probably better to build an rpm package yourself and install that.
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •