Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-19 15:36:54 -0400, Jung-uk Kim wrote: On 2012-07-19 15:09:08 -0400, Dimitry Andric wrote: Btw, does anybody know *why* the LibreOffice port attempts to compile everything as C++0x or C++11? Is it really using those features? It is using some of its features, I guess: ifeq ($(HAVE_CXX0X),TRUE) #Currently, as well as for its own merits, c++11/c++0x mode allows use to use #a template for SAL_N_ELEMENTS to detect at compiler time its misuse gb_CXXFLAGS += -std=c++0x ... I don't know the impact of turning it off, however. Some time ago, I tried to forcefully turning it off but I wasn't able to make it work on all releases at the time. More investigation showed that it was added because Boost 1.48 had serious regression: http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?h=libreoffice-3-4id=9c2ab9f4febec2b2c5fac25469f1d0cfedc6af5e It seems to be related to this Boost issue: https://svn.boost.org/trac/boost/ticket/6167 Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAJ7zkACgkQmlay1b9qnVOZVgCghuywlMgsr7nTiGTpSwWJpquN bL4AoJEs2L4wqSdlRsUps1vPvkX+TvrO =5/X9 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
On 2012-07-19 01:34, Jung-uk Kim wrote: While I was tackling LibreOffice build issues, I found something interesting about __cplusplus. Basically, different C++ compilers may have different __cplusplus definitions and it may cause some strangeness. Clang, for example, used to set it to 1 but now it is set to C++ standard value since this commit: http://llvm.org/viewvc/llvm-project?view=revrevision=156113 Yes, this is because gcc started doing the same. Otherwise it becomes rather difficult to distinguish C++98, C++0x and C++11 in your C++ library implementation (in the GNU case, libstdc++ most likely). ... This causes very subtle issues depending on compiler versions and FreeBSD versions. For example, NULL may be defined differently because stable/9 and head have this: #if __cplusplus = 201103L #define NULLnullptr #elif defined(__GNUG__) defined(__GNUC__) __GNUC__ = 4 #define NULL__null #else #if defined(__LP64__) #define NULL(0L) #else #define NULL0 #endif /* __LP64__ */ #endif /* __GNUG__ */ Before that, we had this: #if defined(__GNUG__) defined(__GNUC__) __GNUC__ = 4 #define NULL__null #else #if defined(__LP64__) #define NULL(0L) #else #define NULL0 #endif/* __LP64__ */ #endif/* __GNUG__ */ What a mess... Well, this is what you get when standards progress to include non-standard features (such as gcc's __null) that are already in use, but then subtly change them (calling them nullptr). However, as long as you can hide the #ifdef ugliness in a header, I don't really see the problem. This won't be the last ugly definition either. :) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
On 2012-07-19 09:21:30 -0400, Dimitry Andric wrote: On 2012-07-19 01:34, Jung-uk Kim wrote: While I was tackling LibreOffice build issues, I found something interesting about __cplusplus. Basically, different C++ compilers may have different __cplusplus definitions and it may cause some strangeness. Clang, for example, used to set it to 1 but now it is set to C++ standard value since this commit: http://llvm.org/viewvc/llvm-project?view=revrevision=156113 Yes, this is because gcc started doing the same. Otherwise it becomes rather difficult to distinguish C++98, C++0x and C++11 in your C++ library implementation (in the GNU case, libstdc++ most likely). Since when Clang started mimicking GCC 4.7? % /usr/local/bin/clang++ -E -x c++ -dM /dev/null | grep __GNUC #define __GNUC_GNU_INLINE__ 1 #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC__ 4 ;-) This causes very subtle issues depending on compiler versions and FreeBSD versions. For example, NULL may be defined differently because stable/9 and head have this: #if __cplusplus = 201103L #define NULLnullptr #elif defined(__GNUG__) defined(__GNUC__) __GNUC__ = 4 #define NULL__null #else #if defined(__LP64__) #define NULL(0L) #else #define NULL0 #endif /* __LP64__ */ #endif /* __GNUG__ */ Before that, we had this: #if defined(__GNUG__) defined(__GNUC__) __GNUC__ = 4 #define NULL__null #else #if defined(__LP64__) #define NULL (0L) #else #define NULL0 #endif/* __LP64__ */ #endif /* __GNUG__ */ What a mess... Well, this is what you get when standards progress to include non-standard features (such as gcc's __null) that are already in use, but then subtly change them (calling them nullptr). Yes, it is subtle but it can cause a real trouble because NULL can have different types depending on compiler versions and FreeBSD releases. % cat test.cc #include cstddef char *test = reinterpret_castchar *(NULL); % clang++ -c test.cc % clang++ -c -std=gnu++98 test.cc % clang++ -c -std=gnu++0x test.cc % clang++ -c -std=c++98 test.cc % clang++ -c -std=c++0x test.cc test.cc:2:14: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed char *test = reinterpret_castchar *(NULL); ^~ 1 error generated. % /usr/local/bin/clang++ -c test.cc % /usr/local/bin/clang++ -c -std=gnu++98 test.cc % /usr/local/bin/clang++ -c -std=gnu++0x test.cc test.cc:2:14: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed char *test = reinterpret_castchar *(NULL); ^~ 1 error generated. % /usr/local/bin/clang++ -c -std=c++98 test.cc % /usr/local/bin/clang++ -c -std=c++0x test.cc test.cc:2:14: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed char *test = reinterpret_castchar *(NULL); ^~ 1 error generated. When NULL is __null or an integral type, clang does not complain, of course. However, as long as you can hide the #ifdef ugliness in a header, I don't really see the problem. This won't be the last ugly definition either. :) I just wanted to let ports maintainers know about the caveat using different C++ compilers on different FreeBSD releases. Jung-uk Kim ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
On 2012-07-19 20:07, Jung-uk Kim wrote: On 2012-07-19 09:21:30 -0400, Dimitry Andric wrote: ... Since when Clang started mimicking GCC 4.7? Most likely since somebody attempted to get the latest GNU libstdc++ building with clang, and bumped into precisely this issue: if __cplusplus has the simple value 1, you can't get libstdc++'s C++0x or C++11 support enabled. % /usr/local/bin/clang++ -E -x c++ -dM /dev/null | grep __GNUC #define __GNUC_GNU_INLINE__ 1 #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC__ 4 Yeah, that's probably the last gcc version clang is going to lie about, especially since version checking is very fragile. By the way, feature checks are implemented in clang using the __has_feature macro, which is much easier to use than comparing versions: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check ... Well, this is what you get when standards progress to include non-standard features (such as gcc's __null) that are already in use, but then subtly change them (calling them nullptr). Yes, it is subtle but it can cause a real trouble because NULL can have different types depending on compiler versions and FreeBSD releases. % cat test.cc #include cstddef char *test = reinterpret_castchar *(NULL); % clang++ -c test.cc % clang++ -c -std=gnu++98 test.cc % clang++ -c -std=gnu++0x test.cc % clang++ -c -std=c++98 test.cc % clang++ -c -std=c++0x test.cc test.cc:2:14: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed char *test = reinterpret_castchar *(NULL); ^~ There is no need for casting at all here. 'nullptr' can implicitly be converted to any pointer type. If you really want to perform the cast, even when it is unnecessary, use static_cast, or a C-style cast. You only need to use reinterpret_cast here, if you want to convert 'nullptr' to any non-pointer type, such as int. Btw, does anybody know *why* the LibreOffice port attempts to compile everything as C++0x or C++11? Is it really using those features? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-19 15:09:08 -0400, Dimitry Andric wrote: On 2012-07-19 20:07, Jung-uk Kim wrote: On 2012-07-19 09:21:30 -0400, Dimitry Andric wrote: ... Since when Clang started mimicking GCC 4.7? Most likely since somebody attempted to get the latest GNU libstdc++ building with clang, and bumped into precisely this issue: if __cplusplus has the simple value 1, you can't get libstdc++'s C++0x or C++11 support enabled. % /usr/local/bin/clang++ -E -x c++ -dM /dev/null | grep __GNUC #define __GNUC_GNU_INLINE__ 1 #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC__ 4 Yeah, that's probably the last gcc version clang is going to lie about, especially since version checking is very fragile. By the way, feature checks are implemented in clang using the __has_feature macro, which is much easier to use than comparing versions: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check Yes, I know. Actually, the real problem is LibreOffice treats Clang as GCC variant and configure script thinks it is gcc 4.2.1:-( configure:7361: checking the GNU C compiler version configure:7385: result: checked (gcc 4.2.1) ... Well, this is what you get when standards progress to include non-standard features (such as gcc's __null) that are already in use, but then subtly change them (calling them nullptr). Yes, it is subtle but it can cause a real trouble because NULL can have different types depending on compiler versions and FreeBSD releases. % cat test.cc #include cstddef char *test = reinterpret_castchar *(NULL); % clang++ -c test.cc % clang++ -c -std=gnu++98 test.cc % clang++ -c -std=gnu++0x test.cc % clang++ -c -std=c++98 test.cc % clang++ -c -std=c++0x test.cc test.cc:2:14: error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed char *test = reinterpret_castchar *(NULL); ^~ There is no need for casting at all here. 'nullptr' can implicitly be converted to any pointer type. If you really want to perform the cast, even when it is unnecessary, use static_cast, or a C-style cast. You only need to use reinterpret_cast here, if you want to convert 'nullptr' to any non-pointer type, such as int. Feel free to file a LibreOffice PR. ;-) https://www.libreoffice.org/get-help/bug/ Seriously, it is not really easy to correct all upstream bugs, especially huge monsters such as LibreOffice OpenOffice. :-( Btw, does anybody know *why* the LibreOffice port attempts to compile everything as C++0x or C++11? Is it really using those features? It is using some of its features, I guess: ifeq ($(HAVE_CXX0X),TRUE) #Currently, as well as for its own merits, c++11/c++0x mode allows use to use #a template for SAL_N_ELEMENTS to detect at compiler time its misuse gb_CXXFLAGS += -std=c++0x ... I don't know the impact of turning it off, however. Some time ago, I tried to forcefully turning it off but I wasn't able to make it work on all releases at the time. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAIYdYACgkQmlay1b9qnVP5wQCgrPWXsR5XwPHw2+4hXUdrt80r vS8AnRRHfIHWivxEfOnl11BnBIUFN98J =VdAg -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While I was tackling LibreOffice build issues, I found something interesting about __cplusplus. Basically, different C++ compilers may have different __cplusplus definitions and it may cause some strangeness. Clang, for example, used to set it to 1 but now it is set to C++ standard value since this commit: http://llvm.org/viewvc/llvm-project?view=revrevision=156113 This is what I got from head: GCC: % cpp --version cpp (GCC) 4.2.1 20070831 patched [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % cpp -x c++ -dM /dev/null | grep __cplusplus #define __cplusplus 1 % cpp -x c++ -std=gnu++98 -dM /dev/null | grep __cplusplus #define __cplusplus 1 Clang 3.1: % clang-cpp --version FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 Target: x86_64-unknown-freebsd10.0 Thread model: posix % clang-cpp -x c++ -std=c++98 -dM /dev/null | grep __cplusplus #define __cplusplus 199711L % clang-cpp -x c++ -std=c++0x -dM /dev/null | grep __cplusplus #define __cplusplus 201103L % clang-cpp -x c++ -std=gnu++98 -dM /dev/null | grep __cplusplus #define __cplusplus 1 % clang-cpp -x c++ -std=gnu++0x -dM /dev/null | grep __cplusplus #define __cplusplus 1 Clang 3.2 snapshot (ports/lang/clang-devel): % /usr/local/bin/clang++ --version clang version 3.2 (trunk) Target: amd64-portbld-freebsd10.0 Thread model: posix % /usr/local/bin/clang++ -E -x c++ -std=c++98 -dM /dev/null | grep __cplusplus #define __cplusplus 199711L % /usr/local/bin/clang++ -E -x c++ -std=c++0x -dM /dev/null | grep __cplusplus #define __cplusplus 201103L % /usr/local/bin/clang++ -E -x c++ -std=gnu++98 -dM /dev/null | grep __cplusplus #define __cplusplus 199711L % /usr/local/bin/clang++ -E -x c++ -std=gnu++0x -dM /dev/null | grep __cplusplus #define __cplusplus 201103L and so on and so forth... This causes very subtle issues depending on compiler versions and FreeBSD versions. For example, NULL may be defined differently because stable/9 and head have this: #if __cplusplus = 201103L #define NULLnullptr #elif defined(__GNUG__) defined(__GNUC__) __GNUC__ = 4 #define NULL__null #else #if defined(__LP64__) #define NULL(0L) #else #define NULL0 #endif /* __LP64__ */ #endif /* __GNUG__ */ Before that, we had this: #if defined(__GNUG__) defined(__GNUC__) __GNUC__ = 4 #define NULL__null #else #if defined(__LP64__) #define NULL(0L) #else #define NULL0 #endif /* __LP64__ */ #endif /* __GNUG__ */ What a mess... Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAHR/IACgkQmlay1b9qnVNd0QCfX1NPpOfc+haRebvmBb1+nMSY KAUAn3A6vKEaV0FQy82gysnV79UdejMf =7G3Z -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
