GNOME Bugzilla – Bug 712539
invalid application of 'sizeof' to an incomplete type 'value_type' (aka 'pan::Log::Entry')
Last modified: 2016-03-18 21:01:57 UTC
Created attachment 260042 [details] build log Building pan2 0.139 fails on OS X 10.9 Mavericks. This was also reported to the MacPorts project here: https://trac.macports.org/ticket/41402. I'm attaching a full log from trying to build this in MacPorts.
Have you been able to make any progress on resolving this issue? Users are unable to build pan2 on OS X 10.9 or later because of this issue.
Users continue to ask us why pan2 does not build on OS X 10.9 or later, and we continue to have to refer them here, though no progress appears to be occurring. Have you done anything yet to figure out why your program does not build with libc++ or how to fix it? I do not write C++ code so I am not well equipped to help you resolve this issue.
Building on MacPorts 2.3.3 Mac OS X 10.10.5 (Yosemite) Xcode 6.4 Build version 6E35b Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.5.0 Thread model: posix Using -stdlib=libc++ (default for OS X 10.9+) build fails as follows: :info:build /usr/bin/clang++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -D_REENTRANT -I/opt/local/include/gmime-2.6 -I/opt/local/include -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/opt/local/include -I/opt/local/include -pipe -Os -arch x86_64 -stdlib=libc++ -MT filter-info.o -MD -MP -MF .deps/filter-info.Tpo -c -o filter-info.o filter-info.cc :info:build In file included from filter-info.cc:26: :info:build In file included from ./filter-info.h:23: :info:build /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/deque:912:49: error: invalid application of 'sizeof' to an incomplete type 'value_type' (aka 'pan::FilterInfo') :info:build static const difference_type __block_size = sizeof(value_type) < 256 ? 4096 / sizeof(value_type) : 16;:info:build ^~~~~~~~~~~~~~~~~~ :info:build /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/deque:1183:15: note: in instantiation of template class 'std::__1::__deque_base<pan::FilterInfo, std::__1::allocator<pan::FilterInfo> >' requested here :info:build : private __deque_base<_Tp, _Allocator> :info:build ^ :info:build ./filter-info.h:81:20: note: in instantiation of template class 'std::__1::deque<pan::FilterInfo, std::__1::allocator<pan::FilterInfo> >' requested here :info:build aggregates_t _aggregates; :info:build ^ :info:build ./filter-info.h:34:9: note: definition of 'pan::FilterInfo' is not complete until the closing '}' :info:build class FilterInfo :info:build ^ The problem seems to be that, opposed to libstdc++, the implementation of deque in libc++ uses sizeof() on its argument. This causes the statements /** Convenience typedef. */ typedef std::deque<FilterInfo> aggregates_t; /** When `_type' is AGGREGATE_OR or AGGREGATE_AND, these are the filters being or'ed or and'ed together. */ aggregates_t _aggregates; in the definition of class FilterInfo to fail because the definition of pan::FilterInfo is not complete at that point. This will only work after the closing } of the definition. A similar usage occurs in the definition of class RulesInfo. See pan/usenet-utils/filter-info.h pan/usenet-utils/rules-info.h In addition to this error, the following deprecation warning can be seen in the same files :info:build In file included from filter-info.cc:26: :info:build In file included from ./filter-info.h:24: :info:build In file included from ../../pan/general/quark.h:35: :info:build /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ext/hash_set:205:5: warning: Use of the header <ext/hash_set> is deprecated. Migrate to <unordered_set> [-W#warnings] :info:build # warning Use of the header <ext/hash_set> is deprecated. Migrate to <unordered_set> :info:build ^ :info:build In file included from rules-info.cc:30: :info:build In file included from ./rules-info.h:24: :info:build In file included from ../../pan/general/quark.h:35: :info:build /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ext/hash_set:205:5: warning: Use of the header <ext/hash_set> is deprecated. Migrate to <unordered_set> [-W#warnings] :info:build # warning Use of the header <ext/hash_set> is deprecated. Migrate to <unordered_set> :info:build ^ There may be more libc++ issues elsewhere but this is a start.
I should add that the error/warning messages in comment 3 came from a build of the latest git master commit af878257ee5dba08a350e2a8f73493b661a4320f
This problem is fixed in the current version of Pan from the git repository. I've build Pan successfully with clang on FreeBSD. Please try to build the current version of Pan from git repo on OS X.
The specific error reported does seem to be fixed but now the libc++ build fails as follows: Building with git master commit 3dffc90a2b13267461f6aa6069cbee1113f91e90 Mac OS X 10.10.5 (Yosemite) Xcode 7.2 Build version 7C68 Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin14.5.0 Thread model: posix -stdlib=libc++ /usr/bin/clang++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -D_REENTRANT -I/opt/local/include/gmime-2.6 -I/opt/local/include -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -D_REENTRANT -I/opt/local/include/gtk-2.0 -I/opt/local/lib/gtk-2.0/include -I/opt/local/include/pango-1.0 -I/opt/local/include/gio-unix-2.0/ -I/opt/local/include -I/opt/local/include/cairo -I/opt/local/include/atk-1.0 -I/opt/local/include/cairo -I/opt/local/include/pixman-1 -I/opt/local/include/libpng16 -I/opt/local/include -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/libpng16 -I/opt/local/include/pango-1.0 -I/opt/local/include/harfbuzz -I/opt/local/include -I/opt/local/include/pango-1.0 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/opt/local/include -pipe -Os -arch x86_64 -stdlib=libc++ -MT groups.o -MD -MP -MF .deps/groups.Tpo -c -o groups.o groups.cc In file included from groups.cc:46: In file included from ./data-impl.h:30: In file included from ../../pan/tasks/queue.h:28: In file included from ../../pan/tasks/decoder.h:32: In file included from ../../pan/tasks/task-article.h:28: In file included from ../../pan/data/article.h:26: In file included from ../../pan/general/quark.h:35: /Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ext/hash_set:205:5: warning: Use of the header <ext/hash_set> is deprecated. Migrate to <unordered_set> [-W#warnings] # warning Use of the header <ext/hash_set> is deprecated. Migrate to <unordered_set> ^ groups.cc:84:10: fatal error: 'ext/algorithm' file not found #include <ext/algorithm> ^ 1 warning and 1 error generated. make[3]: *** [groups.o] Error 1 make[3]: Leaving directory `/opt/local/var/macports/build/_Users_devans_macports_dports_news_pan2/pan2/work/pan2-3dffc90a2b13267461f6aa6069cbee1113f91e90/pan/data-impl'
I don't know where the header file "algorithm" is located on OS X. But you can change the line from: #include <ext/algorithm> to: #include <algorithm> in the file: groups.cc and try to build Pan again. Hope it helps.
As stated in the original report pan2 builds fine on Mac OS X versions 10.8 and earlier that use -stdlib=libstdc++ but Mac OS X version 10.9+ use -stdlib=libc++ by default. #include <ext/algorithm> is appropriate for -stdlib=libstdc++ but as you say #include <algorithm> is appropriate for -stdlib=libc++ Since we are trying to support platforms from OS X 10.6 through 10.14 (El Capitan), a better solution would be for you to ascertain which library the build is using and include the appropriate headers accordingly. This would probably be appreciated by Linux platforms that are trying to use the newer libraries as well. Although we are building on Mac OS X, this is not really a Mac specific issue but a C++ standards issue.
Typo: El Capitan is OS X 10.11.
Thanks for following up on this. I'm wondering if we could use something like this here: #ifdef _LIBCPP_VERSION // libc++ specific code here #else // generic code here #endif This is from http://stackoverflow.com/questions/31657499/how-to-detect-stdlib-libc-in-the-preprocessor. See also http://stackoverflow.com/questions/22531247/detect-whether-clang-is-compiling-using-c11-or-legacy-libstdc-standard-libra and http://lists.apple.com/archives/xcode-users/2012/Oct/msg00039.html.
Attached is my patch against git master 44c6404b1b1bbddb06691882fd3d3e131ba58811, based on your suggestion, that fixes this last problem. This patch allows pan2 to build successfuly for me using either -stdlib=libstdc++ or -stdlib=libc++. Tested on Mac OS X 10.10.5 (Yellowstone) using its default -stdlib=libc++ and on Mac OS X 10.8.5 (Mountain Lion) using its default -stdlib=libstdc++. The build was tested against both GTK+ 2.24.30 and GTK+ 3.18.9 on each platform using the appropriate configuration options.
Created attachment 324058 [details] [review] Proposed patch to allow build with either libc++ or libstdc++.
Created attachment 324118 [details] [review] Add #include <ciso646> David, Detlef, could you please git-apply this patch and test it? It's based on David's patch but also includes <ciso646>. That's probably unneeded here but it shouldn't hurt and it's recommended per the stackoverflow discussions. Thanks!
I've tested the patch without the "#include <ciso646>" statement on: - Linux with gcc5 - FreeBSD witch clang Ver. 3.4.1 I could successfully build Pan on Linux and FreeBSD. I think the patch is ok.
Works for me either way but I think the Petr's patch including <ciso646> is more "by the book." Tested this morning on the following platforms: Mac OS X 10.10 & 10.11 clang: Apple LLVM version 7.0.2 (clang-700.1.81) with libc++ Mac OS X 10.9 clang: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) with libc++ Mac OS X 10.8 clang: Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) with libstdc++
I've just committed the fix as 44ffc85e90af75046ca6dc94268b4b9045b5c6d5. Everybody, thank you for your help. This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.