GCC 4.9 In CentOS 7 ??

Home » CentOS » GCC 4.9 In CentOS 7 ??
CentOS 20 Comments

The following features of the C++11/C++14 standards are not supported by g++:
* std::make_unique function (C++14)
* digit separators (C++14)
* binary literals (C++14)
* generic lambdas (C++14)
If you are using the GNU C compiler collection (gcc) then you need at least v4.9.x. configure: error: support for required C++11/C++14 features incomplete

Is there by chance a compat package for gcc 4.9.x available?

I didn’t see it in a yum list.

I’m trying to build the latest mkvtoolnix and it looks like CentOS 7 gcc is just barely too old :-/

20 thoughts on - GCC 4.9 In CentOS 7 ??

  • There are three ways to utilize SCLs: a temporary subshell invoked with the scl utility, a session-long environment shift by sourcing the package’s ‘enable’ script, or a permanent alteration of your shell profile to include the package’s bin/ and lib/ directories.

    I outline the first two methods in a blog post you may find helpful:

    https://www.madboa.com/blog/2016/08/29/scl-intro/

    (There’s no advertising on my site and I make no revenue from it.)

  • Hello guys..

    or you dig it up by hand and use

    environment-modules

    In our cluster I prepaired my self to do it step by step, because we need the binary as rpm (because of dependency)
    to pull it onto the cluster nodes, but this takes a lot of time.

    Sincerely

    Andy

    Am Sonntag, den 05.02.2017, 22:43 -0800 schrieb Gordon Messmer:

  • Yeah, I’m not fond of the new model for building packages by doing a git checkout to get the spec files and sources and other stuff.

    The software collections looks like it might interfere with some of my own packaging (repos that build upon EPEL to provide modern server stack based on LibreSSL and a repo for modern multimedia)

    I did find the newer gcc src.rpm but it looks like it has a lot of build dependencies also part of the software collection model, so I think I
    just have to accept that latest mkvtools are not for me.

  • Where do you see a conflict? Those packages are structured to avoid conflict with the base platform, but installing into an alternate root
    (/opt/rh/) and are normally active only when specifically enabled in a login session. That is, they’re available when wanted but don’t affect the system when they aren’t.

  • What I mean is conflicts in devel packages.

    What I mean is this – my LibreSSL package installs in /usr and not in
    /opt and that is intentional, so that it is not possible to have both opennsl-devel and libressl-devel installed at the same time, since they both are the same API.

    Here’s why –

    If I build php against LibreSSL but some some of the PHP build dependencies are built against OpenSSL then those build dependencies will want openssl-devel.

    If both openssl-devel and libressl-devel are /usr then the packages will conflict and I know I have to rebuild the PHP build dependencies against LibreSSL before I can build PHP.

    But if LibreSSL was in /opt then RPM would have no problem having both libressl-devel and openssl-devel installed at the same time, and the build of PHP could potentially result in mixed implementation of the OpenSSL API – e.g. PHP is linked against LibreSSL but also is linked against Net-SNMP which is linked against OpenSSL – so that the dynamic loader then loads two shared libraries that provide the same API.

    That’s what I am trying to avoid, and that is easiest to avoid by just using /usr as the prefix so that devel files have their headers in
    /usr/include and devel files for different implementations of the same API can not be installed at the same time.

  • None of that is particularly relevant. There are only 3 “devel”
    packages in the devtoolset-4 collection, and those are only for the developer tools. Using that collection for gcc, especially if you’re only using that compiler for one package, isn’t going to create the conflicts you’re describing.

  • –That’s the very problem that Software Collections endeavors to solve. If you install a non-standard package that conflicts with OS defaults, install it as a collection so that end users can choose whether to use the enhancement or the default, on a per-session basis.

    Does Net-SNMP expose the libraries and API it depend on? Does the loader only link on API signature or does it also look at the library name? Does Net-SNMP fail if it was built against OpenSSL but is loaded with LibreSSL?

  • Does that mean you end up needing to manage crazy long PATH variables?

    As far as I can tell PHP built against LibreSSL works just fine running with the net-snmp bindings built against OpenSSL however there was a warning in the system log from ld when I tried it.

  • What I really worry about is bugs in makefiles – if I have openssl-devel installed in /usr to satisfy the net-snmp-devel package, and I have libressl-devel installed on /opt – what happens if a Makefile gets confused when parsing the pkgconfig files or something and uses the wrong header files for the libraries it is linking against.

    That’s why I want to make sure only one devel package for an API is installed at a time, and that’s easiest to do by always using /usr as the prefix so that if dependencies are brought in by the mock build system that result in two implementations of the same API, they will conflict with each other and mock will exit.

    For the runtime I’m not that worried, the shared libraries have different versions.

    It’s building where bugs in Makefile systems could cause the wrong headers being used.

  • Manage in what way?

    The SCL can be used in a number of ways. Most people do it by invoking a shell preconfigured with the correct environment by doing something like

    scl enable devtoolset-3 bash

    exiting out of the shell obviously restores your original environment. You can start programs other than a shell in the same way.

    There is also the option of running the collection’s enable script to set up the environment in the current shell. e.g.

    /opt/rh/devtoolset-3/enable

    but there is no easy of removing the environment other than restarting the shell.

    There’s information on the RH website about software collections and how to package things properly and how to convert spec files etc. etc.

    P.

  • Thx, this is very clear and helpful. My question is, what is needed to build rpms against such scl packages?
    Any documentation or examples somewhere?

    Am 06.02.2017 um 18:38 schrieb Paul Heinlein:

  • Not only are all the devtoolset SRPMS there, so are all of the build requirements that are not in the other location .. and if you want, every build log (and build root log) for any built SRPM so you can see the exact packages in the build root, etc.

LEAVE A COMMENT