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.
Related
The following options seems relevant but the result is no .dll/.exe and no .cs:
/compile:0 /compileTarget:cs
There doesn't seem to be any other command line options to control this.
I found the answer:
/compile:0 /compileTarget:cs /spillTargetCode:2
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.
ERROR - function sql_insert__mark_/2 undefined. (LINE NO - 242,217)
- unknown type specifier 'H' (LINE NO - 150)
I am trying to compile this module separately but cannot because of this issue.I have included all the necessary hrl files. mod_mam and mod_mam_mnesia compiles perfectly but this one fails.
Ejabberd version - 18.01
If you want to compile that module because you applied some changes in it, it may be easier to simply download all ejabberd source code, compile all of it, then make your changes, and compile again.
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_;
I'm not sure why, but on my Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.4) css-mode is not loading and with M-x css-mode gives this error in Messages:
Symbol's function definition is void: apropos-macrop
or
File mode specification error: (void-function apropos-macrop)
my css file (ending in .css) is in Fundamental. I just tried it on a 23.1.1 and CSS mode comes up and works fine.
Update: Traced problem to my autoloads. i.e., comment out autoloads
;(load "~/modes/autoloads" 'install)
and the problem goes away. I'm not sure what to hack with an autoloads file. Any way to "step" through an autoloads? Here's my autoloads: http://gmcongo.org/temp/autoloads
In Emacs 24.4 and the bleeding edge versions leading to it (like 24.3.50+), apropos-macrop has been replaced by macrop. In css-mode.el, replace the call to apropos-macrop with a call to macrop and the error goes away.
Building upon the existing correct answer, you can create an alias in your ~/.emacs instead of editing css-mode (if for example, it came in a package with your distribution):
;; For css-mode, temporarily.
(defalias 'apropos-macrop 'macrop)