Boost with Clang via MinGW-w64
Hey all, Ruben over at the MinGW-w64 project has started providing a Clang toolchain built upon MinGW-w64. http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-July/016005.html I just tried compiling Boost trunk r72754 with it, and figured I'd post the output here so work can commence bringing it in line with GCC via MinGW-w64. 90% of the errors seem to be a result of a 'call to deleted constructor' which seems to be caused by the shared_ptr library (or its usage)... Then the remaining 5% seem to be quite similar in nature, so it doesn't look like stuff will be too horrible to fix, but I don't know enough about the implementation of shared_ptr to fix it at the moment. One other thing to take into consideration will be the lack of a Clang Windows toolset. Currently when you set your toolset to Clang under MinGW, Boost treats it as Clang-Linux. I'm not sure what exactly that will affect... The script I used and the resulting output is available here: http://www.raptorfactor.com/code/Boost-Clang-MinGW-Output-20110708a.zip Thanks..
Yeah, I suspected that too at first, but then I had a quick look through the commit log and couldn't see anything that would cause it, and I doubted that it would be a long-standing bug as Clang compiles Boost under other platforms... Tbh though I have no idea, which is why I'm deferring to someone with a bit more experience in this area. On Fri, Jul 8, 2011 at 6:24 PM, Peter Dimov <pdimov@pdimov.com> wrote:
Joshua Boyce wrote:
90% of the errors seem to be a result of a 'call to deleted constructor'
which seems to be caused by the shared_ptr library (or its usage)...
This looks like a bug in clang to me. ______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
On 08.07.2011 11:15, Joshua Boyce wrote:
Yeah, I suspected that too at first, but then I had a quick look through the commit log and couldn't see anything that would cause it, and I doubted that it would be a long-standing bug as Clang compiles Boost under other platforms...
Tbh though I have no idea, which is why I'm deferring to someone with a bit more experience in this area. Could be something about that specific libstdc++ Clang can't handle.
Sebastian
According to the Clang mailing list this is in fact a Boost defect. http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-July/016195.html On Fri, Jul 8, 2011 at 7:57 PM, Sebastian Redl < sebastian.redl@getdesigned.at> wrote:
On 08.07.2011 11:15, Joshua Boyce wrote:
Yeah, I suspected that too at first, but then I had a quick look through the commit log and couldn't see anything that would cause it, and I doubted that it would be a long-standing bug as Clang compiles Boost under other platforms...
Tbh though I have no idea, which is why I'm deferring to someone with a bit more experience in this area.
Could be something about that specific libstdc++ Clang can't handle.
Sebastian
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
On Sun, Jul 17, 2011 at 11:07 AM, Joshua Boyce <raptorfactor@raptorfactor.com> wrote:
According to the Clang mailing list this is in fact a Boost defect.
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-July/016195.html
Although the rest of that post seems correct, the paragraph mentioned in that posting is wrong, since it is about copy assignment rather than copy construction. The correct paragraph in the FDIS is 18.2, paragraph 7, which reads "If the class definition does not explicitly declare a copy constructor, one is declared implicitly. If the class definition declares a move constructor or move assignment operator, the implicitly declared copy constructor is defined as deleted; otherwise, it is defined as defaulted (8.4). The latter case is deprecated if the class has a user-declared copy assignment operator or a user-declared destructor. ..." So this does look like a bug in Boost shared_ptr code. Incidentally, I was recently bitten by the same problem, but mistakenly thought I was dealing with a compiler bug so just worked around it by defining the copy constructor:-) --Beman
participants (4)
-
Beman Dawes -
Joshua Boyce -
Peter Dimov -
Sebastian Redl