When I use std::map's merge(source) I got an error:
error: no member named 'merge'
However, the std::map::merge should be there since c++17.
I do add set(CMAKE_CXX_STANDARD 17) and -stdlib=libc++. The std::map::extract is already there. Is this a bug in clang-7?
If I get rid of -stdlib=libc++, the gcc header does contain std::map::merge. Then I can compile. But I do need -stdlib=libc++ for my project. Any idea?
I dig around and find out that the merge neither exists in llvm/include/c++/v1/map nor in llvm/include/c++/v1/experimental/map. So which header should I include for that? Or the c++17 support in clang-7 is still problematic?
It's in LLVM 8 but not 7. It's item p0083r3 in the C++17 status table, and here's the commit:
https://github.com/llvm/llvm-project/commit/5c4e07ae5c6f7f467b436f1b24f41ef4cf9897b3
From the tag list it doesn't look like it's been back-ported to 7.
Related
I am building Yocto 2.5(Sumo) with Gstreamer 1.14 and OpenCV 3.4.5
I am getting this error while compiling Gstreamer:
build_xwayland_mq/tmp/work/aarch64-mx8m-poky-linux/gstreamer1.0-plugins-bad/1.14.4.imx-r0/recipe-sysroot/usr/include/opencv2/imgproc/types_c.h:445:21: error: conflicting declaration of C function 'CvMoments cvMoments(const cv::Moments&)'
CV_INLINE CvMoments cvMoments(const cv::Moments& m)
same error in imgproc_c.h:360:13
I saw someone solved this by building with OpenCV 4 instead, but we need OpenCV 3.4.5 for our own project.
Anyone know how to resolve this conflict?
too long for comment..
I did just quick search, found this:
https://www.yoctoproject.org/pipermail/meta-freescale/2019-March/023888.html
There is some problem in includes .. I guess in mentioned hpp files there are some types that are not declared in that imgproc_c.h for 3.4, but already are moved there for opencv 4 (just my guess).
You just need to add those hpp on all places (in gst plugins bad) where you find include for imgproc_c.h.
Take inspiration from this.. or maybe it itself will solve your issue:
https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-opencv-fix-build-for-opencv-3-4-2.patch?h=thud
The patch is for yocto thud.. but perhaps it does not matter for GStreamer.
In worst case you will have to backport it or make your own patch for sumo.
Or if you can try update to thud (should be small difference) or newer and check if it persists.
I couldn't find sample code for a clang-tidy command line for fixing the following error:
[archlinux#thinkpad fizzbuzz]$ clang-tidy fizzbuzz2.cpp -checks=cppcoreguidelines-pro-bounds-constant-array-index
5 warnings generated.
fizzbuzz2.cpp:21:18: warning: do not use array subscript when the index is not an integer constant expression; use gsl::at() instead [cppcoreguidelines-pro-bounds-constant-array-index]
std::cout << arr[index] << std::endl;
^
Suppressed 4 warnings (4 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
[archlinux#thinkpad fizzbuzz]$
I just want to find out how I can get clang-tidy to fix this automatically. If not, how should I use gsl::at() to fix this? The clang-tidy documentation says the following:
cppcoreguidelines-pro-bounds-constant-array-index
This check flags all array subscript expressions on static arrays and std::arrays that either do not have a constant integer expression index or are out of bounds (for std::array). For out-of-bounds checking of static arrays, see the -Warray-bounds Clang diagnostic.
This rule is part of the “Bounds safety” profile of the C++ Core Guidelines, see https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Pro-bounds-arrayindex.
Options
GslHeader
The check can generate fixes after this option has been set to the name of the include file that contains gsl::at(), e.g. “gsl/gsl.h”.
IncludeStyle
A string specifying which include-style is used, llvm or google. Default is llvm.
I found the gsl::at() subroutine in <gsl/gsl_util>. How do I tell clang-tidy to use it to fix my warning?
Edit: I looked at the config string and found the solution to this:
On running:
clang-tidy fizzbuzz2.cpp -checks=cppcoreguidelines-pro-bounds-constant-array-index -dump-config
I got some hints towards the solution
clang-tidy fizzbuzz2.cpp -checks=cppcoreguidelines-pro-bounds-constant-array-index -config="{CheckOptions: [{key: cppcoreguidelines-pro-bounds-constant-array-index.GslHeader, value: gsl/gsl_util}]}" -fix
Edit: I looked at the config string and found the solution to this:
On running:
clang-tidy fizzbuzz2.cpp -checks=cppcoreguidelines-pro-bounds-constant-array-index -dump-config
I got some hints towards the solution
clang-tidy fizzbuzz2.cpp -checks=cppcoreguidelines-pro-bounds-constant-array-index -config="{CheckOptions: [{key: cppcoreguidelines-pro-bounds-constant-array-index.GslHeader, value: gsl/gsl_util}]}" -fix
I know... Another one of this... But no one else's error is the same as mine and I've been trying to build opencv with mingw32 for days now.
When building OpenCV with mingw the command mingw32-make fails at some point trying to compile sources\modules\ts\src\ts_gtest.cpp with error pic bellow:
I've tried following several tutorials, but none work cleanly and this is the best I could get stuff to work.
What I did:
Installed Mingw and added C:\Mingw\bin\ to PATH environment variable.
Installed CMake and added it too to PATH.
Extracted OpenCV to C:\ and created forlder C:\opencv\mingwBuild\
In CMake-GUI I define source folder as C:\opencv\sources\ and build folder as C:\opencv\mingwBuild\.
Hit Configure and select Mingw Makefiles, with 'Use default native compilers' (have also specified compilers explicitly and the result is the same.).
Hit Generate, which creates the Makefile.
I open C:\Mingw\msys\1.0\msys.bat to have a console with all variables loaded (have also tried directly from a simple cmd.exe, given that PATH is set for mingw, but I get the same error in compilation). Navigate to C:\opencv\mingwBuild\ and run mingw32-make.
And that's where the error shows up after a while. Any ideas?
Turns ou gTest was not compiling in Mingw for some reason.
As I don't intend to test my code (for now) I removed opencv_ts from instalation (by deselecting it in Cmake, after configuring and before generating).
Someone mentions, in the first link #Dan Masek refers, that GTest has this issue with type conversion under mingw. They say that you can edit ts_gtest.cpp to apply the correct conversion, according to error message. That may be a solution if you need this module.
Another comment in #Dan Masek's second link mentions that gcc's version 5 surpasses the issue, which version 4 has. So, getting a hold of such distro may also be a solution.
For me it seems to be fixed by applying this fix: https://github.com/msk-repo01/opencv/commit/9a1835ce6676836ce278d723da4ff55a8f900ff1
(Also see: https://github.com/opencv/opencv/issues/8105)
The fix basically replaces the "_RTL_CRITICAL_SECTION" by "_CRITICAL_SECTION" for MingW compilers in modules/ts/include/opencv2/ts/ts_gtest.h in the following way:
The lines
// assuming CRITICAL_SECTION is a typedef of _RTL_CRITICAL_SECTION.
// This assumption is verified by
// WindowsTypesTest.CRITICAL_SECTIONIs_RTL_CRITICAL_SECTION.
struct _RTL_CRITICAL_SECTION;
(around line 723 in OpenCV 3.2.0 release from Dec. 2016) are replaced by
# if GTEST_OS_WINDOWS_MINGW
// MinGW defined _CRITICAL_SECTION and _RTL_CRITICAL_SECTION as two
// separate (equivalent) structs, instead of using typedef
typedef struct _CRITICAL_SECTION GTEST_CRITICAL_SECTION;
# else
// assuming CRITICAL_SECTION is a typedef of _RTL_CRITICAL_SECTION.
// This assumption is verified by
// WindowsTypesTest.CRITICAL_SECTIONIs_RTL_CRITICAL_SECTION.
typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION;
# endif
and
_RTL_CRITICAL_SECTION* critical_section_;
is replaced by
GTEST_CRITICAL_SECTION* critical_section_;
the goal is to debug a method deep within a library.
We can debug c functions in that same library (as long as they are not in the .m files), but apparently no Objective-C code, or even c code within any .m file.
When I try to set breakpoints manually, (break set -n), I get:
WARNING: Unable to resolve breakpoint to any actual locations.
The code does get called, the trusty logger confirms that.
My hunch is that debugging information gets lost somewhere along the way: We are building a static library, then another static library ("Framework" style), and finally we are linking this into our app. Yes, that's complicated but, historical reasons, you know.
I have tried to examine the first .a file to see what is going on, but when I try to load it into lldb I have to create a target. And target creation fails for either architecture:
target create -d --arch i386 libFoo.a
error: 'libFoo.a' doesn't contain the architecture i386
target create -d --arch armv7 libFoo.a
error: 'libFoo.a' doesn't contain any 'remote-ios' platform architectures: arm64, armv7, armv7f, armv7k, armv7s, armv7m, armv7em, armv6m, armv6, armv5, armv4, arm, thumbv7, thumbv7k, thumbv7s, thumbv7f, thumbv7m, thumbv7em, thumbv6m, thumbv6, thumbv5, thumbv4t, thumb
lipo -info libFoo.a
Architectures in the fat file: libFoo.a are: armv7 i386
Does anyone have a good idea how to best tackle this issue? The code is definitely linked, working, but lldb can not set breakpoints.
Thanks a lot
Addendum:
I have created the most simple setup I could think of, and I see very, very odd results:
If I try to lookup certain things, some will return a file and a line number, others will not:
image lookup -s Foo::faz()
1 symbols match 'Foo::faz()' in […]/Build/Products/Debug-iphoneos/Test.app/Test:
Address: Test[0x00010334] (Test.__TEXT.__text + 22060)
Summary: Test'Foo::faz() at Foo.cpp:858
image lookup -s FazBar
1 symbols match 'FazBar' in […]/Build/Products/Debug-iphoneos/Test.app/Test:
Address: Test[0x00038eb4] (Test.__TEXT.__text + 188844)
Summary: Test'FazBar
Trying to set breakpoints in the corresponding files yields, well, expected results:
(lldb) break set -f Foo.cpp -l 877
Breakpoint 5: where = Test'Foo::faz() + 76 at Foo.cpp:877, address = 0x000cb380
(lldb) break set -f bar.c -l 585
Breakpoint 6: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
How can I dig into the .a file to see why certain files are not found?
Well, someone (actually not me, had the absolutely bright idea of setting
GCC_GENERATE_DEBUGGING_SYMBOLS = NO
somewhere hidden deep.
Setting it to yes, well, you guessed it, solves the issue
Alex
set exception break point like above
go to brekpoint navigation click on + and slecte add exception brak point
Try using DYLD_BIND_AT_LOAD environment variable set. This should disable lazy binding, which often fails to hit symbolic breaküpints
I tried building the first example here and got errors. Right on the first line there's a missing include statement, but I managed to figure out it should be
#include "hdf5.h"
But even after fixing that I got more errors:
$ h5cc ./example1.c
./example1.c: In function ‘main’:
./example1.c:66:4: error: too few arguments to function ‘H5Dcreate2’
In file included from /usr/include/hdf5.h:27:0,
from ./example1.c:6:
/usr/include/H5Dpublic.h:104:14: note: declared here
Any idea how to solve it?
The example code was written for release 1.6 of hdf5, and as such will simply not compile on a 1.8 release without modification.
If you want to get the code to work on 1.8, you need to enable 1.6 compatibility, which means passing in the flag:
-DH5_USE_16_API
to the h5cc command line like:
h5cc -DH5_USE_16_API ./example1.c
and it should compile correctly; otherwise you will have to rewrite the code to make use of the 1.8 API.