Re: STDCXX-1070
Martin Sebor writes: >> Clear to go ahead here? > > You mean apply the patch attached to STDCXX-1070? It looks good > to me. I also checked the test. It's odd that the problem didn't > get caught sooner (we did get errors when the function templates > were declared static, which is why the static keyword is commented > out). But it sure does look like a problem. > > FWIW, if you want quick input on a patch, I find it easier when > it's posted to the list (instead of attaching it to the issue). > Attaching it is useful when it's large and/or when you don't > have commit permissions. Others may have a different preference. My personal preference would be both. > > Martin > >> >> Thanks, >> Liviu >> > Thanks, -- Wojciech Meyer http://danmey.org
Re: [jira] [Closed] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
Hi guys, I think the consensus about this bug is that everybody wants to fix it. Stefan has a patch but I got completely lost what is the exact reason of not applying it. It would be a shame to stop at this point. Liviu Nicoara writes: > On 9/25/12 7:56 PM, Stefan Teleman (JIRA) wrote: >> >> [ >> https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] > > Stefan, > > I don't think it's ok to close this bug. The race conditions are there > and we have not come to a completely satisfactory conclusion on how to > deal with them, or even if we should deal with them. Whichever it is > we gotta keep this discussion open. I sure hope you want to be a part > of it. > > FWIW, I have spent quite some time looking at your proposed patch and > I am going to reopen the incident. If I can. > > Liviu > >> >> Stefan Teleman closed STDCXX-1056. >> -- >> >> Resolution: Won't Fix >> >> Bug will not be fixed. Upstream refuses to acknowledge the existence of the >> bug in spite of objective evidence to the contrary. >> >>> std::moneypunct and std::numpunct implementations are not thread-safe >>> - >>> >>> Key: STDCXX-1056 >>> URL: https://issues.apache.org/jira/browse/STDCXX-1056 >>> Project: C++ Standard Library >>> Issue Type: Bug >>> Components: 22. Localization >>> Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 >>> Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ >>> Compilers 12.1, 12.2, 12.3 >>> Issue is independent of platform and/or compiler. >>> Reporter: Stefan Teleman >>> Labels: thread-safety >>> Fix For: 4.2.x, 4.3.x, 5.0.0 >>> >>> Attachments: 22.locale.numpunct.mt.out, facet.cpp.diff, >>> locale_body.cpp.diff, punct.cpp.diff, runtests-linux32-all.out, >>> runtests-linux64-all.out, runtests.out, STDCXX-1056-additional-timings.tgz, >>> stdcxx-1056.patch, stdcxx-1056-timings.tgz, >>> stdcxx-4.2.x-numpunct-perfect-forwarding.patch, >>> stdcxx-4.3.x-numpunct-perfect-forwarding.patch >>> >>> >>> several member functions in std::moneypunct<> and std::numpunct<> return >>> a std::string by value (as required by the Standard). The implication of >>> return-by-value >>> being that the caller "owns" the returned object. >>> In the stdcxx implementation, the std::basic_string copy constructor uses a >>> shared >>> underlying buffer implementation. This shared buffer creates the first >>> problem for >>> these classes: although the std::string object returned by value *appears* >>> to be owned >>> by the caller, it is, in fact, not. >>> In a mult-threaded environment, this underlying shared buffer can be >>> subsequently modified by a different thread than the one who made the >>> initial call. Furthermore, two or more different threads can access the >>> same shared buffer at the same time, and modify it, resulting in undefined >>> run-time behavior. >>> The cure for this defect has two parts: >>> 1. the member functions in question must truly return a copy by avoiding a >>> call to the copy constructor, and using a constructor which creates a deep >>> copy of the std::string. >>> 2. access to these member functions must be serialized, in order to >>> guarantee atomicity >>> of the creation of the std::string being returned by value. >>> Patch for 4.2.1 to follow. >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> > -- Wojciech Meyer http://danmey.org
Re: STDCXX-1056 : numpunct fix
Liviu Nicoara writes: > On Sep 20, 2012, at 5:23 PM, Stefan Teleman wrote: > >> On Thu, Sep 20, 2012 at 4:45 PM, Travis Vitek >> wrote: >> >>>> >>>> I'll let you in on a little secret: once you call setlocale(3C) and >>>> localeconv(3C), the Standard C Library doesn't release its own locale >>>> handles until process termination. So you might think you save a lot >>>> of memory by destroying and constructing the same locales. You're >>>> really not. It's the Standard C Library locale data which takes up a >>>> lot of space. >>> >>> You have a working knowledge of all Standard C Library implementations? >> >> I happen to do, yes, for the operating systems that I've been testing >> on. I also happen to know that you don't. This fact alone pretty much >> closes up *this* particular discussion. >> >> Do yourself, and this mailing list a favor: either write a patch which >> addresses all of your concerns *AND* eliminates all the race >> conditions reported, or stop this pseudo software engineering bullshit >> via email. >> >> There is apparently, a high concentration of know-it-alls on this >> mailing list, who are much better at detecting race conditions and >> thread unsafety than the tools themselves. Too bad they aren't as good >> at figuring out their own bugs. I fully agree - tools are great, however I know a little about compilers, and I can tell you that there are limits of static guarantees you can get from any analyser, because in nature there is something defined as a "halting problem", which limits the tools even the topnotch ones based on abstract interpretation to the certain extent. The halting problem says: "for every program in a formal language that is Turing complete you can't say with 100% assurance it will halt for every input data". You can try to analyse it statically, but then there is a balance between analysing and interpreting parts of it, even in the extreme case if you run it - you will not know if it suppose to halt. Therefore please use tools but be a bit reserved for the results. All these MT analysers are based on a simple heuristics and logical assertions that can't give you 100% right results. I don't think people here are picky about your patches, it's just better sometimes to take a breath and see the big picture. -- Wojciech Meyer http://danmey.org
Re: STDCXX-1056 : numpunct fix
Hi, My perceptions is by reading through the whole thread - we should not trust 100% external tools to asses the safety of the code. I don't think there exist an algorithm that produces no false positives. That's said I admire Stefan's approach, but we should ask the question are we MT safe enough? I would say from what I read here: yes. Liviu Nicoara writes: > On Sep 20, 2012, at 5:31 PM, Stefan Teleman wrote: > >> On Thu, Sep 20, 2012 at 5:07 PM, Liviu Nicoara wrote: > >> >> To answer your question [...]: >> yes, the MT failures occur on SPARC as well, on both SPARCV8 and >> SPARCV9, and the race conditions are reported on *ALL* plaforms >> tested, even after having applied your _numpunct.h patch. This patch >> alone does *NOT* solve the problem. > > Stefan, I want to be clear. You are talking about a patch identical in > nature to the one I have attached now. Just want to be 100% sure we > are talking about the same thing. This one still produces failures > (crashes, assertions, etc.) in the locale MT tests on SPARC and > elsewhere in your builds? > > Thanks, > Liviu > > -- Wojciech Meyer http://danmey.org
Re: STDCXX-1056 [was: Re: STDCXX forks]
Liviu Nicoara writes: > On 09/17/12 11:21, Stefan Teleman wrote: >> On Mon, Sep 17, 2012 at 11:17 AM, Liviu Nicoara wrote: >> >>> I hope you agree that this synchronization is sufficient for the facet >>> initialization and reading of facet data. >> >> Sorry, I do not agree. Two different thread analyzers from two >> different compilers written by two different compiler writers tell me >> not to. > > Stefan, that is indeed your prerogative. However, please keep in mind > that tools may be buggy or may have limitations beyond what is > advertised. I do not ask you to have faith in my analysis, which would > be absurd, but to look for yourself, exercise due diligence in testing > the code and draw your own conclusions. so which compilers do fail? You know, some of them might use the same component. -- Wojciech
Re: [PATCH] STDCXX-1067 Mac builds
Hi Liviu, I don't use Mac OS X at all but: Liviu Nicoara writes: > The default compiler on recent Apple Macs is LLVM with Clang and gcc > C++ front-ends. The compiler does not come with a C++ language support > library. However, gcc Mac builds are fine with GNU stock compilers, > modulo the issues for which I attach the patch below, for review. I think it will be a big win to support Clang for the community. > I built successfully and ran the test suite on both Mac and Linux, > wigh gcc 4.5.4 and 4.5.2, respectively. That's cool! > Thanks. > > Liviu Thanks. -- Wojciech Meyer http://danmey.org
Re: A question (or two) of procedure, etc.
Martin Sebor writes: > Anyone is welcome to express their opinion here, especially > if you are or have in the past contributed to the project. > The weight of the opinion is (or should be) commensurate to > the value of the contributions. I think the ASF calls this > Meritocracy. Thanks, that sounds sensible. > I made the stdcxx process increasingly more formal as I learned > from my own past mistakes that a loose process makes it harder > to track changes and find the root cause of the problems they > sometimes introduce. In practical terms, I've made an effort > to have an issue, with a test case if possible, for every > change made to the code, and commit a regression test into > the test suite for every bug fix. I can understand the reasons, system library programming is not a piece of cake, and must be taken with a great care. However, IMHO it's more important for the propriety projects to log everything in bug tracker, then just in the rcs, within the absence of commercial type of management. Maybe my opinion is a bit biased (I've never been a real tech lead so it's difficult to say), but please see below. > FWIW, in my day to day job, this is a requirement. Cisco > doesn't make a change to its code without an issue. My team > does the same with GCC changes. We find that projects that > don't follow this practice as closely (e.g., GNU Binutils), > tend to be more difficult for us to work with than those > that do. In my day time job it's also a requirement. At ARM we do put so much efforts to get the processes right, and no change is allowed without being logged in the tracker, peer reviewed, validated etc. It makes sense for the projects kind of compiler, kernel, or system library - no doubt I fully agree. However, I believe that it has other side of story, it comes with an overhead, sometimes it's just very difficult to do anything because it all needs to go through the process. It's really pleasant feeling (which is perhaps an attribute of open source), when you just go to the code, feel true confidence, fix the bug and commit. Of course it makes sense in a certain cases and with the complexity of stdcxx is just very difficult to feel that true confidence :-) By looking at what kind bugs Liviu, Stefan, and you have fixed/discussed, I had an impression that lot of this stuff is tweaking, and smaller re-engineering work which just takes a lot of time and experience, and notoriously difficult to get right. I hope I will also have a taste of stdcxx, perhaps I might look at something this weekend. I still need to commit (somewhat) the bigger patches for armcc. > > That being said, when it comes to the stdcxx configuration > machinery, or to the test suite, I think it's fine to be > somewhat less formal. We don't need test cases for problems > in configuration tests, or necessarily even test cases > reproducing failures in library tests (although small tests > can often be more useful than the large tests we have in > the test suite). We also don't need tests for makefile bugs. > Outside of that, when it comes to changing the library, I > do recommend making an effort to create test cases and open > issues for all changes. I fully agree with the test cases and the rest of the paragraph. It's really good to know your opinion! Thanks. -- Wojciech Meyer http://danmey.org
Re: A question (or two) of procedure, etc.
Liviu Nicoara writes: > I sure hope we can have totally open (civilized) discussions going > forward. :) Yes I'm also sure we can, thanks :-) -- Wojciech Meyer http://danmey.org
Re: A question (or two) of procedure, etc.
Liviu Nicoara writes: > What is the latest policy in what regards trivial fixes, e.g., the > volatile qualifier for the max var in LIMITS.cpp we discussed earlier, > etc.? It seems excessive to create a bug report for such issues. My advice based on some observations with other projects, is that in these cases we go just go on and apply fix. Non invasive code quality improvements over the codebase should be promoted not hindered. More risky patches, should be discussed on the list, the ones that needs either serious changes, attention, re-factoring, feature or fixes that may break something should be logged in Jira. So I vote for keeping the changes as lightweight as possible, and avoid extra bureaucracy if it makes sense. This assumption is based that developers here trust their selves, and run the tests often. I'm not subscribed to the commit list here, but if I do - I usually follow people's changes and assume that developers do read commit lists. So the general consensus from my experience with other project was: not sure - ask. That's my experience, also I don't have full rights to express my opinion right now about stdcxx. > Also, IIUC from reading previous discussions, forward and backward > binary compatible changes go in 4.2.x, followed by merges to 4.3.x and > trunk. Am I getting this right? Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). > > Also, besides the Linux, FreeBSD, Windows, Solaris builds hosted on Apache > (Jenkins) is anybody building on HP-UX, AIX, etc.? > > Thanks. > > Liviu > -- Wojciech Meyer http://danmey.org
Re: STDCXX forks
Jim Jagielski writes: > On Aug 31, 2012, at 8:40 AM, Liviu Nicoara wrote: > >> >> Stefan's seem like a complete git-ification of the whole Apache repository >> but with no changes I could detect. >> > > FWIW, The ASF supports git so if people think it would help, > all we'd need to do is ask #infra to move stdcxx to git. Git sounds much better to me, so I vote for it. -- Wojciech Meyer http://danmey.org
Re: stdcxx issue 1058
Hi Stefan, Stefan Teleman writes: > On Fri, Aug 31, 2012 at 1:29 PM, Liviu Nicoara wrote: >> On 08/31/12 13:14, Stefan Teleman wrote: >>> >>> >>> In June this year I committed r1353821 to trunk which fixes stdcxx-1058. >>> >>> I have the patches for 1058 ready to commit to branches (4.2.x and 4.3.x). >>> >>> OK to go? >> >> The patch looks ok to me. What seems to be the problem? +1 I also had a initial look at the patch. Looks OK, I looked at the other occurrences of "operator delete" to see if we are not doing the same thing. -- Wojciech Meyer http://danmey.org
Re: New committers?
Jim Jagielski writes: > On Sep 2, 2012, at 12:02 AM, Martin Sebor wrote: > >> On 08/31/2012 02:38 PM, Liviu Nicoara wrote: >>> My input below. >>> >>> On 08/31/12 09:42, Wojciech Meyer wrote: >>>> The two significant ones (as far as I can understand): >>>> >>>> - as I heard from Christopher Bergström that it's hard to push the >>>> stdcxx to FreeBSD ports repository (I can understand it and that >>>> sounds pretty bad, if that's the case then the board should consider >>>> re-licensing as advised; I agree in general it's a hard decision for >>>> the board, but imagine the project would benefit, IANAL tho) >>> >>> Christopher's wishes and goals may be different from others'. I do not >>> believe he has ulterior motives that would be detrimental to the rest of >>> us but AFAICT he has not made a compelling argument. Even with one, it >>> stretches the imagination what could possibly convince Apache to give up >>> on STDCXX ownership. >> >> Just a point of clarity: the ASF doesn't "own" stdcxx. They license >> it from Rogue Wave which still has the copyright. (Not that anyone >> there realizes it or would know what to do with it if they did.) >> IIUC, that's also why they can't relicense it under different terms. >> > > FWIW, the ASF never requires copyright assignment... Just a copyright > license to "reproduce, prepare derivative works of, publicly display, > publicly perform, sublicense, and distribute Your Contributions and > such derivative works." > > Also, there is nothing in our bylaws or in the various license > agreements that *exclude* the ASF ever releasing code not under > the ALv2 (how could it? After all, that would prevent us from > ever being able to move to ALv3). Again, we could, if we wanted > to (which we never will, btw) actually make our code under the > GPLv2... So what is this discussion all about, I think I got lost in all the if&buts of the licensing, again IANAL. Is there any FAQ, explaining on practical examples, like project X uses ALv2 and wants to link GPLv2 code Y, but is a system library, so project X can exploit clause #12345 of the GPLv2 license and do it, but needs to be licensed under GPLv2 or GPLv3, etc. Still I am reading that ALv2 does not require the fork to be licensed under the same license (!), so that made me completely lost: "The Apache License is permissive, so it does not require modified versions of the software to be distributed using the same license (unlike copyleft licenses - see comparison). In every licensed file, any original copyright, patent, trademark, and attribution notices in redistributed code must be preserved (excluding notices that do not pertain to any part of the derivative works); and, in every licensed file changed, a notification must be added stating that changes have been made to that file." (wikipedia; I can't read the original maze.) Sorry, but now I am out of this particular discussion. Thanks, -- Wojciech Meyer http://danmey.org
Re: New committers?
Jim Jagielski writes: > On Aug 31, 2012, at 2:27 PM, "C. Bergström" wrote: > >> On 09/ 1/12 01:25 AM, Jim Jagielski wrote: >>> Are you suggesting that FreeBSD does not allow the inclusion of ANY >>> ALv2 library under its ports directory? >> I'll give you the benefit of the a doubt one more time... >> >> stdcxx ends up linking against *EVERY* C++ application if it's used >> in the default compiler setup. (Which is what I was trying to >> achieve) That includes ***GPLv2 software in ports. Get >> it? >> > > I notice you did not answer my question... It's a simply question > and requires a simple yes or no. Are you suggesting that FreeBSD does > not allow the inclusion of ANY ALv2 library under its ports directory? > > Thx. Hi again, the point is that the stdcxx is rudimentary for the C++ applications, and if they are GPL then can't use stdcxx as a standard C++ library. Therefore it means that in this setting stdcxx becomes useless. The license in this case hinders the purpose of the library, which is bad in many ways, OTOH if AF used extensively C++ in their projects it would make sense to stick to have own non GPL library. From my point of view, there would be absolutely no problem if ALv2 was relaxed version of LGPL and more over compatible with it, but in this case it's less permissive than LGPL. which for such library is not appropriate since there are many GPL projects that do use C++. Libstc++ is LGPL therefore can link with GPL project, and can link with ALv2 project, but stdcxx is ALv2 and cannot link with GPL project. That's basically what LGPL was designed for, to solve this problem. It would be like libc was GPL, who would ever consider using that apart from GPLed projects? For third party standard library is even worse. One could blame the combination of unlucky choice of the ALv2 for this sort of project, or FSF being incompatible with that particular license being a root problem of stdcxx declining. So I understand that people that want to use stdcxx are being frustrated - because basically they can't freely use it. So I disagree with FSF being not able to accept Apache license, but accepting BSD license at the same point. I also see a point of relaxing license, to make the projects more successful, either something or completely nothing I would say. There is nothing better for the project to put it under BSD license, if the community fails to deliver what is needed. What Christopher is proposing is not to close the codebase or anything like this, he is trying to save the damn useful piece of code. and BTW: I was unaware about the licensing glitch between GPL vs ALv2 until know, and it appeared to me a broken concept from the Open Source point view (but it makes sense from the Free Software point of view) now I know why is this hot discussion etc. The worst scenario would be to put the project into attic, that would kill that codebase once for good. Please, don't. Now let's think clearly what can we do to keep it alive. I am willing to contribute still, but I see limited sense of all this operations, if we can't link it to C++ GPL programs. I'll leave this decision to Jim Jagielski, as he is word is the last here, but you know my view on that. (even if it matters little in the end) -- Wojciech Meyer http://danmey.org PS: "Linking exception" or "Dual licensing" would that solve the problem?
Re: New committers?
Jim Jagielski writes: > So how are/were they committers?? Hi! Chime in - I think we need to clarify what kind of problems we have with stdcxx being hosted as an Apache project. The two significant ones (as far as I can understand): - as I heard from Christopher Bergström that it's hard to push the stdcxx to FreeBSD ports repository (I can understand it and that sounds pretty bad, if that's the case then the board should consider re-licensing as advised; I agree in general it's a hard decision for the board, but imagine the project would benefit, IANAL tho) - I'm also reading through that methodology we use might not fit the distributed model which could basically improve the pace of development stream (and again github is nice at these things; but there are other considerations) Could somebody just prepare a list of impediments, and possible solutions, we can all workout a single solution that everybody will at least accept - I really don't want to lose faith in stdcxx - especially in such conditions. I still want to contribute, as Christopher said is a critical part of the C++ stack. We got a commit access, and the list seems to be more lively these days, so why not really try to do something useful with this! AFAIK there are 3 sides of this discussion: * Jim who wants to put the project into attic, but what he really cares is how to resurrect stdcxx, as it's an exceptional project for Apache. * Christopher who also thinks the project is exceptional, and should change the way we handle certain things. * and the rest who actually want to commit something and actually start developing, right? I can understand that putting stdcxx into attic might have a negative impact on the development, but doesn't inhibit forking. I'd vote not for putting attic still, as perhaps in case of stdcxx and current state of tools it might be that the project will not survive it, surely that's not Christopher, board and the rest of the developers want. So we agree on one thing, don't want to lose stdcxx and have freedom of the C++ standard library with frequent updates, and speed of development that is concurrent to gcc's libc++ and Clang libraries with a liberal license. So what we need to submit from everybody (not trying to be bossy this time :-)) 1) list of *real* impediments, concrete examples: so we can workout the plan. Bullet points would be great, similar to facts table Christopher has submitted. 2) list of our commitments vs. stdcxx: who is going to do what in the meantime. #1: Nothing comes to my mind right now, apart from not putting into attic for time being please, but I understand other people might have a lot of to say. #2: I plan to commit my patches to armcc port of stdcxx in the short time, and perhaps help with the Clang port as somebody already have mentioned, this certainly needs to be discussed! Cheers, Wojciech
Re: Assistance with account reset
> Could someone please tell me why I'm receiving these email? Perhaps, because it went to dev@stdcxx.apache.org? Regards, Wojciech Jake Foley writes: > -Original Message- > From: Tony Stevenson [mailto:t...@pc-tony.com] > Sent: Wednesday, August 29, 2012 4:00 AM > To: Daniel Shahaf > Cc: Martin Sebor; Infrastructure Apache; dev@stdcxx.apache.org; Liviu > Nicoara > Subject: Re: Assistance with account reset > > > On 29 Aug 2012, at 08:47, Daniel Shahaf wrote: > >> We don't do those by proxy. The alleged account owner should contact >> root@ or secretary@ and prove his identity > > He did ping root@ asking for it to be reset. I haven't followed up yet. > >> >> Martin Sebor wrote on Tue, Aug 28, 2012 at 18:30:37 -0600: >>> Can someone help Liviu get his password reset? >>> >>> Thanks >>> Martin >>> >>> On 08/28/2012 07:23 AM, Liviu Nicoara wrote: Hi, I need assistance with the resetting of my account, lnicoara at apache. I cannot reset my password via https://id.apache.org because I do not have the backup email account anymore, where the reset information > is sent. Thanks in advance. Liviu Nicoara >>> >> >> __ >> This email has been scanned by the Symantec Email Security.cloud service. >> For more information please visit http://www.symanteccloud.com >> __ > > Cheers, > Tony > > -- > Tony Stevenson > > t...@pc-tony.com > t...@caret.cam.ac.uk > pct...@apache.org > > http://www.pc-tony.com > > GPG - 1024D/51047D66 > -- > > > > -- Wojciech
RE: [VOTE] Retirement of stdcxx to the 'Attic'?
Hi William, On 2/5/2012 10:36 AM, Wojciech Meyer wrote: > > This is partially because stdcxx is still considered to be a derivate > > implementation of RogueWave in ARM toolchain, so upgrading at some > > point would have had a smaller impact on our customers than porting > > the toolchain into another library, apart from that I think this means > > that we will have yet smaller choice of C++ libraries avaiable - even > > if they are a bit outdated. > > > > Therefore -1. > You trimmed the vote thread... can we presume you are willing to be > active in the project? Sorry, my understanding was that the header tells everything, if there was an online poll please count this vote as -1 formally as: *not* putting the stdcxx Apache STL project to Apache Attic. Of course I would like to contribute if that's possible, I do have a formal agreement of ARM, at least for the ARM related patches - please see below. > > PS: I still have some pending patches to port it to ARM Compiler, if > > somebody would be happy to review it/commit it I would be happy to > > follow up - Martin was looking, but we both stuck at some point with > > having not enough time to do it. Now, as how the things stands I think > > they should be pushed. > It's necessary to push these at the bug tracker or the dev@ list. One > problem is that if you push it to an individual (e.g. Martin) then there > is no chance the community can help take up the slack when that individual > gets busy. I understand that. Some of them were put into Jira: STDCXX-1051 at least this. I can do some digging and find out if I tracked the other ones, otherwise I will raise them in Jira. 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.
RE: [disscuss] Retirement of stdcxx to the 'Attic'?
> * I would not like to see major changes to the build infrastructure at > this time. One of the goals of this project has been portability, and > this includes the build infrastructure. My understanding is that gmake > is considered to be more portable than some of the alternatives (cmake, > ant). I might disagree with that, since gmake on windows not only needs gmake.exe on path but also a several Cygwin tools. Also MSVC port needs separate nmake instructions. On other hand Cmake has - not nice indeed - a specialized language separated from the platform to regenerate needed build boilerplate. Just mine 2 cents, Wojciech From: Andrew Black [andrew.bl...@roguewave.com] Sent: Friday, February 03, 2012 9:48 PM To: dev@stdcxx.apache.org Subject: Re: [disscuss] Retirement of stdcxx to the 'Attic'? Like Farid, I too am willing to help process patches for review and submission. Once a track record has been established, someone on the PMC would likely raise a motion to designate you as a committer, as defined at http://stdcxx.apache.org/#committers . This would allow you to make changes directly to subversion without assistance. Do note that in order to be designated as such, you will need to have a Contributor License Agreement ( http://www.apache.org/licenses/icla.txt ) on file with the Apache foundation. If you are being paid to perform this work, the company you work for will likely need to have a Corporate Contributor License Agreement ( http://www.apache.org/licenses/cla-corporate.txt ) on file. If we are trying to revitalize this project, there are a few things I personally would/would not like to see in the patches: * I would not like to see major changes to the build infrastructure at this time. One of the goals of this project has been portability, and this includes the build infrastructure. My understanding is that gmake is considered to be more portable than some of the alternatives (cmake, ant). * I would like to see tests added to verify any library changes. Ideally the new tests will pass on most platforms, though we don't currently have an automated test mechanism in place. If any existing tests are incorrect, commentary for the change about why they are broken would be appreciated. * Changes destined for the 4.2.x branch should have forwards and backwards binary compatibility. * Changes destined for the 4.3.x branch should have backwards source compatibility. --Andrew Black On 02/03/2012 03:04 PM, Farid Zaripov wrote: > On 03.02.2012 1:52, Stefan Teleman wrote: >> 2. Someone with stdcxx commit privileges should be part of this >> reunification (for obvious reasons). It is very discouraging to submit >> patches knowing full well and ahead of time that they will never make >> it anywhere. Perhaps the process of submitting patches could be >> somewhat less of a "process". Just my 0.02. --Stefan > > Stefan, if you split the all your patches to a set of small finalized > changes and submit them through a set of corresponding issues in JIRA, I > promise I will process them all one by one. > At the moment I don't see any issues, reported by you. Sorry, but > process is a process. > > Farid. > -- 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.
RE: [VOTE] Retirement of stdcxx to the 'Attic'?
Hi all, -1 This is partially because stdcxx is still considered to be a derivate implementation of RogueWave in ARM toolchain, so upgrading at some point would have had a smaller impact on our customers than porting the toolchain into another library, apart from that I think this means that we will have yet smaller choice of C++ libraries avaiable - even if they are a bit outdated. Therefore -1. PS: I still have some pending patches to port it to ARM Compiler, if somebody would be happy to review it/commit it I would be happy to follow up - Martin was looking, but we both stuck at some point with having not enough time to do it. Now, as how the things stands I think they should be pushed. Wojciech From: Farid Zaripov [far...@apache.org] Sent: Friday, February 03, 2012 7:34 PM To: dev@stdcxx.apache.org Subject: Re: [VOTE] Retirement of stdcxx to the 'Attic'? On 02.02.2012 19:03, William A. Rowe Jr. wrote: > Fans and contributors, > > it appears that the stdcxx project is entirely dormant. The ASF has > launched a new 'Attic' project over the past two years, to neatly > retire dormant works until and unless a community comes along who > wishes to revive the effort. > > As a simple formality your votes please; > > [ ] +1 - stdcxx committee should be retired, with code sent to the Attic > > [X] -1 - No, stdcxx should not fold, I am still contributing, and >[would serve|am serving] on its project management committee > > The results of this vote will be taken up by the ASF Board of Directors > at their 15 Feb meeting. I have not too much time for active developing the stdcxx, but I can review user patches, test them on a set of Microsoft compilers and commit into svn. In the other words, I can provide support of the stdcxx to the users if any exist :). Also I plan to smoothly move the stdcxx in the C++ 0x direction. So my vote is: -1 Farid. -- 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.
RE: STDCXX "fork"
> Hi all Hi, > 1) "better" cmake build system (Actually this has nothing to do with > Apache or the current build system.) > 2) Faster code review, QA and easier contribution process (Only the last > part is slowed down by Apache) > 3) Actively maintained (To start just bug fixes, better support for > Win/ARM/Solaris and performance improvements[2]. If we get enough > interest we'll start on C++0x) We have some armcc porting patches against 5.2.1 (or trunk), would you be able to try to include them in your "big merge"? They are basically build system amendments to cross compile stdcxx with our compiler and make it work with our run time. Obviously if the build system is going to change, I would need to spend some time porting them to cmake (hopefully it will be straight forward), so let me know WDYT. > Note: The cmake based build system isn't in the tree now and should > merge mid/late next week. Great. > If you're interested > https://github.com/pathscale/stdcxx/ Already cloned. > If you have outstanding patches please clone and send a pull request. > We're going to work hard to get all the backlog of stuff reviewed and > integrated. Will do. Thanks! > ./C 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.
RE: patch for STDCXX-1051
> > Now, it would be all fine besides that stdcxx build system checks for > > this flag here > > > > (..) > > etc/config/GNUmakefile.cfg:247: > >elif [ ! -x $$file ] ; then\ > >nm -gp $$file.o 2>&1 | grep "T *main *$$">/dev/null ; \ > >test -f $$file.o -a ! $$? -eq 0 ; \ > >else \ > >echo "./$$file">>$(LOGFILE) ; \ > >LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:. ; \ > >LIBPATH=$$LIBPATH:. ; \ > >export LIBPATH LD_LIBRARY_PATH ; \ > >text=`./$$file` ; \ > >fi;\ > > (..) > > > > So, I needed to do it manually to ensure it does search for > > that. Using this shell trickery everything seems to work fine. > > > > Let me know your thoughts. > The change would cause problems for the HP linker. We don't > want to break one build to make another work. Ouch, no good. > One way you could work around it is by writing a wrapper > script for your linker and setting the executable bit in > it. From a design POV, since your linker behaves in > an "unusual" way (i.e., different than all the linkers > stdcxx usually targets), Yes indeed, I thought the same, maybe we should set up this flag. I raised that to the linker person, and he said that it would be an enhancement to actually provide a command-line switch to support it. For time being please commit your version of the patch, and I will stick with the wrapper script. I will send another (bigger) patch soon. Thanks. > I would prefer to avoid changing > the configuration machinery this way. But if you can come > up with a "clean" solution that improves the machinery for > all linkers I would certainly support it. I will try to figure out this as well. > Martin Thanks, 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.
RE: patch for STDCXX-1051
> > 2) Removed the changes to the link and compile_then_link > > functions. Because of the comments within them these > > were effectively commented out and had no effect. > > I also don't understand why the chmod +x command is > > necessary. The linker should set the executable bit after > > a successful link. There is one linker (HP) that fails (or > > used to) to delete the output file on failure (maybe when > > when it crashes). With that linker the only way to tell > > that the file is bad (other than the exit status of the > > linker) is by examining the executable bit. > I don't remember why I did this, but I remember it was something > that I needed to do, probably it was related somewhat to > cross-compilation. Now I know! The reason behind it, is that our linker which performs linking *does not* setup executable flag on the destination file. It's an image which should not be executed directly anyway. Now, it would be all fine besides that stdcxx build system checks for this flag here (..) etc/config/GNUmakefile.cfg:247: elif [ ! -x $$file ] ; then\ nm -gp $$file.o 2>&1 | grep "T *main *$$" >/dev/null ; \ test -f $$file.o -a ! $$? -eq 0 ; \ else \ echo "./$$file" >>$(LOGFILE) ; \ LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:. ; \ LIBPATH=$$LIBPATH:. ; \ export LIBPATH LD_LIBRARY_PATH ; \ text=`./$$file` ; \ fi;\ (..) So, I needed to do it manually to ensure it does search for that. Using this shell trickery everything seems to work fine. Let me know your thoughts. Thanks! Wojciech
RE: patch for STDCXX-1051
Hi Martin, > I've reviewed your patch for STDCXX-1051. It looks reasonable > to me. I've made a couple of minor changes (see the attached > diff): Thanks for this! :) > 1) Renamed EXEC_RUNNER to CFG_EXEC to match the .cfg suffix > we use for some of the configuration files (such as > GNUMakefile.cfg), and left it unset by default to avoid > unnecessarily invoking the shell by default. The extra > shell invocation can be quite expensive on systems line > CygWin and make the configuration process very slow. Yes, I didn't know the convention, and indeed Cygwin especially on the network is very expensive, configuration of stdcxx takes while. > 2) Removed the changes to the link and compile_then_link > functions. Because of the comments within them these > were effectively commented out and had no effect. > I also don't understand why the chmod +x command is > necessary. The linker should set the executable bit after > a successful link. There is one linker (HP) that fails (or > used to) to delete the output file on failure (maybe when > when it crashes). With that linker the only way to tell > that the file is bad (other than the exit status of the > linker) is by examining the executable bit. I don't remember why I did this, but I remember it was something that I needed to do, probably it was related somewhat to cross-compilation. > It is necessary in case of cross-compilation > I've successfully tested the attached patch both ways, with > and without a CFG_EXEC script. Let me know if this works for > you. Thanks! I will get back to you someday tomorrow or in the middle of this week and let you know if that all works for me. There will be few patches more.. I'll do my best to reduce from you burden of veryfing and applying them. > Martin Wojciech
RE: [PATCH] STDCXX-1051: Stdcxx build process needs to be able to run configuration executable files created by the build system during configuration step on emulators in order to cross compile the li
Hi Martin, > Yes, the configure machinery wasn't design with cross compilation > in mind. We could probably eliminate some, even may, of the runtime > tests and replace with them compilation (plus linking) only tests. > Besides making cross compilation easier, doing so would also speed > up the configuration process. Yes, the configuration time is kind of bottleneck now. It happens now, (Windows Cygwin build, with a compiler wrapped with a script to convert Cygwin style paths to Windows on VMware) to take I think about 20 sec for each file. It is not that dramatic when you use native gcc for instance, but in this case it is unbearable. Spawning a model for each configuration script is also quite time consuming. However, despite that I like the stdcxx build system (but I will not say replacing with something different is bad idea, just I don't have major problems with it). > I don't see the patch. If you attached it, I suspect it got stripped > by ezmlm. That tends to happen when using Outlook. Other email clients > don't have the problem. If you continue to be unable to attach patches > to your posts a (less preferable, IMO) alternative is to attach them > to the Jira issue. Yes, I attached it, it seems to got lost (I am forced to use Outlook here not my favourite MUA Gnus :) ). > Martin Thanks, 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.
RE: [PATCH] STDCXX-1051: Stdcxx build process needs to be able to run configuration executable files created by the build system during configuration step on emulators in order to cross compile the li
Martin, Done (in Jira). Thanks, Wojciech -Original Message- From: Martin Sebor [mailto:mse...@gmail.com] Sent: 23 September 2010 15:59 To: dev@stdcxx.apache.org Cc: Wojciech Meyer Subject: Re: [PATCH] STDCXX-1051: Stdcxx build process needs to be able to run configuration executable files created by the build system during configuration step on emulators in order to cross compile the library On 09/20/2010 06:46 AM, Wojciech Meyer wrote: > Hi, > > We are trying to cross compile stdcxx library. The problem we are facing > > is that there is no way of telling stdcxx build system, that we don't > > want to run configuration files created by configuration step by build > > system directly on a host system (through a shell). > > For instance, this command (taken from log): > > ./UNISTD_DECL > > invoked during configuration process runs natively the executable through > > a shell. Yes, the configure machinery wasn't design with cross compilation in mind. We could probably eliminate some, even may, of the runtime tests and replace with them compilation (plus linking) only tests. Besides making cross compilation easier, doing so would also speed up the configuration process. > > However we want to be able to run it on an emulator like this: > > UNISTD_DECL > > This command will run the UNISTD_DECL through an emulator. > > The patch we are proposing, is to introduce a new Makefile variable, called > > EXEC_RUNNER, which allows us to do it. > > EXEC_RUNNER defaults to "/bin/sh -c". so it does not interfere with > > the rest of build process (at least on Unix/MSys/Cygwin environment, > > pure Win32 platform has completely separate build system). This makes sense to me. > > Patch is against `trunk'. I don't see the patch. If you attached it, I suspect it got stripped by ezmlm. That tends to happen when using Outlook. Other email clients don't have the problem. If you continue to be unable to attach patches to your posts a (less preferable, IMO) alternative is to attach them to the Jira issue. Martin > > TIA > > Wojciech >
RE: [PATCH] STDCXX-1051: Stdcxx build process needs to be able to run configuration executable files created by the build system during configuration step on emulators in order to cross compile the li
> C. Bergström wrote: > > We have ported stdcxx over to cmake and will likely be cross compiling. > > (mingw and other targets) When the work is more complete I'll ping you > > for early testing. > Thanks. > That's a good news. Please do a pull request on ML once it's working. BTW: We will have some more patches that you might be interested in, particularly related to `stdcxx vs no-posix stuff', please see this thread: http://www.mail-archive.com/dev@stdcxx.apache.org/msg01625.html It would be good to coordinate if you plan some massive changes on trunk, (the former patch applies to stdcxx-4.2.x line too). Wojciech
RE: [PATCH] STDCXX-1051: Stdcxx build process needs to be able to run configuration executable files created by the build system during configuration step on emulators in order to cross compile the li
C. Bergström wrote: > We have ported stdcxx over to cmake and will likely be cross compiling. > (mingw and other targets) When the work is more complete I'll ping you > for early testing. Thanks. That's a good news. Please do a pull request on ML once it's working. Wojciech
[PATCH] STDCXX-1051: Stdcxx build process needs to be able to run configuration executable files created by the build system during configuration step on emulators in order to cross compile the librar
Hi, We are trying to cross compile stdcxx library. The problem we are facing is that there is no way of telling stdcxx build system, that we don't want to run configuration files created by configuration step by build system directly on a host system (through a shell). For instance, this command (taken from log): ./UNISTD_DECL invoked during configuration process runs natively the executable through a shell. However we want to be able to run it on an emulator like this: UNISTD_DECL This command will run the UNISTD_DECL through an emulator. The patch we are proposing, is to introduce a new Makefile variable, called EXEC_RUNNER, which allows us to do it. EXEC_RUNNER defaults to "/bin/sh -c". so it does not interfere with the rest of build process (at least on Unix/MSys/Cygwin environment, pure Win32 platform has completely separate build system). Patch is against `trunk'. TIA Wojciech
RE: stdcxx and POSIX
Hello Martin, Any good news about the patch? :) Wojciech -Original Message- From: Martin Sebor [mailto:mse...@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.me...@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:mse...@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:mse...@gmail.com] >>
RE: stdcxx and POSIX
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.me...@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:mse...@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:mse...@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 thi
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:mse...@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:mse...@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'
RE: stdcxx and POSIX
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:mse...@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:mse...@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' >&
RE: stdcxx and POSIX
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.
stdcxx and POSIX
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. We have found some occurrences of POSIX
headers and symbols in file.cpp and iostream.cpp. Although
run-time behavior for iostreams can be changed by passing
unofficial extension to openmode _RWSTD_IOS_STDIO, but the POSIX
symbols are still present, so the compilation will fail. There is
_RWSTD_NO_NATIVE_IO as the README file says:
o _RWSTD_NO_NATIVE_IO
[lib, over]
#defined to force file streams to use the facilities of libc
stdio as opposed to the POSIX I/O interface.
and here:
#ifndef _RWSTD_NO_NATIVE_IO
# define _RWSTD_INVALID_FILE -1
# define _RWSTD_INVALID_OPENMODE -1
#else
# define _RWSTD_INVALID_FILE (FILE*)0
# define _RWSTD_INVALID_OPENMODE 0
#endif // _RWSTD_NO_NATIVE_IO
but that does not to fix the problem at all.
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.
Thanks.
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.
