Hi,
referring to http://marc.info/?l=openbsd-ports&m=129789998809077&w=2
I am in the process of updating llvm+clang from 2.8 ==> 2.9
(maintainer is ports@). Done the update on amd64 (will need some
feedback) sending as a separate email. Update can go in or not, but
clang++ C++ compiler absolutely needs a fix to be usable, clang C
compiler works.
Right now llvm+clang 2.8 is unusable as C++ compiler on OpenBSD
because of gcc issue highlighted in below thread on ports@. This issue
of C++ compilation issues was initially brought up and then solved by
matthew@ when prodded by espie@. I am using the version of
os_defines.h in that thread and rebuilt userland since that time and
clang++ works fine. matthew@ committed the first part of that fix for
libc __cxa_finalize. This part needs consensus approval from you guys
since it might affect stuff negatively.
I am kickstarting this discussion in the hope this gets resolved
sometime before 5.0 lock and I don't have to see a M next to this file
when I do a cvs up.
Investigating this CHECK / DYNAMIC defines in the other BSDs brings
the foll results. FreeBSD has almost the same file as OpenBSD. So if
anybody has access to a FreeBSD stable 8.2 or current system, can they
compile any C++ program with Clang++ 2.9? This is because their header
file is same as OpenBSD.
----------------------------------------------------
freebsd-src-current/head/contrib/libstdc++/config/os/bsd/freebsd/os_defines.h
GCC 4.2.1? present (Can clang++ actually compile C++ programs? verify)
#define _GLIBCXX_USE_C99_CHECK 1
#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE >= 1999))
#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1
#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC ||
!defined
__LONG_LONG_SUPPORTED)
#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1
#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE
----------------------------------------------------
dragonfly-src-current/src/contrib/gcc-4.4/libstdc++-v3/config/os/bsd/dragonfl
y/os_defines.h
GCC 4.4.5? note how its completely absent on 4.4.5
/* JRM: Disable all these defines until better understood.
They work fine on vendor gcc 4.6, but break buildworld.
#define _GLIBCXX_USE_C99 1
#define _GLIBCXX_USE_C99_CHECK 1
#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE >= 1999))
#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1
#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC
|| !defined __LONG_LONG_SUPPORTED)
#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1
#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE
*/
----------------------------------------------------
netbsd-src-current/src/gnu/dist/gcc4/libstdc++-v3/config/os/bsd/netbsd/os_def
ines.h
gcc 4.1.* or 4.2.1? absent with additional define
#ifndef _GLIBCXX_OS_DEFINES
#define _GLIBCXX_OS_DEFINES 1
// System-specific #define, typedefs, corrections, etc, go here. This
// file will come before all others.
#define __ssize_t ssize_t
----------------------------------------------------
/usr/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h
GCC 4.2.1, present with additional typedef
#define _GLIBCXX_USE_C99 1
#define _GLIBCXX_USE_C99_CHECK 1
#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE >= 1999))
#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1
#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC ||
!defined
__LONG_LONG_SUPPORTED)
#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1
#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE
typedef __builtin_va_list __gnuc_va_list;
Note, matthew@ said in another email in that thread that Ubuntu
doesn't define it.
Will some guru please find time to investigate this issue?
Thanks,
amit
P.S I am trying to see how far clang goes in compiling userland &
xenocara, the latter of which needs clang++ as CXX compiler.
On Tue, Feb 15, 2011 at 10:13 PM, Matthew Dempsky <matt...@dempsky.org>
wrote:
> On Tue, Feb 15, 2011 at 11:57:44PM +0100, Marc Espie wrote:
>> Finding out why it doesn't work with g++ from src would be
>> the correct approach.
>
> Investigating further, it seems to boil down to _GLIBCXX_USE_C99_CHECK
> in /usr/include/g++/*/bits/os_defines.h. Including <cstdio> from base
> effectively feeds the following to the compiler:
>
> typedef unsigned long size_t;
>
> extern "C" {
> int snprintf(char *, size_t, const char *, ...)
> __attribute__((__format__ (printf, 3, 4)))
> __attribute__((__nonnull__ (3)))
> __attribute__((__bounded__ (__string__,1,2)));
> }
>
> namespace std {
> extern "C" int
> (snprintf)(char * restrict, size_t, const char * restrict, ...);
> using ::snprintf;
> }
>
> g++ doesn't mind the conflicting definitions for snprintf (it doesn't
> seem to care about *any* conflicts actually; you could put "int
> snprintf(double x)" and it's still happy), but clang++ does.
>
> We don't define anything in os_defines.h in libstdc++ from ports, so
> the the second chunk of code above never gets included.
>
> Perhaps we can get rid of _GLIBCXX_USE_C99_CHECK (along with the other
> *_CHECK defines) since it's apparently useless even with g++ and just
> causes compile trouble with clang++? Also, maybe useful to add
> _GLIBCXX_USE_C99 to ports libstdc++? (I'll test these ideas out
> later.)
