I am trying to setup OpenCV v2.4.1 with FFMPEG v0.11 support on Scientific Linux SL release 5.0 (Boron), and I am running into a problem with a missing file that seems completely undocumented. The error I am getting is as follows:
-- Install configuration: "Release"
-- Up-to-date: /home/s18/s1138832/OpenCV/include/opencv/cv.h
-- Up-to-date: /home/s18/s1138832/OpenCV/include/opencv/cxmisc.h
-- Up-to-date: /home/s18/s1138832/OpenCV/include/opencv/cvwimage.h
-- Up-to-date: /home/s18/s1138832/OpenCV/include/opencv2/opencv.hpp
CMake Error at modules/core/cmake_install.cmake:63 (FILE):
file INSTALL cannot find file
"/home/s18/s1138832/OpenCV/lib/libopencv_core.so.2.4.1" to install.
Call Stack (most recent call first):
modules/cmake_install.cmake:57 (INCLUDE)
cmake_install.cmake:56 (INCLUDE)
I honestly don't know where to begin troubleshooting this at this point. I successfully installed without ffmpeg a few days ago, but now I can't even install with ffmpeg support set to off.
The files that link to the missing library are:
lrwxrwxrwx 1 s1138832 s18 21 Jun 17 18:26 libopencv_core.so -> libopencv_core.so.2.4
lrwxrwxrwx 1 s1138832 s18 23 Jun 17 18:26 libopencv_core.so.2.4 -> libopencv_core.so.2.4.1
Any advice or prods in the right direction would be much appreciated. I would also be happy to provide more info on whatever interesting details I may have omitted.
UPDATES: This website seems to have the same error, but I can't read it and translations patchy - http://www.opencv.org.cn/forum/viewtopic.php?f=1&t=15664 ( http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.opencv.org.cn%2Fforum%2Fviewtopic.php%3Ff%3D1%26t%3D15664&act=url )
libopencv_core.so.2.4.1 exists after "make", but "make install" deletes it somehow. I copied it and added it again, but it didn't change anything
As always, it was something very simple! I had my CMAKE_INSTALL_PREFIX set to "/foo" and I was configuring and building from "/foo" - when I configured from "/foo/temp" everything went swimmingly.
I guess the make install step tries to copy your built files to the install prefix path, and deletes the originals. Obviously this could cause some problems. Works like a charm now.
Thanks to everyone who made suggestions!
Related
It's been a long time since I last built opencv, contrib and all. The last installation I did, I recall being able to shrink the size of the installation after it was done; presently the file "build" is 28 gigabytes. My previous installation was able to be reduced in size to about 12 gigabytes after installation by removing files that are only necessary for installing and building, but not running. I have since forgotten what these files are that can be removed, and the installation tutorial that told me which ones were able to be removed. Can some shed some light on which files in my build folder can be removed after my release and debug builds have been installed?
If your intention is to extract the "bin/ include/ lib/ share/" QUAD and remove the entire cmake build tree, there is a simple thing you can do:
cd /path/to/cv/build
DESTDIR=/tmp/lalala make install -j7
Then you'll find what the QUAD in /tmp/lalala/path/to/your/original/install/dir. If that's all you need, rm -rf /path/to/cv/build.
If you are not using Linux/Unix & make however, let me know in the comment and I'll edit the answer.
Love your spiderman movies, btw. :-)
Good day,
I recently could install Lua 5.3 to /opt/lua53 on Centos 7
I also added the following line into /etc/bashrc
PATH=/opt/lua35/bin:$PATH
LD_LIBRARY_PATH=/opt/lua53/lib:$LD_LIBRARY_PATH
export PATH LD_LIBRARY_PATH
export LUA_INCLUDE_DIR=/opt/lua53/include
My colleague also install a software and when I compile by doing
make
I got the following errors
[root#pc6 jixie]# make
-- Release Build
-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is at least version "5.2")
-- Could NOT find ZEROMQPP (missing: ZEROMQPP_LIBRARIES ZEROMQPP_INCLUDE_DIRS)
-- Could NOT find OPENVDB (missing: OPENVDB_LIBRARIES OPENVDB_INCLUDE_DIRS)
-- Downloading/updating kdtree
-- Configuring done
-- Generating done
I look into serveral thread but none of then could help me.
As I wrote, I added the following line
export LUA_INCLUDE_DIR=/opt/lua53/include
hoping it can provide the path to LUA_INCLUDE_DIR, but unfortunately I still get the same error.
Any idea how I can solve my problem? DO you need more information of my system?
NB: I am using cmake 3.10
PATH=/opt/lua35/bin:$PATH looks wrong: It should be /opt/lua53/bin.
You are re-inventing the wheel and making it square this time round...
If you have installed Lua development (package or from source) then there should be a package-config file named lua.pc placed at a location where cmake or configure can find it and enquire it as to what should the libs and cflags of any application requiring Lua include/libs. For my system, these files are usually located at /usr/lib64/pkgconfig/ and indeed lua.pc lives there with this content:
V= 5.3
R= 5.3.4
prefix= /usr
exec_prefix=${prefix}
libdir= /usr/lib64
includedir=${prefix}/include
Name: Lua
Description: An Extensible Extension Language
Version: ${R}
Requires:
Libs: -llua -lm -ldl
Cflags: -I${includedir}
The above file tells configure where the include dir is, and what's more important, what flags to use during compilation (-I... -L... -l...).
If you are on a system with a package manager (say yum, dnf, apt-get, etc.) then placing these pc files to their location is taken care of automatically if they exist in the package that is.
If you insist to do it the way you have done it above by hand-coding LUA_INCLUDE_DIR to your shell's environment, then make sure that LUA_INCLUDE_DIR points to an existing and valid location with valid content. Are you sure the include files required can be found in that dir? Maybe there is an extra dir in there?
I'm having some trouble trying to compile opencv 3 in ubuntu 16.
I've followed the opencv tutorial and have gone over questions about the issue but can't make it work.
My problem is that compilation process doesn't find header files.
When I execute make -j4, the process finishes with the error.
/opencv/build/modules/freetype/precomp.hpp:61:22: fatal error: ft2build.h: file or directory doesn't exists
compilation terminated.
This file is located in following directories:
/xxx/tools/anaconda3/pkgs/freetype-2.5.5-1/include/freetype2/ft2build.h
/xxx/anaconda3/include/freetype2/ft2build.h
/home/xxx/anaconda3/envs/computervision/include/freetype2/ft2build.h
/usr/include/freetype2/ft2build.h
I tried to set the /user/include/freetype2 as header folder for make command with -I parameter but it didn't work:
make -j4 -I/usr/include/harfbuzz
Can anyone give me a hint about how to set the header folders?
Thank you.
I finally solve it simply adding this parameter to cmake:
-D ENABLE_PRECOMPILED_HEADERS=OFF
In attempting to install the latest ImageMagick (and devel) RPM from http://www.imagemagick.org/download/linux/CentOS/x86_64/ I receive this message
ImageMagick-libs = 6.8.5-8 is needed by ImageMagick-devel-6.8.5-8.x86_64
Confusingly, there is no ImageMagick-libs RPM listed, and searching has yet to yield a solution. Is there a way around this existential dependency?
Neither I nor Google know where ImageMagick-libs lives nor what it contains, but for posterity this gets things up and running on CentOS 5.8 (the distribution listed on imagemagick.org):
>: rpm -Uvh --nodeps ImageMagick-6.8.5-8.x86_64.rpm ImageMagick-devel-6.8.5-8.x86_64.rpm
>: ln -s /usr/include/ImageMagick-6 /usr/include/ImageMagick
The symbolic link was necessary for software relying on ImageMagick header files.
If someone were to stumble upon this, the ImageMagick-libs RPM are now downloadable from the link in the question.
I ran into the same thing when building the RPMs myself.
line 66 of the SRPM's included ImageMagick spec file includes:
Requires: %{name}-libs = %{version}-%{release}
I just commented out that line and the build completes; the resultant RPM satisfies the requirement cleaner. In sum, I believe it a bug in the SPEC file bundled in the SRPM. It isn't necessary for functionality even when building against php magickwand and similar finicky tools that require headers from ImageMagick.
I have spent days trying to submit my app on the RIM Vendor Portal.
I can build it. I can run it on my device using debugtoken.bar.
When I try to submit it to the Vendor Portal I get the dreaded "Some files are missing signatures" error.
I built my application.bar file (actually named QuoteUnquote.bar), then signed it with:
"C:\Program Files (x86)\Research In Motion\BlackBerry WebWorks SDK for TabletOS 2.1.0.6\bbwp\blackberry-tablet-sdk\bin\blackberry-signer" -verbose -cskpass ******** -keystore sigtool.p12 -storepass ******** "C:\work\word\quotes\platform_airplay\build_smartquotes-airplay_vc10\deployments\default\playbook\release\QuoteUnquote.bar" RDK
"C:\Program Files (x86)\Research In Motion\BlackBerry WebWorks SDK for TabletOS 2.1.0.6\bbwp\blackberry-tablet-sdk\bin\blackberry-signer" -keystore sigtool.p12 -storepass ******** "C:\work\word\quotes\platform_airplay\build_smartquotes-airplay_vc10\deployments\default\playbook\release\QuoteUnquote.bar" author
I confirm that there are the required five files inside the META-INF folder in the signed .bar file.
When I verify it without the -verbose option, it just says ".bar verified". When I verify it with the -verbose option, the verify tool appears to crash:
C:\work\word\quotes\platform_airplay\PlayBook>"C:\Program Files (x86)\Research In Motion\BlackBerry WebWorks SDK for TabletOS 2.1.0.6\bbwp\blackberry-tablet-sdk\bin\blackberry-signer" -verify -keystore sigtool.p12 -verbose "C:\work\word\quotes\platform_airplay\build_smartquotes-airplay_vc10\deployments\default\playbook\release\QuoteUnquote.bar"
2240 Sat Jun 30 00:31:16 PDT 2012 META-INF/MANIFEST.MF
1287 Sat Jun 30 00:31:16 PDT 2012 META-INF/AUTHOR.SF
710 Sat Jun 30 00:31:16 PDT 2012 META-INF/AUTHOR.EC
1287 Sat Jun 30 00:31:02 PDT 2012 META-INF/RDK.SF
280 Sat Jun 30 00:31:02 PDT 2012 META-INF/RDK.EC
0 Tue Jan 01 00:00:00 PST 1980 META-INF/
0 Tue Jan 01 00:00:00 PST 1980 native/
barsigner error: java.lang.NullPointerException
So that's not very helpful. I don't know if the -verify tool is just flaky, or if some problem with the .bar file is making it crash, or what.
This is all very frustrating because I've successfully signed and submitted .bar files in the past. I don't know what I'm doing differently now.
As I say, I've been stuck on this for days. If you can give me pointers, that would be great. If I can send you my .bar file and you can tell me what's wrong with it, that would be better.
Any help greatly appreciated.
My little hack to get around this was to sign the .bar as usual (RDK and Author) then rename the .bar file to .zip and extract all files into an temporary directory.
Using 7Zip I then RE-ZIP all files using this command:
7z a -tzip <AppName>.bar *.* -r
Which will re-zip all files back and remove the entries for directory names.
Run a verify on it:
blackberry-signer -verbose -verify <AppName>.bar
So long as you properly signed the app, you should see the lovely message:
Info: Bar verified.
Submit it and off you go!
I have figure out what was going on here. The problem is that there are two kinds of .zip files in the world, those where the directories get their own entry in the .zip file's directory, and those where they don't. This is a difficult issue because (as I understand it) most tools for viewing .zip files don't give an indication of whether the directories have their own entries -- they just show the directories using GUI folder icons like in Windows Explorer or whatever.
The solution was given here: http://supportforums.blackberry.com/t5/Native-Development/Error-while-uploading-Invalid-signature-file-digest-for-Manifest/td-p/1623873
It gives a java program to rebuild the .zip from the extracted contents, and using that particular java library to rebuild the .zip does not include the folders as their own entries.
This problem arose for two reasons:
(1) The RIM Vendor Portal submission tool checks to see if each item in the file is properly signed, and it apparently sees those two directory entries in the contents directory and freaks out because they are not signed, hence "Some files (sic) are missing signatures." In fact, it seems like it could just notice that those are zero-length directory entries and that there's nothing to sign anyway, and just let it go. That would avoid the whole mess in the first place.
(2) The Marmalade tool that makes the .bar file creates a zip that includes those directory entries. What's tricky is that, best as I can tell, it doesn't create those entries on everyone's system, just on some. There are other Marmalade users who apparently don't get this problem. I don't know if it has to do with the underlying .zip library that the Marmalade tool is using, whether that's part of the .jdk, part of the python system Marmalade uses, or what. But it definitely seems to behave differently on different systems.
So, both RIM and Marmalade should include information about this. When RIM gives the error that "some items are missing signatures" it should specify that it's these zero-length directory entries that are missing signatures (or it could just not treat it as an error at all, as mentioned above). Marmalade should tell all users who are working on PlayBook submissions about this issue.
Ok don't use this method.... it verifies and allows you to submit BUT on RIM's side they will complain about the fact that you modified the .bar file AFTER it was signed! !