From owner-freebsd-ports@FreeBSD.ORG Thu Jul 19 19:36:55 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5B871065672; Thu, 19 Jul 2012 19:36:55 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8C68E8FC14; Thu, 19 Jul 2012 19:36:55 +0000 (UTC) Message-ID: <500861D6.1070001@FreeBSD.org> Date: Thu, 19 Jul 2012 15:36:54 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120626 Thunderbird/13.0.1 MIME-Version: 1.0 To: Dimitry Andric References: <5006F780.2020004@FreeBSD.org> <44k3y1ndlp.fsf@be-well.ilk.org> <50073701.80205@FreeBSD.org> <500747F2.8010900@FreeBSD.org> <500809DA.1030301@FreeBSD.org> <50084CFA.9090802@gmail.com> <50085B54.2040005@FreeBSD.org> In-Reply-To: <50085B54.2040005@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: [FYI] C++ compilers vs. __cplusplus (was Re: SV: Re: make failed for editors/libreoffice) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 19:36:56 -0000 -----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 char *test = >> reinterpret_cast(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_cast(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-----