To make it simple, I want to use the OpenCV libs within my embedded ElinOS system, while programming on my Windows machine.
To do so, I downloaded OpenCV sources for Linux on the website and I'm trying to compile it using cygwin and cmake to generate the Makefile. However, I have an error occuring during the "make" step, which is /usr/include/wchar.h:41:25: fatal error : bits/wchar.h : No such file or directory
I understand the problem, which is basically that cygwin should use /opt/elinos-6.0/cdk/x86/x86_64/eglibc-2.17/x86_64-unkown-linux-gnu/include instead of /usr/include but I have basically no idea how to change that.
That far, I added those two lines to the CMakeLists.txt
set(CMAKE_INCLUDE_DIRECTORIES_BEFORE ON)
include_directories(BEFORE C:/sysgo/opt/elinos-6.0/cdk/x86/x86_64/eglibc-2.17/x86_64-unkown-linux-gnu/include/)
and this line to the builded Makefile:
INC = -I/cygdrive/c/sysgo/opt/elinos-6.0/cdk/x86/x86_64/eglibc-2.17/x86_64-unknown-linux-gnu/include/
But it didn't work, I still got the same error. Any help is welcome, and I would be glad if an explanation comes with the magic command line(s) that will help.
Thanks in advance!
one way for you might be to clear the standard include path completly:
first delete standard path with -nostdinc and then put your own directories in it.
you might not want loose all of them, here is a way to see which are used in the standard include path: echo "//" | gcc -xc++ -E -v - (works also with clang)
Here is a fine article for this for gcc :
http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art026
here you can read it works with clang too:
http://clang.llvm.org/docs/CommandGuide/clang.html
Related
I'm trying to use conda to manage several dependencies for a c++ library I'm building (I was previously using git submodules in my project's external/ dir which worked fine, but for a number of reasons I wanted to migrate to conda).
The libraries I need to use are tbb, zstd, and cspice. I've verified they are all installed correctly by conda, and are in my environment (named vira_env). The headers are very clearly in ~/mamba_envs/vira_env/include/.
However when I add include_directories(${CMAKE_INSTALL_PREFIX}/include) to my root CMakeLists.txt and run cmake using -DCMAKE_INSTALL_PREFIX=${CONDA_PREFIX}, it fails to find any of the headers.
Running make VERBOSE=1 reveals that g++ has no -I argument to include the ~/mamba_envs/vira_env/include/ directory. Which makes sense, as it is failing to find the headers that are there.
However, if I use include_directories(${CMAKE_INSTALL_PREFIX}) and rerun make VERBOSE=1, or it clearly shows that g++ has a -I /home/cgnam/mamba_envs/vira_env/.
Similarly, if I use include_directories(${CMAKE_INSTALL_PREFIX}/include/oneapi) it shows g++ has a -I /home/cgnam/mamba_envs/vira_env/include/oneapi. (oneapi is the directory where the tbb headers are placed).
So include_directories() will happily use either the conda environment root, or even one of the directories inside the conda environment's include/ directory... but it will just completely ignore the include/ directory itself.
EDIT
As discovered in one of my comments below, printing CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES shows /home/cgnam/mamba_envs/vira_env/include. Which explains why my include_directories() is not having any effect on the g++ call by make, since it believes that the compiler should be looking in that directory already.
make VERBOSE=1is showing that the compiler being used is: /home/cgnam/mamba_envs/vira_env/bin/x86_64-conda-linux-gnu-c++. However using which g++ is showing ~/mamba_envs/vira_env/bin/g++. Further, which ld returns: ~/mamba_envs/vira_env/bin/ld.
If I use ld --verbose | grep SEARCH_DIR, it does not show /home/cgnam/mamba_envs/vira_env/include. Neither does ~/mamba_envs/vira_env/bin/x86_64-conda-linux-gnu-ld --verbose | grep SEARCH_DIR.
I have recently installed CMake in order to write code to make use of Libbitcoin in C++ but I am having a hard time, I was trying to build the example code on GitHub here. And it haters been going terribly. I can't manage to link the library right in CMake, here is my code. I read and people were saying that I should try Autoconf but I have no idea how to even start that as I know nothing about Autoconf. I have CMake 3.16, and installed Libbitcoin with brew but alias were made in /usr/local/include for the library, I am on Mac OS X 10.15. The CMake runs fine but when running "make", it responds with:
Scanning dependencies of target CreateAddr
main.cxx:1:10: fatal error: bitcoin/bitcoin.hpp: No such file or directory
1 | #include <bitcoin/bitcoin.hpp>
| ^~~~~~~~~~~~~~~~~~~~~
Here is my CMake text:
Please all help is appreciated I am beyond lost.
It is hard to be sure without knowing the specifics of your installation, but it appears that your include directory paths may be overlapping with what is specified for the header in main.cxx. The include_directories() call tells the compiler to include headers from this directory:
/usr/local/include/bitcoin
Then, in main.cxx, you're including the file with bitcoin/bitcoin.hpp. Combining these suggests the file is located here:
/usr/local/include/bitcoin/bitcoin/bitcoin.hpp
The error states the header could not be found, so perhaps you meant to locate it here:
/usr/local/include/bitcoin/bitcoin.hpp
In that case, just remove the relative directory path from the main.cxx file, like this:
#include <bitcoin.hpp>
Also, you want to link to your libbitcoin library correctly. Using link_directories() is not recommended. Instead, you can specify the full path to your libbitcoin library directly in the call to target_link_libraries(). The library may not be located in /usr/local/include/bitcoin. With these changes, the last few lines in your CMake would look something more like this:
include_directories(/usr/local/include/bitcoin)
add_executable(CreateAddr main.cxx)
target_link_libraries(CreateAddr PUBLIC /your/path/to/libs/libbitcoin.so)
I have a c++ application that is separated into modules. The directory structure for each module looks like this:
module_a/
export/ <-- module_a public interface
src/ <-- module_a private source
test/
src/ <-- unittests for module_a
I'm using CMake to setup the module dependencies and to build the application. If module_a depends on module_b then module_b's export directory is added as include path when building module_a.
So, if there is a file module_b/export/foo.h that module_a needs then in a source file you will use #include "foo.h".
I'm looking for a way to to make so that the module name is part of the include directive. So for the above example I want to (have to) write #include "module_b/foo.h".
Is this something that can be done with GCC option -iprefix and -iwithprefix? I've searched for usage examples but all I can find is copies and references back to the GCC manual, which I think doesn't explain it very well.
I have tried to use it this way:
$ find -type f
./src
./src/main.cc
./export
./export/bar.h
$ g++ -iprefix foo/ -iwithprefix export/ src/main.cc
src/main.cc:1:10: fatal error: foo/bar.h: No such file or directory
1 | #include "foo/bar.h"
| ^~~~~~~~~~~
compilation terminated.
$ gcc --version
gcc (Debian 9.2.1-17) 9.2.1 20191102
But as you can see, it doesn't work. How should I use -iprefix and -iwithprefix?
Also, does anyone have another solution to my problem? I'm a bit worried that IDEs and other compilers might not understand -iprefix and -iwithprefix, so any other solutions are welcome as well.
Edit: after posting this question I immediately realized that perhaps -iprefix foo/ -iwithprefix bar is just a fancy way of writing -I foo/bar. However, I tested that and I still didn't get it to work. So it would still be good if someone could explain how these options works, even if they are not going to help me for my problem.
How should I use -iprefix and -iwithprefix?
It's just a shortcut to avoid having to write out a common prefix every time. So instead of:
cpp -Idirafter /sys/root/a -Idirafter /sys/root/b
You instead do:
cpp -iprefix /sys/root/ -iwithprefix a -withprefix b
(substitute -Iwithprefix for -Iwithprefixbefore if you want it to be equivalent to -I instead.)
This can come on handy with very long include directory paths like you may run into when cross-compiling (and may be even required, cf. getconf ARG_MAX)
Also, does anyone have another solution to my problem?
I stumbled upon -iprefix, because I've the same problem you have as well and hoped there would be an out-of-the-box option for that. There isn't, but Linux device tree builds have the same issue:
The device trees for ARCH=arm and ARCH=arm64 are in arch/arm/boot/dts and arch/arm64/boot/dts, respectively. Sometimes, arm64 device trees need some common file from the arm directory, but having the dts directories of all architectures in path isn't that great a solution.
What Linux does instead, is having a dedicated directory in the source tree with suitably-named symlinks into each architecture and this directory's path as well as the directory of the currently active ARCH go into the search path. That way, ARCH=arm can write #include "something.dtsi", but ARCH=arm64 has to write #include <arm/something.dtsi> instead.
As part of a research project I'm trying to use clang 6.0.1 with Xcode 9.4.1. I've built and installed clang in a custom location (/opt/llvm-6_0_1/clang). I wrote a simple xcplugin compiler specification to integrate my clang version with Xcode.
Now I can open projects in Xcode, select my proxy compiler and use it to build instead of Apple's default clang.
There were some minor additions that I had to make to the xcplugin's xcspec file to get this to work that probably won't be interesting to most people, so I won't provide the details here unless asked.
This all works with most of the projects I've played with, but I'm running into an odd problem where an implicitly linked static library cannot be found by my copy of clang. Specifically I get this error:
ld: file not found: /opt/llvm-6_0_1/clang/Toolchains/LLVM6.0.1.xctoolchain/usr/lib/arc/libarclite_macosx.a
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
Note that the libarclite_macosx.a file is not explicitly included by the Xcode project. I figured it must be implicitly included, perhaps because this project enables ARC?
After pouring over the Xcode generated link command line (it's complex) I decided to look at the MyProject__dependency_info.dat file, which is passed in via the -dependency_info option. Apparently this data file (the path is defined as env var LD_DEPENDENCY_INFO_FILE) is created during the linking process, not as an input to the linker. Perhaps it exists because of a hack workaround using symlinks that I used to get a link to work (described at the end).
In any case the format appears to be binary, but I was able to see a text reference to libarclite_macosx.a in the file:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc/libarclite_macosx.a
After enabling the -Xlinker -v option I could see that my built clang was not searching the default toolchain lib or arc paths so I added them:
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc
Now I can see the search paths in the verbose output, but clang still cannot find the library:
Library search paths:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc
I've tried adding the paths to the frameworks search paths. I also tried defining the various link path env vars. Nothing has worked.
To try to get a sense of what clang is actually doing, I used fs_usage while getting the link error:
sudo fs_usage -e -w -f filesys | grep "lib/arc"
14:11:00.461965 stat64 [ 2] /opt/llvm-6_0_1/clang/Toolchains/LLVM6.0.1.xctoolchain/usr/lib/arc>>>>>>>>>>>>>>>>>>>>>> 0.000006 ld.1421614
14:11:00.461968 stat64 [ 2] /opt/llvm-6_0_1/clang/Toolchains/LLVM6.0.1.xctoolchain/usr/lib/arc>>>>>>>>>>>>>>>>>>>>>> 0.000002 ld.1421614
Clearly clang really wants to look for this file in the installed location, not the location indicated in the -dependency_info, nor in the search paths that I'm providing.
At this stage the only way I can get a build to work is to add a symlink to Xcode's "arc" directory to my installed clang lib directory. That "works", but is fragile and nasty.
Any thoughts as to how how I can get clang find the static library where it actually lives?
I would like to generate glut .so file in Ubuntu. I've downloaded the files, extracted them and opened the readme. This is the instructions for Linux
MAKEFILE GENERATION TO BUILD GLUT: <-- IMPORTANT!
Use "mkmkfiles.sgi" to put Makefiles using the SGI Makefile conventions
in place. Use "mkmkfiles.imake" to put Makefiles generated from
Imakefiles in place. Run one of these two commands in this directory,
then do a "make".
I don't really understand SGI Makefile. I know Makefile though. Could you please guide me for generating the dll. In the folder, these are the files
adainclude Imakefile mkmkfiles.imake README.fortran README.man
CHANGES include mkmkfiles.sgi README.glut2 README.mesa
FAQ.glut lib mkmkfiles.win README.glut3 README.mui
Glut.cf linux NOTICE README.ibm-shlib README.win
glutdefs Makefile Portability.txt README.inventor README.xinput
glutmake.bat Makefile.sgi progs README.irix6 test
glutwin32.mak Makefile.win README README.irix64bit
IAFA-PACKAGE man README.ada README.linux
I've tried running make but getting errors and there is no CMakeLists. Thank you.
When I run ./mkmkfiles.sgi or mkmkfiles.imake, I get this error
bash: ./mkmkfiles.sgi: /bin/csh: bad interpreter: No such file or directory
Technically you need first to instal tcsh. With that installed, running mkmkfiles.imake will work and generate the required Makefile so you can build on Linux. Here is an old post asking pretty much the same question: http://comments.gmane.org/gmane.linux.lfs.general/17539