I am sure there is a simple command for this.
I had installed opencv 2.4.3 manually in /usr/local.
Then I removed it and installed OpenCV 2.4.5 from the arch community(I am using Arch linux) which gets installed in /usr
Now when I try to use OpenCV in a cmake project, cmake returns the old paths from /usr/local.
I did some digging around and found that if remove "CACHE" from the line:
get_filename_component(OpenCV_CONFIG_PATH ="${CMAKE_CURRENT_LIST_FILE}" PATCH CACHE)
in /usr/share/opencv/OpenCVConfig.cmake I get the correct path.
This points to my question. How do I clear the cmake cache?I am talking about cmake's internal cache not the application's cache which can be deleted by removing CMakeCache.txt. Is there a command? Or where is the cmake cache directory/file located? I am sure there's a simple answer for this.
I know how to set/unset a CACHE variable, but don't know how to clear the complete cache.
The problem was with pkg-config settings. I hadn't removed the old .pc file and adjusted the PKG_CONFIG_PATH. pkg-config was using the opencv.pc file present in /usr/local/lib/pkgconfig rather than the one present in /usr/lib/pkgconfig. There isn't any cache that cmake uses internally, i think.
Recompiling the dependency library solved my problem.
I have a project that depends on Opencv. When I still using Xcode 7.2beta, the path of SDK of MacOSX is "/Applications/xcode7.2beta.app/Content/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk". So, the cmake generated and compiled opencv libraries with MacOSX10.11.sdk under "/Applications/xcode7.2beta.app/".
A few days ago, I upgraded my xcode to 8.0, the new path of xcode and its SDK is "/Applications/xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk". But anyway, when cmake generates my project, the reference to opencv always points to the old xcode.
Later I realized that opencv was generated using the old Xcode, so I re-compiled the opencv with the new Xcode, and my project was compiled correctly.
Related
I'm working on a C++ project that requires libpng. So far I've worked on Linux and everything is smooth. I installed libpng, CMAKE picks it up and everything is alright. Now move to Windows.
Here I first installed zlib (required by libpng) and libpng. When I say install, I mean I downloaded the source files, and then built them and install them using msbuild.
I noticed that by doing so, I got new folders under c:\program files (x86):
c:\program files (x86)\zlib
c:\program files (x86)\libpng
Seemed all right to me. Now when I configure my project with CMAKE zlib is picked up:
-- Found ZLIB: C:/Program Files (x86)/zlib/lib/zlib.lib (found version "1.2.13")
but there's no way CMAKE finds the PNG library:
Could NOT find PNG (missing: PNG_LIBRARY PNG_PNG_INCLUDE_DIR)
Now I tried to have a look at the FindPNG and I noticed this line:
find_path(PNG_PNG_INCLUDE_DIR png.h PATH_SUFFIXES include/libpng)
Does this mean that CMAKE expects the file png.h to be in a directory ending in include/libpng? If so, then it will never find it because in my case png.h is placed in libpng/include. But this is also the "official" installation from the source code just downloaded from http://www.libpng.org/pub/png/libpng.html.
So now I am superconfused. How things are supposed to work in Windows? Should I "create" a folder structure with the correct files for every library so that CMAKE is happy? In a way I hoped things in Windows were similar to what happens in Linux: libraries go in a standard folder, they are detected by CMAKE.. everything is ok. But apparently this is not the case. So my question in general is: how do you ship a package like this to a Windows user so that he can builds it without having to go through all this?
Thanks so much
Fabrizio
This would be the right one to use:
find_package(PNG)
You can tell CMake to look in the location where you installed it by adding the libpng base install location to CMAKE_PREFIX_PATH. Without this, CMake doesn't know where you put it.
cmake "-DCMAKE_PREFIX_PATH=C:/Program Files (x86)/libpng" ...
Note that FindPNG first looks for zlib and will fail if zlib could not be found.
I'm attempting to use Cocotron to build the Foundation framework. GCC 4.3.1 for Windows compiled fine, and it's creating valid Windows executable files, which I confirmed by making a "Hello, world" executable.
So what I don't understand is why, with Xcode 5.0.2, when I use either xcodebuild or build the Foundation project within Xcode itself, it isn't creating dll files.
So, it seems that as of Xcode 5, Apple no longer supports any compilers that are not derived from clang. To fix this issue, I had to copy the pbcomspec files from /Library/Application Support/Shared/Xcode/Specifications to ~/Library/Application Support/Shared/Xcode/Specifications and edit the file that declares that the compiler is based on llvm-gcc to declare that it's based on com.apple.compilers.llvm.clang.1_0. Then it should at least try to build.
I try to use hpc gcc instead clang and get same results. I found that cocotron needs additional libraries zlib, libjpeg and libpng and in xcode 4.x build failed without they, but in xcode 5.x its only warnings and build marks as success. I didn't try fix it because we began use virtual machine with xcode 3.2, but maybe it is cause that libraries are not created
BTW I use this post and this plugin
I'm on mac 10.7.5, using xcode 4.6.2 and working with the OpenCV 2.4.3 library. I went through the process of making the build directory with the cmake files in terminal and did the download.
I added the .dylib files in Xcode and changed the header path, changed C++ Library to libstdc++, but when I compiled I got this error :
ld: library not found for -lopencv_calib3d.2.4.3
clang: error: linker command failed with exit code 1
I have libopencv_calib3d.2.4.3.dylib added in the project so I have no idea what else it needs.Any ideas?
If your "make back-end" is Cmake you should stick to using it. Local config changes in Xcode can "secretly" be overwritten when the cmake is rerun (which for example happens after you make changes to it) creating weird build errors and forcing you to remember all the manual changes you made.
Your problem seems to be that the generated project doesn't seem to know where to look for opencv.
Assuming you installed opencv using macports you should add a line saying
link_directories(/opt/local/lib)
to your CMakeLists.txt. (if you installed it using brew, or compiled it manually just replace /opt/local/lib for /usr/local/lib or the path to your compiled libraries)
Also make sure to link against opencv_calib3d instead of opencv_calib3d.2.4.3 (unless you have a very particular reason for bypassing this, but that usually means that something else is weird in the setup :) )
Final pointer that you might already know of: As you are already using Cmake you should add the libraries to link against using TARGET_LINK_LIBRARIES(...) in Cmake rather than manually adding them in Xcode (referring to my previous argument).
I'm trying to install QtROOT, and as part of the installation (specifically, the readme file in the QtROOT tarball at http://root.bnl.gov/QtRoot/downloads/qtFullRoot.tar.gz), it mentions to make sure that QTDIR is set. I've installed from the Qt 4.6.3 SDK installation for Mac OS X, and I have no such environment variable set. I've tried googling to figure out where it should be set to, but the options I've found (such as /usr/local/qt) don't exist. What should this variable be set to?
OS X 10.6.4, Qt 4.6.3, ROOT 5.26/00, QtROOT... I have no idea. :P
Thanks,
Paul
Qt's packaged installer for OSX scatters things throughout the /Developer and /Library directories rather than installing to a self-contained location in /usr/local or /opt/local as you might expect it to do on other unix-based systems.
Incidentally, Qt follows Apple's way of doing things in this respect, so it's really not wrong -- it's just different -- but it does make some 3rd party Qt applications somewhat difficult to build on OSX.
The packaged Qt installer itself has the following to say on this topic:
After a successful install, you can find most new things in /Developer. Specifically things will be located in the following places:
Qt Designer, Qt Linguist: /Developer/Applications/Qt
Qt Documentation: /Developer/Documentation/Qt
Qt Examples: /Developer/Examples/Qt
Qt Plugins: /Developer/Applications/Qt/Plugins
Qt Frameworks: /Library/Frameworks
Qt Libraries: /usr/lib
qmake, moc, uic, etc.: /Developer/Tools/Qt (symlink to /usr/bin)
Uninstall script: /Developer/Tools/uninstall-qt.py
So, it does put the libs into '/usr/lib', and it symlinks the essential Qt tools (like qmake) into '/usr/bin'. This suggests that QTDIR could be set to '/usr'. In practice however, this doesn't work because the qt headers remain buried in '/Library/Frameworks/Qt*/Headers/*.h', while builds that rely on $QTDIR will end up looking for the qt headers in "${QTDIR}/include/" instead.
The easiest way around all this is to build Qt from source. The install location will default to something like /usr/local/Trolltech/Qt-4.6.3 (note the version number, and adjust accordingly). You can override the default install location by using the -prefix option on ./configure.
A simpler approach is to let macports build it for you. This is the approach I ended up taking (and with good success). Just install macports, if you don't already have it. Then:
> sudo port selfupdate
> sudo port install qt4-mac
Macports will work its magic, and when it's done Qt will be installed, in its entirety, at /opt/local/libexec/qt4-mac.
Regardless of how you build Qt, expect a full build to take several hours. It's a very large code base.
I didn't install Qt from the installer (but compiled it myself), so I don't know the default location.
However, where you installed Qt, there is your QTDIR.
Search for qmake, it should reside in some bin/ folder. one up is QTDIR ($QTDIR/bin/qmake).
Usually it's not necessary anymore to set QTDIR these days to build a Qt project, just qmake must be in the PATH, everything else found then. But some projects might require it though (if they use a custom build system that still uses QTDIR).
I need to install LiteIDE on my mac and in the install guide, the QTDIR is necessary. I install the qt with the homebrew by brew install qt --build-from-source, it takes about 2 hours in RMBP. After the install finished, there is still no QTDIR path. By checking the build_osx.sh, i know it's just the parent folder of bin. so i set the path by export QTDIR=/usr/local/Cellar/qt/4.8.6. Then run the ./build_osx.sh again. it works.
Hope this will be helpful.
I need to step through the Qt code to help solve a bug in my C++ application. I've downloaded qt-mac-opensource-src-4.5.2.tar from here and followed the install instructions that came with this:
unpacked the file to /tmp.
typed ./configure -debug.
typed make.
typed sudo make install.
edited the PATH environment variable as instructed.
set the DYLD_IMAGE_SUFFIX environment variable to _debug.
This installed Qt and my Qt application runs, but I still can't step into the Qt code.
I'm using Xcode 3.1.3 and tried changing the Executable Info to "use debug suffix when loading frameworks". This generated a lot of warnings like:
warning: Could not find object file "/private/tmp/qt-mac-opensource-src-4.5.2/src/corelib/.obj/debug-shared/qmalloc.o" - no debug information available for "global/qmalloc.cpp".
warning: Could not find object file "/private/tmp/qt-mac-opensource-src-4.5.2/src/corelib/.obj/debug-shared/qnumeric.o" - no debug information available for "global/qnumeric.cpp".
and also a lot of non-qt related warnings.
I'd shutdown the Macbook Pro overnight, which I can only assume clears the tmp directory as the unpacked file is no longer there.
I think I could fix it by rebuilding Qt without frameworks, but this is more of a work-around than a fix that will probably come back to bite me. I'm also a bit reluctant to do this, when each rebuild takes between 3 and 4 hours.
Alternatively, would downloading the binaries and debug libs work?
I'd be grateful for any suggestions on what I'm missing and how I address this.
Thanks.
With the help of Qt support, I've now resolved this.
There were a couple of issues:
The Qt debug "make install" doesn't currently generate dSYM files for the _debug stuff. They've raised a bug about this. To get round this:
4a. cd /usr/local/Trolltech/Qt-4.5.2/lib
4b. Type /usr/bin/dsymutil -o QtGui.framework/QtGui_debug.dSYM QtGui.framework/Versions/4/QtGui_debug
4c. Repeat for each Qt framework.
The tmp directory does indeed get wiped on each reboot. To get round this:
7- Copy the entire contents of /tmp/qt-mac-opensource-src-4.5.2 to a new directory ~/Qt .
I also added both the frameworks and source code to the Xcode project.
Have a look at this http://doc.trolltech.com/4.5/debug.html
There is a section especially for debugging under MacOSX and Xcode...
I guess you need to generate a makefile with debug option using qmake !
In OS X 10.6 and 10.6.1, setting DYLD_IMAGE_SUFFIX to _debug will cause problems. Hopefully this will be addressed by a future update of OS X 10.6.