I'm using cmake and make to compile a project using an external library (speex).
This library is found by the find_library command in my CMakeLists.txt.
The only problem is: the default include path of cmake does not include /usr/local/include/, that is the location of speex's headers.
I do not want to add /usr/local/include/ to the search path in the CMakeLists.txt because it would (I suppose) generate an error on windows where such path doesn't exist.
Moreover, that would be a dirty trick, I'm not quite fond of this solution.
Do you know a solution to this problem which would be portable and clean ?
Thank you for your time.
Try using a full-blown speex find module, either created from scratch, or based on something found with http://www.google.com/search?q=findspeex.cmake
Punt the configuration to the user via the command line, e.g.
cmake -DSPEEX_PATH=/usr/local/include
Use the PATH argument of find_library to specify other places to search. If the path doesn't exist it shouldn't produce an error.
Related
I am using the z3prover first time, after reading most of related answers, I have noticed that I need to try: sudo make install .How could I skip the link z3 in /usr/bin and /usr/lib to use z3++.h in my own c++ project. (bcs I have noticed not everyone has the sudoer, I hope my code would goes well without sudoer.
You do need to compile the z3 source code if you want to be able to use it in your C/C++ projects. Compiling it will give you the library to link against. If you just download the source code, you can find the headers but you cannot link and hence cannot create your own executables.
But doing so does not require sudo access at all. The proper way to do so is actually explained in the https://github.com/Z3Prover/z3 page, right in the README. Roughly, they go like this:
python scripts/mk_make.py --prefix=/home/leo
cd build
make
make install
Note in the prefix parameter of the first line you tell z3 where to install everything. Change that path to a place where you have write-access. This way you do not need sudo access.
In order to compile your project successfully, you need to tell your compiler where to look for dynamic libraries and header files. Ask separately if you run into issues.
If you use GCC as the compiler you should add -I option for your project as follows :
g++ -Iz3_path/include -Lz3_path/lib -lz3
I am trying to load Lua script from HAProxy. In the Lua script, the following line is causing an error:
local http = require("socket.http")
Intially I gathered from journalctl -xe output that the library was not installed. I installed it using luarocks install luasocket. This did not solve the issue. The new error is module "socket.http" not found. Following the comment in this post I realized that I must change the settings for Lua library path in order to resolve this issue.
Now, I want to know the following:
Do I have install HAProxy+Lua from source and modify the library path pre installation?
If building from source is not necessary then, I believe I must change the path using syslog as suggested by the comment from post linked above. If this is the case, how do I do that and what settings do I need to change/add to syslog.conf?
Are there are any other solution that I am overlooking which, would easier than any of the above?
Thanks for your help in advance.
EDIT 1
I have modified both LUA_PATH and LUA_CPATH as follows:
LUA_PATH=/usr/bin/lua;/usr/bin/lua5.3;/usr/share/lua/5.3/ltn12.lua;/usr/share/lua/5.3/mime.lua;/usr/share/lua/5.3/socket.lua;/usr/share/lua/5.3/ssl.lua;/usr/share/lua/5.3/posix/_argcheck.lua;/usr/share/lua/5.3/posix/compat.lua;/usr/share/lua/5.3/posix/deprecated.lua;/usr/share/lua/5.3/posix/init.lua;/usr/share/lua/5.3/posix/sys.lua;/usr/share/lua/5.3/posix/util.lua;/usr/share/lua/5.3/posix/version.lua;/usr/share/lua/5.3/socket/ftp.lua;/usr/share/lua/5.3/socket/headers.lua;/usr/share/lua/5.3/socket/http.lua;/usr/share/lua/5.3/socket/smtp.lua;/usr/share/lua/5.3/socket/tp.lua;/usr/share/lua/5.3/socket/url.lua;/usr/share/lua/5.3/term/colors.lua;/usr/share/lua/5.3/term/cursor.lua;/usr/share/lua/5.3/term/init.lua;/usr/share/lua/5.3/ssl/https.lua;/usr/share/lua/5.3/luarocks/add.lua;/usr/share/lua/5.3/luarocks/admin_remove.lua;/usr/share/lua/5.3/luarocks/build.lua;/usr/share/lua/5.3/luarocks/cache.lua;/usr/share/lua/5.3/luarocks/cfg.lua;/usr/share/lua/5.3/luarocks/command_line.lua;/usr/share/lua/5.3/luarocks/config_cmd.lua;/usr/share/lua/5.3/luarocks/deps.lua;/usr/share/lua/5.3/luarocks/dir.lua;/usr/share/lua/5.3/luarocks/doc.lua;/usr/share/lua/5.3/luarocks/download.lua;/usr/share/lua/5.3/luarocks/fetch.lua;/usr/share/lua/5.3/luarocks/fs.lua;/usr/share/lua/5.3/luarocks/help.lua;/usr/share/lua/5.3/luarocks/index.lua;/usr/share/lua/5.3/luarocks/install.lua;/usr/share/lua/5.3/luarocks/lint.lua;/usr/share/lua/5.3/luarocks/list.lua;/usr/share/lua/5.3/luarocks/loader.lua;/usr/share/lua/5.3/luarocks/make.lua;/usr/share/lua/5.3/luarocks/make_manifest.lua;/usr/share/lua/5.3/luarocks/manif_core.lua;/usr/share/lua/5.3/luarocks/manif.lua;/usr/share/lua/5.3/luarocks/new_version.lua;/usr/share/lua/5.3/luarocks/pack.lua;/usr/share/lua/5.3/luarocks/path_cmd.lua;/usr/share/lua/5.3/luarocks/path.lua;/usr/share/lua/5.3/luarocks/persist.lua;/usr/share/lua/5.3/luarocks/purge.lua;/usr/share/lua/5.3/luarocks/refresh_cache.lua;/usr/share/lua/5.3/luarocks/remove.lua;/usr/share/lua/5.3/luarocks/repos.lua;/usr/share/lua/5.3/luarocks/require.lua;/usr/share/lua/5.3/luarocks/search.lua;/usr/share/lua/5.3/luarocks/show.lua;/usr/share/lua/5.3/luarocks/site_config.lua;/usr/share/lua/5.3/luarocks/type_check.lua;/usr/share/lua/5.3/luarocks/unpack.lua;/usr/share/lua/5.3/luarocks/upload.lua;/usr/share/lua/5.3/luarocks/util.lua;/usr/share/lua/5.3/luarocks/validate.lua;/usr/share/lua/5.3/luarocks/write_rockspec.lua;/usr/share/lua/5.3/luarocks/build/builtin.lua;/usr/share/lua/5.3/luarocks/build/cmake.lua;/usr/share/lua/5.3/luarocks/build/command.lua;/usr/share/lua/5.3/luarocks/build/make.lua;/usr/share/lua/5.3/luarocks/fs/lua.lua;/usr/share/lua/5.3/luarocks/fs/tools.lua;/usr/share/lua/5.3/luarocks/fs/unix.lua;/usr/share/lua/5.3/luarocks/fs/win32.lua;/usr/share/lua/5.3/luarocks/fetch/cvs.lua;/usr/share/lua/5.3/luarocks/fetch/git_file.lua;/usr/share/lua/5.3/luarocks/fetch/git_http.lua;/usr/share/lua/5.3/luarocks/fetch/git_https.lua;/usr/share/lua/5.3/luarocks/fetch/git.lua;/usr/share/lua/5.3/luarocks/fetch/git_ssh.lua;/usr/share/lua/5.3/luarocks/fetch/hg_http.lua;/usr/share/lua/5.3/luarocks/fetch/hg_https.lua;/usr/share/lua/5.3/luarocks/fetch/hg.lua;/usr/share/lua/5.3/luarocks/fetch/hg_ssh.lua;/usr/share/lua/5.3/luarocks/fetch/sscm.lua;/usr/share/lua/5.3/luarocks/fetch/svn.lua;/usr/share/lua/5.3/luarocks/tools/patch.lua;/usr/share/lua/5.3/luarocks/tools/tar.lua;/usr/share/lua/5.3/luarocks/tools/zip.lua;/usr/share/lua/5.3/luarocks/upload/api.lua;/usr/share/lua/5.3/luarocks/upload/multipart.lua
LUA_CPATH=/usr/lib64/lua/5.3/posix/ctype.so;/usr/lib64/lua/5.3/posix/dirent.so;/usr/lib64/lua/5.3/posix/errno.so;/usr/lib64/lua/5.3/posix/fcntl.so;/usr/lib64/lua/5.3/posix/fnmatch.so;/usr/lib64/lua/5.3/posix/glob.so;/usr/lib64/lua/5.3/posix/grp.so;/usr/lib64/lua/5.3/posix/libgen.so;/usr/lib64/lua/5.3/posix/poll.so;/usr/lib64/lua/5.3/posix/pwd.so;/usr/lib64/lua/5.3/posix/sched.so;/usr/lib64/lua/5.3/posix/signal.so;/usr/lib64/lua/5.3/posix/stdio.so;/usr/lib64/lua/5.3/posix/stdlib.so;/usr/lib64/lua/5.3/posix/syslog.so;/usr/lib64/lua/5.3/posix/termio.so;/usr/lib64/lua/5.3/posix/time.so;/usr/lib64/lua/5.3/posix/unistd.so;/usr/lib64/lua/5.3/posix/utime.so;/usr/lib64/lua/5.3/mime/core.so;/usr/lib64/lua/5.3/socket/core.so;/usr/lib64/lua/5.3/socket/serial.so;/usr/lib64/lua/5.3/socket/unix.so;/usr/lib64/lua/5.3/term/core.so;/usr/lib64/lua/5.3/ssl.so;/usr/lib64/lua/5.3/zlib.so
I am still getting the same error as reported before.
EDIT 2
Found this post on Lua require function quite helpful. Following the discussion, I tried the following:
package.path="/usr/share/lua/5.3/?/?.lua"
package.cpath="/usr/lib64/lua/5.3/?/?.so"
I added these lines at the top my lua script that's causing the error. I also modified the environment variables, LUA_PATH and LUA_CPATH with the same value. The error still persists.
I am out of all possible options at this stage and would be glad if someone can shed some light on this issue.
I'm interested in ORB-SLAM2, So I searched and found this site
https://github.com/Phylliida/orbslam-windows <<
so I read the README file and copied it, but I found these errors.
enter image description here
I already installed OPENCV on windows and I set up the environment variables well.
How can I fix errors?
Try setting OpenCV_DIR in CMakeLists.txt
SET("OpenCV_DIR" "C:/opencv")
If you want an automated installation, build setup for ORB-SALM2, we have it in this repo, scripts\windows\bootstrap.batbuilds opencv and dependencies using vcpkg and build.bat compiles ORB-SLAM2. Bootstrap usually takes time for first time!!
1.Adding the variable to the system path like this.
2.Setting the variable by the cmake-gui.Then reconfigure.
3.Setting the include and lib path about opencv in the CMakeLists.txt manually.
Recently I'm learning openCV. I followed the tutorial on openCV website.
http://docs.opencv.org/doc/tutorials/core/how_to_scan_images/how_to_scan_images.html#howtoscanimagesopencv
However, when I compile my code using following command
g++ loadImage.cpp -o loadImage
the command line shows:
fatal error: 'opencv2/core/core.hpp' file not found
#include <opencv2/core/core.hpp>
^
I installed openCV with brew, I think it is OK. Then I use emacs to edit and g++ compile my code directly, is that the problem? I searched some similar problems but they refer to xCode environment. Thanks for your help!
You need to tell g++ where it can find the header files. I recommend you setup either eclipse or any other IDE that can handle that stuff for you (like Qt Creator or many others). You can follow the setup guides for OpenCV for instructions, if needed.
[edit: note that I know that emacs can also be setup to handle things like include and library paths, but I have no idea how, hence my recommendation for a full scale IDE]
You can also specify the path to the includes on the command line with -I, then it should also work. Example:
g++ -I/path/to/OpenCV-2.4.9/build/include loadImage.cpp -o loadImage
There are environment variables you can set so you don't have to specify this for every call (see this page for a complete list, specifically CPATH and it's variants might be of interest.
So I find an answer myself, using cmake! How did I miss that..
http://docs.opencv.org/doc/tutorials/introduction/linux_gcc_cmake/linux_gcc_cmake.html#linux-gcc-usage
I've been frustrated by the the CMake-CPack for almost one week.
The bad thing is the CMake-CPack online documentation does not document this part well.
After googling, I found this variables to use:
CPACK_PACKAGING_PREFIX # NOT documented
CMAKE_INSTALL_PREFIX # Documented, but the behavior seems weird
CPACK_INSTALL_PREFIX # NOT documented
CPACK_PACKAGE_INSTALL_DIRECTORY # Documented, but this variable does NOT work as the online document described
CPACK_PACKAGING_INSTALL_PREFIX # NOT documented
What I am trying to do is: package a Debian package using fakeroot make package, when the package is installed by sudo dpkg -i MyProgramPackageName, install it to /usr/local, with a subdirectory MyProgramPackageName. That is, all files should be installed under /usr/local/MyProgramPackageName-V.1.2.3.
I've been trying (CMake 2.8.3 and CMake 2.8.5) to tune these variables. I tried so many combinations, but failed.
The only way succeeded is:
Set(CPACK_PACKAGING_INSTALL_PREFIX /usr/local/MyProgramPackageName-V.1.2.3)
But this variable is NOT even documented, and the behavior cannot be guaranteed. If you are confused with my question, please advise me when to use CPACK_PACKAGE_INSTALL_DIRECTORY? because the documentation description about this variable is really attractive, and it is really what I want, but I just could not make it working.
Please advise me.
Peter
I didn't find any documentation to support this, but I did find some bug reports and email archives that seem to suggest that the following is what you should be doing:
set(CPACK_SET_DESTDIR true)
set(CPACK_INSTALL_PREFIX /opt/MySuperAwesomePrefix-v.1.2.3)
If CPACK_INSTALL_PREFIX is not set, it will default to CMAKE_INSTALL_PREFIX. Now relative paths from install(... DESTINATION dest) will end up as CPACK_INSTALL_PREFIX/dest inside your package file. This worked when I tried to generate a deb file.
The paths used by the CPACK are taken from the INSTALL directives in your CMakeLists.txt files. This allows the result package to mirror what a 'make install' would do. This keeps the CPACK configuration to a minimum.
So, from an example CMakeLists.txt file:
INSTALL(TARGETS ${APPLICATION} DESTINATION bin)
This will install to /usr/bin or /usr/local/bin. If you wanted to place it in a subdirectory you could do it here:
INSTALL(TARGETS ${APPLICATION} DESTINATION bin/myappdir)
Or entirely different directory:
INSTALL(TARGETS ${APPLICATION} DESTINATION /opt/foo/bar)