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=tag=*devtoolset*el6*
Thanks. Should we report the packages missing from "vault" somewhere?
___
CentOS
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:
>>>
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
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"
On Sun, Feb 5, 2017 at 11:43 PM, Gordon Messmer
wrote:
> 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/
The source RPMs for devtoolset don't appear to be
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.
> >
> > 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.
>
>
On 02/08/2017 07:35 PM, Kenneth Porter wrote:
--On Wednesday, February 08, 2017 7:25 PM -0800 Alice Wonder
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
--On Wednesday, February 08, 2017 7:25 PM -0800 Alice Wonder
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
On 02/08/2017 06:05 PM, Kenneth Porter wrote:
--On Tuesday, February 07, 2017 2:33 PM -0800 Alice Wonder
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
--On Tuesday, February 07, 2017 2:33 PM -0800 Alice Wonder
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,
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
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
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
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
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,
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
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
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/
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
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:
21 matches
Mail list logo