Cheers;
Wojciech
-----Original Message-----
From: Wojciech Meyer [mailto:[email protected]]
Sent: 02 August 2010 09:25
To: 'Martin Sebor'
Cc: [email protected]
Subject: RE: stdcxx and POSIX
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:[email protected]]
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:[email protected]]
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:[email protected]]
Sent: 05 July 2010 00:19
To: Wojciech Meyer
Cc: [email protected]
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.
