You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@stdcxx.apache.org by Farid Zaripov <Fa...@epam.com> on 2007/04/13 17:23:14 UTC

Building stdcxx with EDG eccp

  I've tried to build stdcxx with EDG eccp in two configurations: 15d
and 15s. The both build was failed.
 
  The first command line: make BUILDTYPE=15d
BUILDDIR=/usr/tmp/stdcxx-eccp-15d CONFIG=eccp.config >eccp15d.log 2>&1
  The first build log is here:
http://people.apache.org/~faridz/eccp15d.log
 
  The second command line: make BUILDTYPE=15s
BUILDDIR=/usr/tmp/stdcxx-eccp-15s CONFIG=eccp.config >eccp15s.log 2>&1
  The second build log is here:
http://people.apache.org/~faridz/eccp15s.log
 
Farid.

RE: PING: Re: Building stdcxx with EDG eccp

Posted by Farid Zaripov <Fa...@epam.com>.

> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Tuesday, May 22, 2007 9:25 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: PING: Re: Building stdcxx with EDG eccp
> 
> 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.

  Yesterday I've updated GCC to version 4.2.0 and tried with eccp again.
No changes.

Farid.

Re: PING: Re: Building stdcxx with EDG eccp

Posted by Martin Sebor <se...@roguewave.com>.

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.

RE: PING: Re: Building stdcxx with EDG eccp

Posted by Farid Zaripov <Fa...@epam.com>.

> -----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.