Okay, thanks. Let me pass this on to them. Strangely, I'm pretty
sure I was able to get the library configured on my Linux box at
home (running Fedora Core 6). My compiler is gcc 4.1.1 so maybe
that makes a difference. In any event it's important that you
get it to work so please remind me if I forget to follow up with
you about it.
Martin
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Monday, May 21, 2007 11:54 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: PING: Re: Building stdcxx with EDG eccp
>>
>> Farid, any progress on the test case or getting this to work?
>
> No progress due to unable to compile. :(
>
> [...]
>
>>>> The eccp in strict mode (with -A or --strict option specified)
>>>> fails to compile the code which is use the GCC extensions, i.e.
>>>> __builtin_xxx functions
>>>> (__builtin_fabs() and other) are used in <cmath>.
>>> Right, I've seen these. They are annoying but I don't think they
>>> prevent the library from being built.
>
> They prevent from performing the configure step correctly. :(
> If I use the --g++ option that builtins are accepted, but --g++ option
> cannot be used together with --strict option.
>
>>>> Also eccp uses the name __is_pod as internal
>> pseudo-function, but
>>>> this name used in
>>>> /usr/local/include/c++/4.0.2/bits/cpp_type_traits.h. As a result I
>>>> got the error: error #40: expected an identifier.
>>> That's not good. If you could produce a small isolated test
>> case I can
>>> pass it on to the EDG folks while we're all here attending our
>>> meeting.
>
> The test is simple:
>
> test.cpp:
> -----------------
> int __is_pod = 0;
> -----------------
>
> echo "int __is_pod = 0;" > test.cpp && eccp --strict test.cpp
> -----------------
> "test.cpp", line 1: error: expected an identifier
> int __is_pod = 0;
> ^
>
> 1 error detected in the compilation of "test.cpp".
> -----------------
>
> Here the part from the eccp-3.9.pdf:
> -----------------
> A number of "type traits pseudo-functions" (taking one or two type
> names) are accepted: __has_nothrow_
> assign, __has_nothrow_constructor, __has_nothrow_copy,
> __has_trivial_assign, __
> has_trivial_constructor, __has_trivial_copy, __has_trivial_destructor,
> __is_
> abstract, __is_base_of, __is_class, __is_convertible_to, __is_empty,
> __is_enum, __
> is_pod, __is_polymorphic, and __is_union.
> double x[__is_union(union U)]; // Okay.
> These are silently accepted even in strict modes. They ease the
> implementation of ISO/IEC TR 19768.
> -----------------
>
> Farid.
|