Re: [Maria-developers] b88e98df9da: C++11 experiment: check if all builders support it
Hi, Sergey!
Current status is: all staging builders pass, except for Ubuntu Precise.
But we no longer build on precise, do we? Any followup MDEVs after this one is pushed? Like migrate atomics ops to C++11 or something?
revision-id: b88e98df9daa586bd6ed1f5908ededaa65a6e464 (mariadb-10.3.6-16-gb88e98df9da) parent(s): 9988a423d229730b252942b7fa066d1591b7eca9 author: Sergey Vojtovich committer: Sergey Vojtovich timestamp: 2018-06-04 12:41:18 +0400 message:
C++11 experiment: check if all builders support it
diff --git a/CMakeLists.txt b/CMakeLists.txt index 76b0817f8c7..efeae3d1ca5 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -89,6 +89,14 @@ ELSE() ENDIF() PROJECT(${MYSQL_PROJECT_NAME})
+IF(CMAKE_VERSION VERSION_LESS "3.1") + IF(CMAKE_CXX_COMPILER_ID STREQUAL "GNU") + SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++11")
Why gnu++11 and not c++11 ? And why not for clang?
+ ENDIF() +ELSE() + SET(CMAKE_CXX_STANDARD 11)
I'd expect this to mean c++11, not gnu++11.
+ENDIF() + SET(CPACK_PACKAGE_NAME "MariaDB") SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY "MariaDB: a very fast and robust SQL database server") SET(CPACK_PACKAGE_URL "http://mariadb.org") diff --git a/storage/tokudb/PerconaFT/portability/toku_crash.cc b/storage/tokudb/PerconaFT/portability/toku_crash.cc index 0af85342a99..297cc29d9ca 100644 --- a/storage/tokudb/PerconaFT/portability/toku_crash.cc +++ b/storage/tokudb/PerconaFT/portability/toku_crash.cc @@ -70,7 +70,7 @@ run_gdb(pid_t parent_pid, const char *gdb_path) { "-ex", "thread apply all bt", "-ex", "thread apply all bt full", exe_buf, pid_buf, - NULL); + (char*) NULL);
Why's that? Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi, Sergei! On Tue, Jul 03, 2018 at 07:53:39PM +0200, Sergei Golubchik wrote:
Hi, Sergey!
Current status is: all staging builders pass, except for Ubuntu Precise.
But we no longer build on precise, do we? Not anymore. Though, as discussed before, it also fails to build on labrador and my push to bb-10.4-release was built only on few platforms.
Any followup MDEVs after this one is pushed? Like migrate atomics ops to C++11 or something?
No MDEVs, but it should happen eventually. I'd like to wait a bit with implementing this (may be till first release) so that we're more or less certain we won't have to revert it.
revision-id: b88e98df9daa586bd6ed1f5908ededaa65a6e464 (mariadb-10.3.6-16-gb88e98df9da) parent(s): 9988a423d229730b252942b7fa066d1591b7eca9 author: Sergey Vojtovich committer: Sergey Vojtovich timestamp: 2018-06-04 12:41:18 +0400 message:
C++11 experiment: check if all builders support it
diff --git a/CMakeLists.txt b/CMakeLists.txt index 76b0817f8c7..efeae3d1ca5 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -89,6 +89,14 @@ ELSE() ENDIF() PROJECT(${MYSQL_PROJECT_NAME})
+IF(CMAKE_VERSION VERSION_LESS "3.1") + IF(CMAKE_CXX_COMPILER_ID STREQUAL "GNU") + SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++11")
Why gnu++11 and not c++11 ?
I don't recall if there was a reason for this, most probably I just copied it from somewhere.
And why not for clang? No special reason, I just didn't see any problems with clang so far. Though I can't say I did try hard.
According to manual, clang enables many c++11 features by default and atomic operations seem to be eneabled as well (if I read it correctly).
+ ENDIF() +ELSE() + SET(CMAKE_CXX_STANDARD 11)
I'd expect this to mean c++11, not gnu++11.
I see your point. We should change the above to c++11 as well to be consistent.
+ENDIF() + SET(CPACK_PACKAGE_NAME "MariaDB") SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY "MariaDB: a very fast and robust SQL database server") SET(CPACK_PACKAGE_URL "http://mariadb.org") diff --git a/storage/tokudb/PerconaFT/portability/toku_crash.cc b/storage/tokudb/PerconaFT/portability/toku_crash.cc index 0af85342a99..297cc29d9ca 100644 --- a/storage/tokudb/PerconaFT/portability/toku_crash.cc +++ b/storage/tokudb/PerconaFT/portability/toku_crash.cc @@ -70,7 +70,7 @@ run_gdb(pid_t parent_pid, const char *gdb_path) { "-ex", "thread apply all bt", "-ex", "thread apply all bt full", exe_buf, pid_buf, - NULL); + (char*) NULL);
Why's that?
storage/tokudb/PerconaFT/portability/toku_crash.cc: In function ‘void run_gdb(pid_t, const char*)’: storage/tokudb/PerconaFT/portability/toku_crash.cc:73:16: error: missing sentinel in function call [-Werror=format=] NULL); ^ And then man execlp specifies this sentinel as "/* (char *) NULL */". Thanks, Sergey
Hi, Sergey! On Jul 03, Sergey Vojtovich wrote:
Hi, Sergei!
On Tue, Jul 03, 2018 at 07:53:39PM +0200, Sergei Golubchik wrote:
Hi, Sergey!
Current status is: all staging builders pass, except for Ubuntu Precise.
But we no longer build on precise, do we? Not anymore. Though, as discussed before, it also fails to build on labrador and my push to bb-10.4-release was built only on few platforms.
labrador already fails to build 10.3 (and other branched?) with internal compiler error. we'll get a newer mac.
Any followup MDEVs after this one is pushed? Like migrate atomics ops to C++11 or something? No MDEVs, but it should happen eventually. I'd like to wait a bit with implementing this (may be till first release) so that we're more or less certain we won't have to revert it.
right. my question was more about getting an idea of *what* should happen eventually. I didn't mean it should happen now.
+ ENDIF() +ELSE() + SET(CMAKE_CXX_STANDARD 11)
I'd expect this to mean c++11, not gnu++11. I see your point. We should change the above to c++11 as well to be consistent.
Also, note that rocksdb, tokudb, and aws plugin all use c++11, no plugin uses gnu++11.
diff --git a/storage/tokudb/PerconaFT/portability/toku_crash.cc b/storage/tokudb/PerconaFT/portability/toku_crash.cc index 0af85342a99..297cc29d9ca 100644 --- a/storage/tokudb/PerconaFT/portability/toku_crash.cc +++ b/storage/tokudb/PerconaFT/portability/toku_crash.cc @@ -70,7 +70,7 @@ run_gdb(pid_t parent_pid, const char *gdb_path) { "-ex", "thread apply all bt", "-ex", "thread apply all bt full", exe_buf, pid_buf, - NULL); + (char*) NULL);
Why's that? storage/tokudb/PerconaFT/portability/toku_crash.cc: In function ‘void run_gdb(pid_t, const char*)’: storage/tokudb/PerconaFT/portability/toku_crash.cc:73:16: error: missing sentinel in function call [-Werror=format=] NULL); ^
interesting. ok. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi Serge[yi]! 2018-07-04 11:17 GMT+03:00 Sergei Golubchik <serg@mariadb.org>:
Hi, Sergey!
On Jul 03, Sergey Vojtovich wrote:
diff --git a/storage/tokudb/PerconaFT/portability/toku_crash.cc b/storage/tokudb/PerconaFT/portability/toku_crash.cc index 0af85342a99..297cc29d9ca 100644 --- a/storage/tokudb/PerconaFT/portability/toku_crash.cc +++ b/storage/tokudb/PerconaFT/portability/toku_crash.cc @@ -70,7 +70,7 @@ run_gdb(pid_t parent_pid, const char *gdb_path) { "-ex", "thread apply all bt", "-ex", "thread apply all bt full", exe_buf, pid_buf, - NULL); + (char*) NULL);
Why's that? storage/tokudb/PerconaFT/portability/toku_crash.cc: In function ‘void run_gdb(pid_t, const char*)’: storage/tokudb/PerconaFT/portability/toku_crash.cc:73:16: error: missing sentinel in function call [-Werror=format=] NULL); ^
interesting. ok.
Would using std::nullptr be a cleaner option? Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation
participants (3)
-
Marko Mäkelä -
Sergei Golubchik -
Sergey Vojtovich