Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 28853 invoked from network); 2 Aug 2010 12:56:07 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Aug 2010 12:56:07 -0000 Received: (qmail 29279 invoked by uid 500); 2 Aug 2010 12:56:07 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 29210 invoked by uid 500); 2 Aug 2010 12:56:06 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 29202 invoked by uid 99); 2 Aug 2010 12:56:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 12:56:05 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=MIME_QP_LONG_LINE,MSGID_MULTIPLE_AT,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Wojciech.Meyer@arm.com designates 217.140.96.50 as permitted sender) Received: from [217.140.96.50] (HELO cam-admin0.cambridge.arm.com) (217.140.96.50) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 12:55:58 +0000 Received: from cam-owa2.Emea.Arm.com (cam-owa2.emea.arm.com [10.1.105.18]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id o72CtRF9000235; Mon, 2 Aug 2010 13:55:27 +0100 (BST) Received: from E102393 ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Aug 2010 13:55:35 +0100 From: "Wojciech Meyer" To: "'Martin Sebor'" Cc: References: <4C28C458.5090101@gmail.com> <4C3116D6.8060205@gmail.com> <4C3C8167.8060209@gmail.com> <4C486926.2040103@gmail.com> <4C53582C.9050800@gmail.com> In-Reply-To: Subject: RE: stdcxx and POSIX Date: Mon, 2 Aug 2010 13:55:32 +0100 Message-ID: <000101cb3241$fe2ff550$fa8fdff0$@Meyer@arm.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01CB324A.5FF45D50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcswOjghPErOCzzHRf6GAAFIaUWqvAB39lNQAAmQd/A= Content-Language: en-gb X-OriginalArrivalTime: 02 Aug 2010 12:55:35.0446 (UTC) FILETIME=[FFB44B60:01CB3241] ------=_NextPart_000_0002_01CB324A.5FF45D50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Martin, I've checked your patches in our environment today, and after a small adjustment I got it to work. I still have not tested it under Windows, as I would need to setup either Visual Studio or Mingw/MSYS environment, that is said I am on vm only (but I will do this soon). I am attaching the corrected patch. The other one is OK. The good thing to do would be to send all diffs from your sandbox to me once you can, probably after holidays (mine will end up with 22nd of Aug), so I can apply it here and test it on Windows too, before you commit. Cheers; Wojciech -----Original Message----- From: Wojciech Meyer [mailto:Wojciech.Meyer@arm.com] Sent: 02 August 2010 09:25 To: 'Martin Sebor' Cc: dev@stdcxx.apache.org 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: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]' >>> /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]' >>> /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]' >>> /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 >>>>>> 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. ------=_NextPart_000_0002_01CB324A.5FF45D50--