I was installing OpenCV on my Linux Mint Qiana system using this article.
So I downloaded OpenCv-3.0.0-beta from the official OpenCV website and followed the instructions.
I keep getting the error:
CMake Error: The source directory "/home/himanshi" does not appear to
contain CMakeLists.txt. Specify --help for usage, or press the help
button on the CMake
On typing this:
cmake -D WITH_TBB=ON -D BUILD_NEW_PYTHON_SUPPORT=ON -D WITH_V4L=ON -D INSTALL_C_EXAMPLES=ON -D INSTALL_PYTHON_EXAMPLES=ON -D BUILD_EXAMPLES=ON -D WITH_IPP=OFF -D CMAKE_INSTALL_PREFIX=/usr ..
What do I do now?
The .. at the end of your call tells CMake to look for the source code and especially the CMakeLists.txt which contains the configure instructions. You have to go to the directory where you have put the OpenCV files, create a build directory there, step into that directory and repeat the command. Than .. matches your source directory.
Related
I am new to building C lib and have mostly worked with python. My goal is to take the source code from https://github.com/torvalds/linux and build a custom driver for USB/IP (https://github.com/torvalds/linux/tree/master/drivers/usb/usbip) module (some modification).
I copied only /tool/usbip/ assuming that USB and USB-IP are already present in the alpine.
I have set up a docker Image:
FROM alpine
COPY . .
RUN apk add build-base autoconf automake libtool eudev-dev libusb-dev
WORKDIR /tool/usbip/
RUN ./autogen.sh
RUN ./configure
RUN make install
I am getting the following error for make install:
Step 7/7 : RUN make install
---> Running in 48f53c225a99
Making install in libsrc
make[1]: Entering directory '/tool/usbip/libsrc'
CC libusbip_la-names.lo
In file included from names.c:23:
usbip_common.h:18:10: fatal error: linux/usb/ch9.h: No such file or directory
18 | #include <linux/usb/ch9.h>
| ^~~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:459: libusbip_la-names.lo] Error 1
make[1]: Leaving directory '/tool/usbip/libsrc'
make: *** [Makefile:500: install-recursive] Error 1
This could mean that alpine doesn't have a USB drive. How do I compile and install the driver in that docker?
Another solution can be to build the entire Linux code from the repo, but can I use alpine and add a USB-IP driver there, as I can see that alpine is very lightweight?
I see some Kconfig and Makefile, but I need guidance on building the required driver, as my task also requires modifying drivers/USB/usbip code and building the driver for usbip.
Some blog links or youtube videos on build drivers will also help, but I was not able to find any good resources online.
Updated docker file:
FROM alpine:latest
COPY . /linux
RUN apk add build-base autoconf \
automake libtool eudev-dev \
linux-headers flex bison gmp-dev \
mpc1-dev mpfr-dev
WORKDIR /linux
RUN zcat /proc/config.gz > .config
RUN make olddefconfig
RUN make modules_prepare
RUN make M=drivers/usb/usbip modules
WORKDIR /linux/tools/usb/usbip/
RUN ./autogen.sh
RUN ./configure
RUN make install
Download kernel sources and go to its root.
Copy .config for system you want to build for. E.g. if it is your running system and it provides /proc/config.gz then zcat /proc/config.gz > .config
make olddefconfig
Ensure CONFIG_USBIP and other modules are enabled as a modules:
$ grep CONFIG_USBIP .config
CONFIG_USBIP_CORE=m
CONFIG_USBIP_VHCI_HCD=m
CONFIG_USBIP_VHCI_HC_PORTS=8
CONFIG_USBIP_VHCI_NR_HCS=1
CONFIG_USBIP_HOST=m
# CONFIG_USBIP_DEBUG is not set
If not, run make nconfig (or make menuconfig), navigate to Device Drivers->USB support->USB/IP support and enable it as a module (<M>); save configuration.
make modules_prepare
make M=drivers/usb/usbip modules
Your modules are in drivers/usb/usbip/
I am attempting to open multixterm on my desktop machine, but I end up with the error:
usr:~> multixterm
can't find package Expect
while executing
"package require Expect"
(file "/usr/local/bin/multixterm" line 6")
Any help would be appreciated. I've tried running multixterm on my laptop and on a friend's machine, and there is no issue there. Both Expect and multixterm exist in the /usr/local/bin/ directory.
Update: I've also found that neither kibitz nor autoexpect will run. I now assume that there is an issue with where the programs are looking for Expect. Does anyone know how I can verify/check that?
First, run ldd /usr/local/bin/expect to find out where the Expect library (libexpect) is. For example:
% ldd /usr/bin/expect | grep libexpect
libexpect.so.5.45 => /usr/lib/x86_64-linux-gnu/libexpect.so.5.45 (0x00007f230f348000)
%
Then, export the TCLLIBPATH var with the libexpect directory. For example (seems like you're using csh):
% setenv TCLLIBPATH /usr/lib/x86_64-linux-gnu
Then run your multixterm command.
Expect was dropped from ubuntu's default installation,
run once:
conda install -c eumetsat Expect
and things should work again.
In my experience on Ubuntu, libexpect.so obtained through apt cannot be used for package require because the file contains 3 undefined-symbols. (E.g. Debian Bug report logs - #890228)
So I compiled the libexpect.so from its source. To do so, I had to compile 3 sources: Tcl, Tk, and Expect.
After decompressing sources, installing by following:
$ cd /path/to/install
$ mkdir tcl tk expect
$
$ /path/to/download/tcl8.*.*/unix/configure \
--prefix=/path/to/install/tcl
$ make ; make install
$
$ /path/to/download/tk8.*.*/unix/configure \
--with-tcl=/path/to/install/tcl \
--prefix=/path/to/install/tk
$ make ; make install
$
$ /path/to/download/expect5.*.*/configure \
--with-tclconfig=/path/to/install/tcl/lib \
--with-tkconfig=/path/to/install/tk/lib \
--prefix=/path/to/install/expect
$ make ; make install
gave me the file /path/to/install/expect/libexpect5.*.*.so for 64-bit architecture without undefined-symbols.
Here are 2 useful links about compiling:
How to Compile Tcl
[SOLVED] configuration error: Can't find Tcl configuration definition
Finally, in the case TCLLIBPATH does not work, unwarping approach using TclKits with sdx can be remedy. On Ubuntu, I used one for RHEL5 x86_64.
Basically I'm trying to compile the simplest code to Windows while I am developing on Linux.
fn main() {
println!("Hello, and bye.")
}
I found these commands by searching the internet:
rustc --target=i686-w64-mingw32-gcc main.rs
rustc --target=i686_pc_windows_gnu -C linker=i686-w64-mingw32-gcc main.rs
Sadly, none of them work. It gives me an error about the std crate missing
$ rustc --target=i686_pc_windows_gnu -C linker=i686-w64-mingw32-gcc main.rs
main.rs:1:1: 1:1 error: can't find crate for `std`
main.rs:1 fn main() {
^
error: aborting due to previous error
Is there a way to compile code on Linux that will run on Windows?
Other answers, while technically correct, are more difficult than they need to be. There's no need to use rustc (in fact it's discouraged, just use cargo), you only need rustup, cargo and your distribution's mingw-w64.
Add the target (you can also change this for whatever target you're cross compiling for):
rustup target add x86_64-pc-windows-gnu
You can build your crate easily with:
cargo build --target x86_64-pc-windows-gnu
No need for messing around with ~/.cargo/config or anything else.
EDIT: Just wanted to add that while you can use the above it can also sometimes be a headache. I wanted to add that the rust tools team also maintains a project called cross: https://github.com/rust-embedded/cross
This might be another solution that you want to look into
The Rust distribution only provides compiled libraries for the host system. However, according to Arch Linux's wiki page on Rust, you could copy the compiled libraries from the Windows packages in the download directory (note that there are i686 and x86-64 packages) in the appropriate place on your system (in /usr/lib/rustlib or /usr/local/lib/rustlib, depending on where Rust is installed), install mingw-w64-gcc and Wine and you should be able to cross-compile.
If you're using Cargo, you can tell Cargo where to look for ar and the linker by adding this to ~/.cargo/config (where $ARCH is the architecture you use):
[target.$ARCH-pc-windows-gnu]
linker = "/usr/bin/$ARCH-w64-mingw32-gcc"
ar = "/usr/$ARCH-w64-mingw32/bin/ar"
Note: the exact paths can vary based on your distribution. Check the list of files for the mingw-w64 package(s) (GCC and binutils) in your distribution.
Then you can use Cargo like this:
$ # Build
$ cargo build --release --target "$ARCH-pc-windows-gnu"
$ # Run unit tests under wine
$ cargo test --target "$ARCH-pc-windows-gnu"
UPDATE 2019-06-11
This fails for me with:
Running `rustc --crate-name animation examples/animation.rs --color always --crate-type bin --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' -C metadata=006e668c6384c29b -C extra-filename=-006e668c6384c29b --out-dir /home/roman/projects/rust-sdl2/target/x86_64-pc-windows-gnu/debug/examples --target x86_64-pc-windows-gnu -C ar=x86_64-w64-mingw32-gcc-ar -C linker=x86_64-w64-mingw32-gcc -C incremental=/home/roman/projects/rust-sdl2/target/x86_64-pc-windows-gnu/debug/incremental -L dependency=/home/roman/projects/rust-sdl2/target/x86_64-pc-windows-gnu/debug/deps -L dependency=/home/roman/projects/rust-sdl2/target/debug/deps --extern bitflags=/home/roman/projects/rust-sdl2/target/x86_64-pc-windows-gnu/debug/deps/libbitflags-2c7b3e3d10e1e0dd.rlib --extern lazy_static=/home/roman/projects/rust-sdl2/target/x86_64-pc-windows-gnu/debug/deps/liblazy_static-a80335916d5ac241.rlib --extern libc=/home/roman/projects/rust-sdl2/target/x86_64-pc-windows-gnu/debug/deps/liblibc-387157ce7a56c1ec.rlib --extern num=/home/roman/projects/rust-sdl2/target/x86_64-pc-windows-gnu/debug/deps/libnum-18ac2d75a7462b42.rlib --extern rand=/home/roman/projects/rust-sdl2/target/x86_64-pc-windows-gnu/debug/deps/librand-7cf254de4aeeab70.rlib --extern sdl2=/home/roman/projects/rust-sdl2/target/x86_64-pc-windows-gnu/debug/deps/libsdl2-3f37ebe30a087396.rlib --extern sdl2_sys=/home/roman/projects/rust-sdl2/target/x86_64-pc-windows-gnu/debug/deps/libsdl2_sys-3edefe52781ad7ef.rlib -L native=/home/roman/.cargo/registry/src/github.com-1ecc6299db9ec823/winapi-x86_64-pc-windows-gnu-0.4.0/lib`
error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1
Maybe this will help https://github.com/rust-lang/rust/issues/44787
Static compile sdl2
There is option to static-compile sdl but it didn't work for me.
Also mixer is not included when used with bundled.
Let's cross-compile examples from rust-sdl2 project from Ubuntu to Windows x86_64
In ~/.cargo/config
[target.x86_64-pc-windows-gnu]
linker = "x86_64-w64-mingw32-gcc"
ar = "x86_64-w64-mingw32-gcc-ar"
Then run this:
sudo apt-get install gcc-mingw-w64-x86-64 -y
# use rustup to add target https://github.com/rust-lang/rustup.rs#cross-compilation
rustup target add x86_64-pc-windows-gnu
# Based on instructions from https://github.com/AngryLawyer/rust-sdl2/
# First we need sdl2 libs
# links to packages https://www.libsdl.org/download-2.0.php
sudo apt-get install libsdl2-dev -y
curl -s https://www.libsdl.org/release/SDL2-devel-2.0.9-mingw.tar.gz | tar xvz -C /tmp
# Prepare files for building
mkdir -p ~/projects
cd ~/projects
git clone https://github.com/Rust-SDL2/rust-sdl2
cd rust-sdl2
cp -r /tmp/SDL2-2.0.9/x86_64-w64-mingw32/lib/* ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/
cp /tmp/SDL2-2.0.9/x86_64-w64-mingw32/bin/SDL2.dll .
Build examples at once
cargo build --target=x86_64-pc-windows-gnu --verbose --examples
Or stop after first fail:
echo; for i in examples/*; do [ $? -eq 0 ] && cargo build --target=x86_64-pc-windows-gnu --verbose --example $(basename $i .rs); done
Run
cargo build will put binaries in target/x86_64-pc-windows-gnu/debug/examples/
Copy needed files:
cp /tmp/SDL2-2.0.4/x86_64-w64-mingw32/bin/SDL2.dll target/x86_64-pc-windows-gnu/debug/examples/
cp assets/sine.wav target/x86_64-pc-windows-gnu/debug/examples/
Then copy directory target/x86_64-pc-windows-gnu/debug/examples/ to your Windows machine and run exe files.
Run in cmd.exe
If you want to see the console output when running exe files, you may run them from cmd.exe.
To open cmd.exe in current directory in file explorer, right click with shift on empty place in window and choose Open command window here.
Backtraces with mingw should work now - if not use msvc https://github.com/rust-lang/rust/pull/39234
There is Docker based solution called cross. All the required tools are in virtualized environment so you don't need to install additional packages for your machine. See Supported targets list.
From project's README:
Features
cross will provide all the ingredients needed for cross compilation without touching your system installation.
cross provides an environment, cross toolchain and cross compiled libraries, that produces the most portable binaries.
“cross testing”, cross can test crates for architectures other than i686 and x86_64.
The stable, beta and nightly channels are supported.
Dependencies
rustup
A Linux kernel with binfmt_misc support is required for cross testing.
One of these container engines is required. If both are installed, cross will default to docker.
Docker. Note that on Linux non-sudo users need to be in the docker group. Read the official post-installation steps. Requires version 1.24 or later.
Podman. Requires version 1.6.3 or later.
Installation
$ cargo install cross
Usage
cross has the exact same CLI as Cargo but as it relies on Docker you'll have to start the daemon before you can use it.
# (ONCE PER BOOT)
# Start the Docker daemon, if it's not already running
$ sudo systemctl start docker
# MAGIC! This Just Works
$ cross build --target aarch64-unknown-linux-gnu
# EVEN MORE MAGICAL! This also Just Works
$ cross test --target mips64-unknown-linux-gnuabi64
# Obviously, this also Just Works
$ cross rustc --target powerpc-unknown-linux-gnu --release -- -C lto
The solution that worked for me was. It is similar to one of the accepted answers but I did not require to add the toolchain.
rustup target add x86_64-pc-windows-gnu
cargo build --target x86_64-pc-windows-gnu
Refer to the documentation for more details.
I've had success on Debian (testing) without using Mingw and Wine just following the official instructions. They look scary, but in the end it didn't hurt that much.
The official instructions also contain info on how to cross-compile C/C++ code. I haven't needed that, so it's something I haven't actually tested.
A couple of remarks for individual points in the official instructions. The numbers match the numbers in the official instructions.
Debian: sudo apt-get install lld
Make a symlink named lld-link to lld somewhere in your $PATH. Example: ln -s /usr/bin/lld local_bin/lld-link
I don't cross-compile C/C++, haven't used this point personally.
This is probably the most annoying part. I installed Rust on a Windows box via rustup, and copied the libraries from the directories named in the official docs to the Linux box. Beware, there were sometimes uppercase library filenames, but lld wants them all lowercase (Windows isn't case-sensitive, Linux is). I've used the following to rename all files in current directory to lowercase:
for f in `find`; do mv -v "$f" "`echo $f | tr '[A-Z]' '[a-z]'`"; done
Personally, I've needed both Kit directories and just one of the VC dirs.
I don't cross-compile C/C++, haven't used this point personally.
Just make $LIB_ROOT in the script at the end of this post point to the lib directory from point 3.
Mandatory
I don't cross-compile C/C++, haven't used this point personally.
Depending the target architecture, either of the following:
rustup target add i686-pc-windows-msvc
rustup target add x86_64-pc-windows-msvc
For cross-building itself, I'm using the following simple script (32-bit version):
#!/bin/sh
# "cargo build" for the 32-bit Windows MSVC architecture.
# Set this to proper directory
LIB_ROOT=~/opt/rust-msvc
# The rest shouldn't need modifications
VS_LIBS="$LIB_ROOT/Microsoft Visual Studio 14.0/VC/lib/"
KIT_8_1_LIBS="$LIB_ROOT/Windows Kits/8.1/Lib/winv6.3/um/x86/"
KIT_10_LIBS="$LIB_ROOT/Windows Kits/10/Lib/10.0.10240.0/ucrt/x86/"
export LIB="$VS_LIBS;$KIT_8_1_LIBS;$KIT_10_LIBS"
cargo build --target=i686-pc-windows-msvc "$#"
I'm using the script the same way I would use cargo build
Hope that helps somebody!
I am trying to build and install TBB library from source so that it can be used for OpenCV to take advantages of multiple cores on my raspberry pi.
I was able to build TBB from source without any problems using this steps.
(Source : How do I build OpenCV with TBB on Raspberry Pi?)
wget -O ~/tbb43_20150316oss_src.tgz --no-check-certificate https://www.threadingbuildingblocks.org/sites/default/files/software_releases/source/tbb43_20150316oss_src.tgz
tar -xvzf tbb43_20150316oss_src.tgz
cd tbb43_20150316oss
make tbb CXXFLAGS="-DTBB_USE_GCC_BUILTINS=1 -D__TBB_64BIT_ATOMICS=0"
However, it's not getting detected while cmake step of building OpenCV.
Where do I add generated .so files and .h files to system paths so that cmake can detect it ?
Thanks.
Run 'make install' in the TBB source directory after running make it should install the files to the correct locations.
You can use the CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH environment variables to help CMake find your custom-built TBB by prefixing your cmake command like so:
CMAKE_INCLUDE_PATH=~/tbb43_20150611oss/include/ \
CMAKE_LIBRARY_PATH=~/tbb43_20150611oss/build/*_release/ \
cmake -DWITH_TBB=ON -DCMAKE_BUILD_TYPE=RELEASE \
-DCMAKE_INSTALL_PREFIX=/usr/local \
-DBUILD_NEW_PYTHON_SUPPORT=ON \
-DINSTALL_C_EXAMPLES=ON \
-DINSTALL_PYTHON_EXAMPLES=ON \
-DBUILD_EXAMPLES=ON ..
As a work around, I created tbb.pc file to /usr/lib/pkgconfig/.
Here is a sample of that file. https://github.com/openembedded/meta-oe/blob/master/meta-oe/recipes-support/tbb/tbb/tbb.pc
Change prefix, libdir and include dir path according to your own tbb path and you're good to go. Hope it helps.
I've seen some articles about how to compile and uses FFmpeg for Android.
These are 2 good examples - example1 and example2
Unfortunately, non off them, or others I found helped me. In those two examples a build_android.sh is created and configure the FFmpeg's configuraion file and call to make. Every time when I'm running the script I'm getting the following error:
c:\android\development\android-ndk-r9\sources\ffmpeg>sh build_android.sh
c:/android/development/android-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebu
ilt/windows-x86_64/arm-linux-androideabi/bin/bin/arm-linux-androideabi-gcc is un
able to create an executable file.
C compiler test failed.
If you think configure made a mistake, make sure you are using the latest
version from Git. If the latest version fails, report the problem to the
ffmpeg-user#ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "config.log" produced by configure as this will help
solving the problem.
Makefile:2: config.mak: No such file or directory
Makefile:49: /common.mak: No such file or directory
Makefile:92: /libavutil/Makefile: No such file or directory
Makefile:92: /library.mak: No such file or directory
Makefile:169: /doc/Makefile: No such file or directory
Makefile:170: /tests/Makefile: No such file or directory
make: *** No rule to make target `/tests/Makefile'. Stop.
Makefile:2: config.mak: No such file or directory
If someone encountered and solved this issue it'll be much appreciated!
After trying the suggested script I ran into a new problem that I couldn't solved, this is the output of the script:
.... Enabled components list....
In the end of the list I got the following:
Enabled indevs:
dv1394 v4l2i
fbdev
Enabled outdevs:
fbdev v4l2
License: LGPL version 2.1 or later
Creating config.mak, config.h, and doc/config.texi...
WARNING: C:/android/development/android-ndk-r9/toolchains/arm-linux-androideabi-
4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-pkg-config not found, libr
ary detection may fail.
make: *** No rule to make target libavfilter/libavfilter.so', needed by all-ye
s'. Stop.
make: *** No rule to make target install-libavfilter-shared', needed by instal
l-libs-yes'. Stop.
Can you paste what's in your build_android.sh file which you've copied inside the FFmpeg directory?
I've got the same error when one of the variables defined at the start of the script where set incorrectly. Check to see if your NDK or SYSROOT or TOOLCHAIN variables are set to a valid path!
I've tried using the following steps and it worked for me:
1) Download FFmpeg
git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg
2) Create a file called build_android.sh inside the FFmpeg directory
cd ffmpeg; touch build_ffmpeg_for_android.sh;
3) Add the following content to the file
#!/usr/bin/env bash
NDK=$HOME/Software/Android/android-ndk-r10/
SYSROOT=$NDK/platforms/android-19/arch-arm/
TOOLCHAIN=$NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64
function build_one
{
./configure \
--prefix=$PREFIX \
--enable-shared \
--disable-static \
--disable-doc \
--disable-ffmpeg \
--disable-ffplay \
--disable-ffprobe \
--disable-ffserver \
--disable-avdevice \
--disable-doc \
--disable-symver \
--cross-prefix=$TOOLCHAIN/bin/arm-linux-androideabi- \
--target-os=linux \
--arch=arm \
--enable-cross-compile \
--sysroot=$SYSROOT \
--extra-cflags="-Os -fpic $ADDI_CFLAGS" \
--extra-ldflags="$ADDI_LDFLAGS" \
$ADDITIONAL_CONFIGURE_FLAG
make clean
make -j4
make install
}
CPU=arm
PREFIX=$(pwd)/android/$CPU
ADDI_CFLAGS="-marm"
build_one
4) Make the script executable
chmod +x build_ffmpeg_for_android.sh
5) Start the build of FFmpeg for Android (ARM)
(run the script with Bash, i.e. /usr/bin/bash not /usr/bin/sh)
./build_ffmpeg_for_android.sh
I was getting the same errors as #powerX and I was able to solve the issue using a different method from #dZkF9RWJT6wN8ux.
Though I am using Ubuntu 13.10, I hope you find my answer helpful. With android NDK r9 and FFMPEG 2.2 "Muybridge" release, I was finally able to accomplish the third step entitled "Build FFMPEG" from #powerX example1 link: http://www.roman10.net/how-to-build-ffmpeg-with-ndk-r9/
I finally fixed this by changing the SYSROOT variable in the build_android.sh file to point to ".../android-19/arch-arm" instead of .../android-9/arch-arm".
Hope this helps.