[PATCH] Trivial test fix
Would someone please apply the patch on 4.2.x branch? (I have not yet regained access to my Apache account.) 2012-09-01 Liviu Nicoara nikko...@hates.ms * tests/containers/23.bitset.cpp: swapped lines to avoid compiler bug (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54442) Index: tests/containers/23.bitset.cpp === --- tests/containers/23.bitset.cpp (revision 1379762) +++ tests/containers/23.bitset.cpp (working copy) @@ -278,8 +278,8 @@ test_synopsis (std::bitset0*) MEMFUN (Bitset, flip, ()); MEMFUN (Bitset, flip, (std::size_t)); -MEMFUN (Bitset::reference, operator[], (std::size_t)); MEMFUN (bool, operator[], (std::size_t) const); +MEMFUN (Bitset::reference, operator[], (std::size_t)); MEMFUN (unsigned long, to_ulong, () const);
Re: New committers?
On Aug 31, 2012, at 5:24 PM, Wojciech Meyer wojciech.me...@googlemail.com wrote: 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. Nope... LGPL was designed as a counterpoint to the GPL, NOT to other-licensed libs.
Re: STDCXX forks
On 08/31/12 12:20, Stefan Teleman wrote: On Fri, Aug 31, 2012 at 8:40 AM, Liviu Nicoara nikko...@hates.ms wrote: Stefan's seem like a complete git-ification of the whole Apache repository but with no changes I could detect. Not quite. :-) [...] The official Oracle port for Solaris 10 and 11, which I maintain, is here: http://src.opensolaris.org/source/xref/userland/gate/components/stdcxx/ Hi Stefan, I have went through the patches. Specifically, I have spent more time looking in the mutex alignment changes and the C++ C library headers patches, and I only read the others. In order: The test extensions seem to be genuine by and large, but I would further analyze them after I find out what is it they are addressing (test cases?). The regression tests whose names contain references to internal bug numbers require a bit more analysis as to their usefulness. Of course an explanation attached to each would alleviate duplicating your work. I have not cross-checked them to JIRA. Some of the compiler characterizations changes, as well as the associated GNUmakefile's, seem to be specific to your port, e.g., GNUmakefile, GNUmakefile.cfg changes. I may have spotted other issues but I would wait for your feed-back first. The C++ C library headers seem to have been re-written to your port. I am unsure why you needed this, but it surely breaks the original intent for these headers' structure. I have also noticed that you stripped the Apache notice and added an Oracle copyright notice on them. This pretty much sums up my first impression. If you were willing to submit them one by one (*), complete with test cases and complete patches (ChangeLog entries and all) I would put in the necessary review time and provide feed-back asap. Please let me know if I missed anything. I sincerely hope this helps. Thanks! Liviu (*) As in issue by issue, not file by file.
Re: [PATCH] Trivial test fix
On Sat, Sep 1, 2012 at 10:49 AM, Liviu Nicoara nikko...@hates.ms wrote: Would someone please apply the patch on 4.2.x branch? (I have not yet regained access to my Apache account.) 2012-09-01 Liviu Nicoara nikko...@hates.ms * tests/containers/23.bitset.cpp: swapped lines to avoid compiler bug (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54442) Index: tests/containers/23.bitset.cpp === --- tests/containers/23.bitset.cpp (revision 1379762) +++ tests/containers/23.bitset.cpp (working copy) @@ -278,8 +278,8 @@ test_synopsis (std::bitset0*) MEMFUN (Bitset, flip, ()); MEMFUN (Bitset, flip, (std::size_t)); -MEMFUN (Bitset::reference, operator[], (std::size_t)); MEMFUN (bool, operator[], (std::size_t) const); +MEMFUN (Bitset::reference, operator[], (std::size_t)); MEMFUN (unsigned long, to_ulong, () const); Done - revision 1379813. --Stefan -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
Re: STDCXX forks
On 08/31/12 08:58, C. Bergström wrote: On 08/31/12 07:40 PM, Liviu Nicoara wrote: Please correct me if I am wrong. I have seen two forks on github, one belonging to C. Bergstrom/Pathscale and the other to Stefan Teleman. The first one contains a number of genuine code changes outside the Apache repository, but without canonical and meaningful commit comments, and without accompanying test cases. We can help clean this up if it makes a real difference Some carry what seem to be bug id's from a private bug database. Some of the changes, e.g., 84d01405124b8c08bb43fdc3755ada2592449727 iirc we renamed the files because of some problem with cmake - it was trying to compile those files instead of treating them like headers. , fa9a45fb36e45b71ba6b4ae93b50bd6679549420, seem odd. I forget why we did this tbh - I'll try to get an answer in case it comes up again as a question Are you guys dropping support for any platforms? Not intentionally - We are using/testing this on Solaris, FBSD and Linux - We may add OSX/Win to that list soon, but I can't promise at this point. For targets we only are able to test x86 and x86_64 Hi Christopher, I finished looking though the github changes. If you are interested in contributing some of those changes back, as complete patches [1], I would volunteer my time to promptly review them and work with you to get them in, as needed. In the meantime, if you will, could you please elaborate on the two changes mentioned above? The first one changes the traditional file extension on the template implementation files, the second affects the library building on platforms like I mentioned in another post. AFAIK STDCXX does not implement or follow Boost conventions and/or library file structure. HTH. Thanks! Liviu [1] http://stdcxx.apache.org/bugs.html#patch_format
Re: STDCXX forks
On Sat, Sep 1, 2012 at 12:15 PM, Liviu Nicoara nikko...@hates.ms wrote: Hi Stefan, I have went through the patches. Specifically, I have spent more time looking in the mutex alignment changes and the C++ C library headers patches, and I only read the others. In order: The test extensions seem to be genuine by and large, but I would further analyze them after I find out what is it they are addressing (test cases?). The regression tests whose names contain references to internal bug numbers require a bit more analysis as to their usefulness. Of course an explanation attached to each would alleviate duplicating your work. I have not cross-checked them to JIRA. Some of the compiler characterizations changes, as well as the associated GNUmakefile's, seem to be specific to your port, e.g., GNUmakefile, GNUmakefile.cfg changes. I may have spotted other issues but I would wait for your feed-back first. The C++ C library headers seem to have been re-written to your port. I am unsure why you needed this, but it surely breaks the original intent for these headers' structure. I have also noticed that you stripped the Apache notice and added an Oracle copyright notice on them. This pretty much sums up my first impression. Hi Yes, you are correct. :-) To begin with: the compiler flags/GNUmakefile changes are very specific to the SunPro compilers and to our internal build system. These changes are most likely not suitable for inclusion in the canonical stdcxx, except maybe for the sunpro.config changes, in case someone would like to be able to replicate our builds. I'd like to mention that, in Solaris, Apache stdcxx is a system library. About the Standard C Library forwarding header files: these changes are specfic to Solaris. The reason behind them is: the Solaris architectural rules, which can be best summarized as: there can be only one of each. In other words, it is Verboten, in Solaris, to duplicate the Standard C Library header files (or any other header file for that matter). The Solaris Standard C Library header files are C++-clean - they are required to be so, by the same architectural rules. Again, these changes are specific to Solaris, and are probably not portable across other implementations. I know for a fact that they are not portable for either the GCC or Intel compilers (with which I test regularly on Linux, in addition to SunPro). So these two groups of changesets can be ignored. I opened yesterday STDCXX-1066: https://issues.apache.org/jira/browse/STDCXX-1056 about the pthread_mutex_t/pthread_cond_t alignment on SPARCV8. I'll have patches done this weekend. Achtung: the patchset is very large and touches a very large number of files. It's strange that I didn't get an email about STDCXX-1066. I'd also like to talk about STDCXX-1056: https://issues.apache.org/jira/browse/STDCXX-1056 which has already had an initial discussion, and for which I have attached a patch. This issue also addresses (indirectly) linkage when building with GCC. On the recent versions of GCC that I have tested with, passing -supc++ on link line automatically links with the GNU libstdc++6.so (on top of linking with stdcxx), and that just bad. And then I'll have to cross reference the patches which refer to our internal bug numbers because most of them are quite old and right now, off the top of my head, I can't remember what they are. :-) --Stefan -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
Re: STDCXX forks
On Sep 1, 2012, at 1:52 PM, Stefan Teleman wrote: On Sat, Sep 1, 2012 at 12:15 PM, Liviu Nicoara nikko...@hates.ms wrote: [...] This pretty much sums up my first impression. [...] To begin with: the compiler flags/GNUmakefile changes are very specific to the SunPro compilers and to our internal build system. These changes are most likely not suitable for inclusion in the canonical stdcxx, except maybe for the sunpro.config changes, in case someone would like to be able to replicate our builds. I'd like to mention that, in Solaris, Apache stdcxx is a system library. Good point. About the Standard C Library forwarding header files: these changes are specfic to Solaris. The reason behind them is: the Solaris architectural rules, which can be best summarized as: there can be only one of each. In other words, it is Verboten, in Solaris, to duplicate the Standard C Library header files (or any other header file for that matter). The Solaris Standard C Library header files are C++-clean - they are required to be so, by the same architectural rules. Again, these changes are specific to Solaris, and are probably not portable across other implementations. I know for a fact that they are not portable for either the GCC or Intel compilers (with which I test regularly on Linux, in addition to SunPro). So these two groups of changesets can be ignored. Got it. I opened yesterday STDCXX-1066: https://issues.apache.org/jira/browse/STDCXX-1056 about the pthread_mutex_t/pthread_cond_t alignment on SPARCV8. I'll have patches done this weekend. Achtung: the patchset is very large and touches a very large number of files. It's strange that I didn't get an email about STDCXX-1066. Acknowledged. I have seen the individual patches on those two websites. I'd also like to talk about STDCXX-1056: https://issues.apache.org/jira/browse/STDCXX-1056 which has already had an initial discussion, and for which I have attached a patch. This issue also addresses (indirectly) linkage when building with GCC. On the recent versions of GCC that I have tested with, passing -supc++ on link line automatically links with the GNU libstdc++6.so (on top of linking with stdcxx), and that just bad. I briefly looked at it, will delve into it later. And then I'll have to cross reference the patches which refer to our internal bug numbers because most of them are quite old and right now, off the top of my head, I can't remember what they are. :-) Thanks! Liviu
Re: Branching policy, 4.3.x, 5.0.0, etc.
On 08/31/2012 12:52 PM, Stefan Teleman wrote: On Fri, Aug 31, 2012 at 2:46 PM, Liviu Nicoara nikko...@hates.ms wrote: On 08/31/12 14:15, Stefan Teleman wrote: My understanding is that 4.2.x and 4.3.x are bugfix/rfe releases while 5.x would become C++2011. There is an implicitly stated binary incompatibility between 4.2 and 4.3. Are you privy to what prompted 4.3.x? I could look it up, I just didn't get that far. Nope, don't know what prompted 4.3.x - Martin probably knows. Most likely the first forward incompatible change. The ChangeLog should say which. 4.3 is source and backward binary compatible with 4.2, and 5.0 isn't necessarily either. All 4.2.x releases are backward and forward binary compatible with one another. The goal of 4.2.2 is to contain trivial bug fixes for 4.2.1, 4.3 is for somewhat bigger bug fixes. 5.0 meant for is C++ 11 as Stefan says where we can break binary (and even source) compatibility. Martin --Stefan
