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 :-/
On 02/05/2017 05:33 PM, Alice Wonder wrote:
Is there by chance a compat package for gcc 4.9.x available?
Yes. Use the software collections.
https://www.softwarecollections.org/en/
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/
yum install centos-release-scl && yum install devtoolset-4
On 02/05/2017 05:46 PM, Gordon Messmer wrote:
On 02/05/2017 05:33 PM, Alice Wonder wrote:
Is there by chance a compat package for gcc 4.9.x available?
Yes. Use the software collections.
https://www.softwarecollections.org/en/
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/
yum install centos-release-scl && yum install devtoolset-4
Where are src.rpm's ?
The source link brings me to a github
On 02/05/2017 06:37 PM, Alice Wonder wrote:
Where are src.rpm's ?
Same place as everything else:
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:
On 02/05/2017 06:37 PM, Alice Wonder wrote:
Where are src.rpm's ?
Same place as everything else:
http://vault.centos.org/7.3.1611/sclo/Source/
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
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.
On 02/06/2017 01:46 PM, Andreas Benzler wrote:
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:
On 02/05/2017 06:37 PM, Alice Wonder wrote:
Where are src.rpm's ?
Same place as everything else:
http://vault.centos.org/7.3.1611/sclo/Source/
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 02/07/2017 01:42 AM, Alice Wonder wrote:
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)
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/<package collection>) 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.
On 02/07/2017 07:34 AM, Gordon Messmer wrote:
On 02/07/2017 01:42 AM, Alice Wonder wrote:
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)
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/<package collection>) 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.
On 02/07/2017 02:33 PM, Alice Wonder wrote:
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.
--On Tuesday, February 07, 2017 2:33 PM -0800 Alice Wonder alice@domblogger.net wrote:
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.
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.
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.
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?
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 02/08/2017 06:05 PM, Kenneth Porter wrote:
--On Tuesday, February 07, 2017 2:33 PM -0800 Alice Wonder alice@domblogger.net wrote:
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.
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 that mean you end up needing to manage crazy long PATH variables?
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.
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?
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.
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
--On Wednesday, February 08, 2017 7:25 PM -0800 Alice Wonder alice@domblogger.net wrote:
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.
There should only be a problem if Net-SNMP depends on bugs in the OpenSSL implementation.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 02/08/2017 07:35 PM, Kenneth Porter wrote:
--On Wednesday, February 08, 2017 7:25 PM -0800 Alice Wonder alice@domblogger.net wrote:
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.
There should only be a problem if Net-SNMP depends on bugs in the OpenSSL implementation.
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.
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 that mean you end up needing to manage crazy long PATH variables?
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.
On Sun, Feb 5, 2017 at 11:43 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 02/05/2017 06:37 PM, Alice Wonder wrote:
Where are src.rpm's ?
Same place as everything else:
The source RPMs for devtoolset don't appear to be there, but I did find them here: http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHSCL/SRPMS/
On 02/16/2017 04:45 PM, Dave Johansen wrote:
The source RPMs for devtoolset don't appear to be there, but I did find them here: http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHSCL/SRPMS/
Possibly a result of an unspecified "accident"
https://lists.centos.org/pipermail/centos-devel/2017-February/015676.html
On 02/16/2017 09:21 PM, Gordon Messmer wrote:
On 02/16/2017 04:45 PM, Dave Johansen wrote:
The source RPMs for devtoolset don't appear to be there, but I did find them here: http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHSCL/SRPMS/
Possibly a result of an unspecified "accident"
https://lists.centos.org/pipermail/centos-devel/2017-February/015676.html
indeed .. but everything that ends up released for devtoolset (or any other scl items) are built in the Community Build System.
Here are where all the builds for EL6 devtoolset live:
http://cbs.centos.org/koji/search?match=glob&type=tag&terms=*devtool...
On 02/17/2017 06:25 AM, Johnny Hughes wrote:
On 02/16/2017 09:21 PM, Gordon Messmer wrote:
On 02/16/2017 04:45 PM, Dave Johansen wrote:
The source RPMs for devtoolset don't appear to be there, but I did find them here: http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHSCL/SRPMS/
Possibly a result of an unspecified "accident"
https://lists.centos.org/pipermail/centos-devel/2017-February/015676.html
indeed .. but everything that ends up released for devtoolset (or any other scl items) are built in the Community Build System.
Here are where all the builds for EL6 devtoolset live:
http://cbs.centos.org/koji/search?match=glob&type=tag&terms=*devtool...
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.
On 02/17/2017 04:25 AM, Johnny Hughes wrote:
Here are where all the builds for EL6 devtoolset live: http://cbs.centos.org/koji/search?match=glob&type=tag&terms=*devtool...
Thanks. Should we report the packages missing from "vault" somewhere?
On Sun, 5 Feb 2017, Gordon Messmer wrote:
Yes. Use the software collections.
https://www.softwarecollections.org/en/
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/
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.)
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:
On Sun, 5 Feb 2017, Gordon Messmer wrote:
Yes. Use the software collections.
https://www.softwarecollections.org/en/
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/
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.)
-
Alice Wonder -
Andreas Benzler -
Dave Johansen -
Gordon Messmer -
Johnny Hughes -
Kenneth Porter -
Paul Heinlein -
Pete Biggs -
Rainer Traut