build/ops: use devtoolset-7 on centos/rhel-7 #18863
Conversation
|
see also ceph/ceph-build#909 |
tchaikov
force-pushed
the
wip-devtoolset-7
branch
from
7c9b9ff
to
6f4ed6c
Compare
src/CMakeLists.txt
Outdated
| " HAVE_GLIBCXX_5_1) | ||
| if(NOT HAVE_GLIBCXX_5_1) | ||
| # libc++'s list::size() is O(1) also. | ||
| message(WARNING "performance regression is expected due to an O(n) implementation of 'std::list::size()' in libstdc++ older than 5.1.0") |
There was a problem hiding this comment.
should this change to ERROR then?
There was a problem hiding this comment.
then, we need to use ubuntu-toolchain-r ppa repo on trusty.
There was a problem hiding this comment.
Wait, Mimic will still support trusty?
There was a problem hiding this comment.
Hmm, I'm not sure we've discussed it. Is trusty the only one that is problematic here? I would very happily drop trusty!
There was a problem hiding this comment.
b/c xenial comes with gcc 5.3, and centos7 will be using devtoolset-7, (hope @ktdreyer is fine with this). and current debian stable (stretch) offers gcc 6.3. the debian's old stable (jessie) offers gcc 4.9. SLE 11 has gcc-6.
but i don't think serious user of centos/rhel 7 and debian jessie would ignore the performance regression warning and continue using whatever the toolchain the distro offers.
so the only blocker is ubuntu trusty. and it's fixable, we just need to update the pbuilderrc script and set the DEB_CC and DEB_CXX env variables. i am still looking into this.
but if we can drop the trusty, that'd be easier.
There was a problem hiding this comment.
Let's drop trusty.
Would you please not use devtoolset-7 until we can discuss it directly with the team at Red Hat that maintains that? There is no published EOL date for that, so it could become unsupported at any time, and their security problems become ours.
The last time I talked with the SCL team they were very hesitant to publish clear EOL dates on centos.org. We need to bring this up with them again.
There was a problem hiding this comment.
SLE 11 has gcc-6
@tchaikov I guess you meant SLE 12 (the current version). SLE 11 is very old and no recent Ceph runs on it. I checked and the current SLE-12-SP3 has gcc 6.2.1.
There was a problem hiding this comment.
thanks for confirming @smithfarm! no, i did mean SLE 11. b/c i found that SLE-11.4's EOL is 2019-03-31, that's why i thought we should consider SLE 11.4. and i was wrong, it has gcc-5.2 not gcc-6, per the release notes
anyway, it's great that we don't need to worry about SLE =)
There was a problem hiding this comment.
@ktdreyer sorry for using devtoolset-7 without any notice beforehand. i thought it's the future of devtoolset and will be well supported. may i know which devtoolset is supported? so we can use it?
|
If this works (install-deps.sh does the right thing on ubuntu and centos) I think we can probably turn the O(n) size() into an error instead of a warning? Then we can live happily ever after in C++11 land! |
tchaikov
force-pushed
the
wip-devtoolset-7
branch
3 times, most recently
from
f1cbb67
to
d435396
Compare
src/CMakeLists.txt
Outdated
| } | ||
| " HAVE_GLIBCXX_5_1) | ||
| if(NOT HAVE_GLIBCXX_5_1) | ||
| # libc++'s list::size() is O(1) also. |
There was a problem hiding this comment.
and libstdc++ 5.1 will also bring us a C++11 standard compliant regex implementation. see http://tracker.ceph.com/issues/20112
tchaikov
force-pushed
the
wip-devtoolset-7
branch
4 times, most recently
from
ce13c82
to
35ad383
Compare
|
https://shaman.ceph.com/builds/ceph/wip-devtoolset-7-kefu/ centos builds are green. |
|
change on trusty side, ceph/ceph-build#914. |
tchaikov
force-pushed
the
wip-devtoolset-7
branch
6 times, most recently
from
fbd83fd
to
7ce8b49
Compare
ready them for gcc7 and libstdc++-7 for better performance. Signed-off-by: Kefu Chai <kchai@redhat.com>
Signed-off-by: Kefu Chai <kchai@redhat.com>
for better performance. Signed-off-by: Kefu Chai <kchai@redhat.com>
* always install gcc-7 on trusty * point g++ to g++-7 if not yet Signed-off-by: Kefu Chai <kchai@redhat.com>
tchaikov
force-pushed
the
wip-devtoolset-7
branch
from
7ce8b49
to
24d0f93
Compare
|
While we're at it.. what would it take to get to C++14? As long as we're using custom toolchains we may as well modernize! |
|
@liewegas i will check the C++14 support matrix of GCC. what features we are after in C++14 in our minds? @adamemerson @cbodley |
|
What is the impact to qemu when we build librbd1 like this? Can users continue to use a qemu that is built with the older GCC that dynamically links to librbd1 built with the newer toolchain? |
ceph/ceph#19548 cmake: check gcc version not release date for libstdc++ saneness cmake: bail out if GCC version is less than 5.1 ceph/ceph#18938 ceph/ceph#19344 build/ops: use devtoolset-7 on centos/rhel-7 ceph.spec: use devtoolset-6-gcc-c++ on aarch64 ceph/ceph#18863 ceph/ceph#19341 install-deps: use DTS-7 on aarch64 and only download mirrored package indexes ceph/ceph#19645 Signed-off-by: luo.runbing <luo.runbing@zte.com.cn>
No description provided.