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.
