Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 62782 invoked from network); 6 Sep 2010 12:51:27 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Sep 2010 12:51:27 -0000 Received: (qmail 22660 invoked by uid 500); 6 Sep 2010 12:51:27 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 22583 invoked by uid 500); 6 Sep 2010 12:51:25 -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 22567 invoked by uid 99); 6 Sep 2010 12:51:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Sep 2010 12:51:23 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=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, 06 Sep 2010 12:51:16 +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 o86CmuF9001486; Mon, 6 Sep 2010 13:48:56 +0100 (BST) Received: from E102393 ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Sep 2010 13:50:52 +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> <000101cb3241$fe2ff550$fa8fdff0$@Meyer@arm.com> <4C593478.3000005@gmail.com> In-Reply-To: <4C593478.3000005@gmail.com> Subject: RE: stdcxx and POSIX Date: Mon, 6 Sep 2010 13:50:49 +0100 Message-ID: <000001cb4dc2$2200c0e0$660242a0$@Meyer@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcszuHZlDCSOABlbQNu0Th2Fd3jiugaCXW+A Content-Language: en-gb X-OriginalArrivalTime: 06 Sep 2010 12:50:52.0730 (UTC) FILETIME=[23A681A0:01CB4DC2] Hello Martin, Any good news about the patch? :) Wojciech -----Original Message----- From: Martin Sebor [mailto:msebor@gmail.com] Sent: 04 August 2010 10:36 To: Wojciech Meyer Cc: dev@stdcxx.apache.org Subject: Re: stdcxx and POSIX On 08/02/2010 06:55 AM, Wojciech Meyer wrote: > 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. Will do! Thanks Martin > > 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. >