RE: stdcxx and POSIX

[Wojciech Meyer <Wo...@arm.com>]

> Wojciech,

> I started applying the patch hoping to be able to commit it
> before I leave for my trip tomorrow but I'm not going to be
> able to make it.

No problem, I will be off on holiday starting next week, for two weeks
time. And it is not a blocker here.

> I think most (but not all) uses of the _RWSTD_NO_NATIVE_IO
> macro should be replaced with one that checks for POSIX or
> UNIX features. Unfortunately, it's not as easy as replacing
> those references with something like __unix__ because that
> would break (or disable the functionality on) Windows.

There are a couple of things:
- it could be a user defined Makefile variable (e.g WITHOUT_POSIX). (if
  you are up to a patch that exactly does it, let me know)
- it will not break only windows build but all of the non Unix builds as
  well (which is the case here).

> Attached are a couple of untested patches to illustrate
> what I have in mind. I don't have a Windows box to test my
> changes on so if you do and have the time to work on it and
> test it there that'd be great. Otherwise it'll need to wait
> until I get back at the end of August.

Thanks for it, fortunately I am able to to test them in our environment
(and I will try to do it on vm windows too)

> Martin

Wojciech

On 07/22/2010 11:11 AM, Wojciech Meyer wrote:
> Hi Martin,
>
> Thanks for the update!
>
> I will svn-up the sandbox sometime next week.
>
> Cheers;
> Wojciech
>
> PS: It's worth to know others that it's been solved so I CC back to ML.
>
>
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com]
> Sent: 22 July 2010 16:52
> To: Wojciech Meyer
> Subject: Re: stdcxx and POSIX
>
> On 07/22/2010 07:14 AM, Wojciech Meyer wrote:
>> Hi Martin!
>>
>> I haven't got any response from you yet, is there any progress on
reviewing it?
>> Please let me know when you will be able.
>> Thanks,
>
> Sorry (and thanks for the reminder). We had a fire drill over the
> weekend due to a customer problem. The patch looks good. I think
> I'll just use a different macro instead of _RWSTD_NO_NATIVE_IO
> since we're using it guard all kinds of POSIX things, not just
> I/O.
>
> I've added an issue and attached your patch to it:
>     http://issues.apache.org/jira/browse/STDCXX-1050
>
> Let me test it and check it in this weekend.
>
> Martin
>
>>
>> Wojciech
>>
>>
>>
>> -----Original Message-----
>> From: Wojciech Meyer
>> Sent: 15 July 2010 10:31
>> To: 'Martin Sebor'
>> Subject: RE: stdcxx and POSIX
>>
>>> In my patch I only focused on the iostream problem. A more complete
>>> fix would be great -- I'll gladly take your patches!
>>
>> So here it goes! A complete patch for a non POSIX platforms.
>>
>> We have other small issues here, regarding running configuration files
>> on models, I will update you on the mailing list soon!
>>
>> BTW: I've tested it with PH, and there no regressions.
>>
>> Thanks,
>> Wojciech
>>
>>
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com]
>> Sent: 13 July 2010 16:08
>> To: Wojciech Meyer
>> Subject: Re: stdcxx and POSIX
>>
>> On 07/13/2010 08:12 AM, Wojciech Meyer wrote:
>>> Hi Martin,
>>>
>>> I checked your latest changes and they had improved everything, but
>>> unfortunately some POSIX problems still persisted. (it is not an easy
>>> task to find a purely non POSIX and non win32 environment - I know)
>>> However I've fixed them all on the stdcxx-4.2.x head. (if you accept any
>>> downstream patches, I am willing to share it, once I got sorted it
>>> here).
>>
>> In my patch I only focused on the iostream problem. A more complete
>> fix would be great -- I'll gladly take your patches!
>>
>>>
>>> One thing: the stdcxx-4.2.x head build on gcc is currently broken (it is
>>> important because I would like to run tests before I send the changes),
>>> on my machine on:
>>
>> I think this is a known problem. Probably STDCXX-512 or one of these:
>>
>>        http://tinyurl.com/28m5juc
>>
>> Martin
>>
>>>
>>> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
>>> gcc (GCC) 4.4.4
>>>
>>> with following compilation errors:
>>>
>>>
/work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:818:
instantiated from here
>>> /work/svn/stdcxx/branches/4.2.x/include/functional:90: error: no match
for 'operator*' in '__x * __y'
>>> /work/svn/stdcxx/branches/4.2.x/include/functional: In member function
'typename std::binary_function<_TypeT, _TypeT, _TypeT>::result_type
std::divides<_TypeT>::operator()(const typename std::binary_function<_TypeT,
_TypeT, _TypeT>::first_argument_type&, const typename
std::binary_function<_TypeT, _TypeT, _TypeT>::second_argument_type&) const
[with _TypeT = UserClass]':
>>> /work/svn/stdcxx/branches/4.2.x/include/algorithm:362:   instantiated
from '_OutputIter std::transform(_InputIter1, _InputIter1, _InputIter2,
_OutputIter, _BinaryOperation) [with _InputIter1 = UserClass*, _InputIter2 =
const UserClass*, _OutputIter = UserClass*, _BinaryOperation =
std::divides<UserClass>]'
>>> /work/svn/stdcxx/branches/4.2.x/include/valarray:383:   instantiated
from 'std::valarray<_TypeT>&    std::valarray<_TypeT>::operator/=(const
std::valarray<_TypeT>&) [with _TypeT = UserClass]'
>>>
/work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:384:
instantiated from 'void test_div_assign(const T*, const char*, const char*)
[with T = UserClass]'
>>>
/work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:762:
instantiated from 'void test_op_assign(const T*, const char*) [with T =
UserClass]'
>>>
/work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:818:
instantiated from here
>>> /work/svn/stdcxx/branches/4.2.x/include/functional:103: error: no match
for 'operator/' in '__x / __y'
>>> /work/svn/stdcxx/branches/4.2.x/include/functional: In member function
'typename std::binary_function<_TypeT, _TypeT, _TypeT>::result_type
std::plus<_TypeT>::operator()(const typename std::binary_function<_TypeT,
_TypeT, _TypeT>::first_argument_type&, const typename
std::binary_function<_TypeT, _TypeT, _TypeT>::second_argument_type&) const
[with _TypeT = UserClass]':
>>> /work/svn/stdcxx/branches/4.2.x/include/algorithm:362:   instantiated
from '_OutputIter std::transform(_InputIter1, _InputIter1, _InputIter2,
_OutputIter, _BinaryOperation) [with _InputIter1 = UserClass*, _InputIter2 =
const UserClass*, _OutputIter = UserClass*, _BinaryOperation =
std::plus<UserClass>]'
>>> /work/svn/stdcxx/branches/4.2.x/include/valarray:396:   instantiated
from 'std::valarray<_TypeT>&    std::valarray<_TypeT>::operator+=(const
std::valarray<_TypeT>&) [with _TypeT = UserClass]'
>>>
/work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:461:
instantiated from 'void test_add_assign(const T*, const char*, const char*)
[with T = UserClass]'
>>>
/work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:770:
instantiated from 'void test_op_assign(const T*, const char*) [with T =
UserClass]'
>>>
/work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:818:
instantiated from here
>>> /work/svn/stdcxx/branches/4.2.x/include/functional:64: error: no match
for 'operator+' in '__x + __y'
>>> /work/svn/stdcxx/branches/4.2.x/include/functional: In member function
'typename std::binary_function<_TypeT, _TypeT, _TypeT>::result_type
std::minus<_TypeT>::operator()(const typename std::binary_function<_TypeT,
_TypeT, _TypeT>::first_argument_type&, const typename
std::binary_function<_TypeT, _TypeT, _TypeT>::second_argument_type&) const
[with _TypeT = UserClass]':
>>> /work/svn/stdcxx/branches/4.2.x/include/algorithm:362:   instantiated
from '_OutputIter std::transform(_InputIter1, _InputIter1, _InputIter2,
_OutputIter, _BinaryOperation) [with _InputIter1 = UserClass*, _InputIter2 =
const UserClass*, _OutputIter = UserClass*, _BinaryOperation =
std::minus<UserClass>]'
>>> /work/svn/stdcxx/branches/4.2.x/include/valarray:409:   instantiated
from 'std::valarray<_TypeT>&    std::valarray<_TypeT>::operator-=(const
std::valarray<_TypeT>&) [with _TypeT = UserClass]'
>>>
/work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:521:
instantiated from 'void test_sub_assign(const T*, const char*, const char*)
[with T = UserClass]'
>>>
/work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:774:
instantiated from 'void test_op_assign(const T*, const char*) [with T =
UserClass]'
>>>
/work/svn/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp:818:
instantiated from here
>>> /work/svn/stdcxx/branches/4.2.x/include/functional:77: error: no match
for 'operator-' in '__x - __y'
>>>
>>> Thanks!
>>>
>>> Wojciech
>>>
>>> -----Original Message-----
>>> From: Wojciech Meyer
>>> Sent: 05 July 2010 11:19
>>> To: 'Martin Sebor'
>>> Subject: RE: stdcxx and POSIX
>>>
>>> Martin,
>>>
>>> Thanks your prompt patch!  I will try to get back to you ASAP on Jira&
>>> dev mailing list, with the feedback (hopefully sometime this week).
>>> There might be some way of sending something back to you (I hope), but
>>> for that I cannot say when.  So please be patient, and once more thanks.
>>>
>>> Wojciech
>>>
>>>
>>> -----Original Message-----
>>> From: Martin Sebor [mailto:msebor@gmail.com]
>>> Sent: 05 July 2010 00:19
>>> To: Wojciech Meyer
>>> Cc: dev@stdcxx.apache.org
>>> Subject: Re: stdcxx and POSIX
>>>
>>> Wojciech,
>>>
>>> This patch fixes the problem for me. Please check it out
>>> and let me know if it works for you:
>>>
>>>       http://svn.apache.org/viewcvs?view=rev&rev=960407
>>>
>>> If you continue to see problems with it (or any other part
>>> of stdcxx) it would be best if you could open issues in Jira.
>>> This one is being tracked here:
>>>
>>>       http://issues.apache.org/jira/browse/STDCXX-1049
>>>
>>> Feel free to add your comments to it (or reopen it).
>>>
>>> Let me know how the rest of your project goes!
>>>
>>> Martin
>>>
>>> On 06/28/2010 10:27 AM, Wojciech Meyer wrote:
>>>> Hi Martin,
>>>>
>>>> Thank you for the quick reply.
>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We are trying to use stdcxx library on a environment where POSIX
>>>>>> environment is not available (and it is not a win32 platform), as
>>>>>> a continuation of RoguWave library.  We would like to know if
>>>>>> stdcxx supports it.
>>>>
>>>>> Probably not without some minor tweaks. Stdcxx has been ported to
>>>>> z/OS (w/o the POSIX compatibility layer) some time ago without much
>>>>> difficulty so porting it to another non-POSIX platform shouldn't be
>>>>> too hard. Off the top of my head, file.cpp, memattr.cpp, mman.cpp,
>>>>> and once.cpp are the files that might need some work. memattr.cpp
>>>>> isn't really being used by the library so providing an empty body
>>>>> for the __rw_memattr() function for your platform should be good
>>>>> enough.
>>>>
>>>>> IIRC, _RWSTD_NO_NATIVE_IO was put in place when porting stdcxx
>>>>> to z/OS. It hasn't been tested since then (perhaps as far back
>>>>> as 2006) so it may have bit rotten.
>>>>
>>>> I think it would be very nice if Stdcxx could handle out of the box non
>>>> POSIX platforms, it is important especially in embedded world. I will
not
>>>> mention test and utilities, as this could be more problematic.
>>>>
>>>>>> On other side, the initialization routine (iostream.cpp) uses POSIX
>>>>>> file descriptors and posix calls for std console streams (cout,
>>>>>> cin, cerr objects and wchar equivalents), in this case there is no
>>>>>> other way than patching library to replace it with stdio.h
functionality.
>>>>>>
>>>>>> To reproduce the problem, on the system where POSIX is not present:
>>>>>> #include<iostream>
>>>>>> int main() { return 0; }
>>>>>>
>>>>>> Will fail, because we could not compile it, even if we compiled it
>>>>>> excluding files that use POSIX we will get linking errors.  Is
>>>>>> there any chance of solving it in your upstream? We know about the
>>>>>> status of Apache STL.
>>>>
>>>>> I see. It looks as though we need a switch to use stdin et al
>>>>> instead of STDIN_FILENO etc. Let me see if I can find some time
>>>>> to look into it this week and get back to you.
>>>>
>>>> That would be great, then we could test on our environment and provide
>>>> you some sort of immediate feedback about it.
>>>>
>>>>> Martin
>>>>
>>>> Wojciech
>>>>
>>>> -- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium.  Thank you.
>>>
>>>
>>> -- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium.  Thank you.
>>
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium.  Thank you.
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium.  Thank you.