I'm using CMake 3.4.1, on Windows 10, with MSYS2 (everything up-to-date as of Dec. 25 2015).
When I use CMake's find_file command, it won't work unless the path is in Windows-style. This is a problem for me, because I'm trying to use findwxWidgets.cmake, which fails because of this.
For example:
CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
find_file(version_h version.h PATHS /mingw64/include/wx-3.0/wx)
message(STATUS "version_h: ${version_h}")
Running cmake spits out:
-- version_h: version_h-NOTFOUND
But it's clearly in there:
>>> file /mingw64/include/wx-3.0/wx/version.h
/mingw64/include/wx-3.0/wx/version.h: C source, ASCII text
I'm wondering if this is a bug, or if there's some obscure flag I have to set to get this to work. How do I get CMake's find_file to find files with UNIX-style paths?
MinGW-w64 cmake can't understand MSYS2 paths. You might propose a path transformation test program to the CMake developers, but that's fairly gross and I'd hope the would reject that. Instead these things must be solved case-by-case. wx-config, being a shell script, is providing an MSYS2 path.
This is a bug in the currently release MSYS2 wxWidgets packages that will be fixed in the next release. To work around it, find the line in /mingw64/bin/wx-config or /mingw32/bin/wx-config:
prefix=${input_option_prefix-${this_prefix:-/mingw64}}
(or /mingw32 of course) and add after it:
if [ "x${MSYSTEM}" = "xMINGW32" ] || [ "x${MSYSTEM}" = "xMINGW64" ]; then
prefix=$(cygpath -m ${prefix})
fi
Be careful to remove it at upgrade time though.
Related
This is basically the same issue as in mingw ld cannot find some library which is exist in the search path, MinGW linker can't find MPICH2 libraries - and I'm aware that there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW - but I couldn't find anything that explains how I can troubleshoot.
I am building a project with a huge linker command like (via g++) on MinGW, in a MSYS2 shell (git-bash.exe). The process fails with, among others:
/z/path/to/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lssl
I add -Wl,--verbose to the g++ linker call (to be passed to ld), and I can see for the -L/z/path/to/libs/openssl/lib/mingw -lssl:
...
attempt to open /z/path/to/libs/openssl/lib/mingw/libssl.a failed
...
/z/path/to/libs/openssl/lib/mingw/ssl.dll failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
But this is weird, because the file exists?
$ file /z/path/to/libs/openssl/lib/mingw/libssl.a
/z/path/to/libs/openssl/lib/mingw/libssl.a: current ar archive
(... and it was built with the same compiler on the same machine)?
Weirdly, once it attempts to open with forward slash .../libssl.a, once with backslash ...\libssl.a - but at least the first path checks out in a bash shell, as shown above?
It gets even worse if I try to specify -l:libssl.a -- or if I specify -L/z/path/to/libs/openssl/lib/mingw -Wl,-Bstatic -lssl -- instead; then all attempts to open are with a backslash:
...
attempt to open /z/path/to/scripts/other/build/openssl/build/mingw/lib\libssl.a failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
To top it all off, if I look it up manually through the command line using ld, it is found ?!:
$ ld -L/z/path/to/libs/openssl/lib/mingw -lssl --verbose
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/ssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
Does anyone have an idea why this happens, and how can I get ld to finally find these libraries? Or rather - how can I troubleshoot, and understand why these libraries are not found, when they exist at the paths where ld tries to open them?
OK, found something more - not sure if this is a bug; but my problem is that I'm actually reading arguments from a file (otherwise I get g++: Argument list too long). So, to simulate that:
$ echo " -Wl,--verbose -L/z/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
# nothing
$ g++ `cat tcmd3` 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
... it turns out, if the very same arguments are fed on the command line, then static library lookup succeeds - but if the arguments are read from file through the # at-sign, then static library lookup fails?! Unfortunately, I cannot use on my actual project, since even with cat, I'd still get g++: Argument list too long ... So how can I fix this?
MSYS has special handling of directories as arguments when they are used in the shell. This translates e.g. /<drive_letter>/blabla to the proper Windows style paths. This is to accomodate Unix programs that don't handle Z: style directory root.
What you see here is that MSYS isn't performing this interpretation for string read from a file. When you think about it, it's very logical, but as you have experienced first-hand, also sometimes annoying.
Long story short: don't put Unix style paths in files with command arguments. Instead, pass them through e.g. cygpath -w, which works in MSYS2 (which should be the MSYS that Git for Windows 2+ comes with).
Ok, with some more experiments, I noticed that:
-L/z/path/to/libs/openssl/lib/mingw, the Unix path specification, tends to fail - while if we specify the same, except starting with a Windows drive letter, that is:
-LZ:/path/to/libs/openssl/lib/mingw, then things work - also from an arguments file with # at-sign:
$ echo " -Wl,--verbose -LZ:/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
I guess, since the shell is MSYS2/git-bash.exe, entering full POSIX paths on the shell with /z/... is not a problem, because the shell will convert them - but in a file, there is nothing to convert them, so we must use Windows/MingW convention to specify them...
I am attempting to rebuild my development/test environment on a new laptop running windows7 32 bit. imageMagick is one of the modules I had installed in an (ancient) version on my old laptop. I have downloaded and installed perl from dwimperl, which is v5.14.2 and had a couple modules install, and several did not.
cpanm Image::Magick - failed
cpanm DB_File - failed
cpanm Time::HiRes - failed
I searched around and found a discussion on magick failing to install on v5.12, but couldn't tell if that was supposed to have been fixed, or if I need to attempt to recreate the fix discussed for 5.12
should I try installing perl from Strawberry? looks like it is a little newer v5.18 ?
is there something I can tweak and re-run cpan installs?
I installed the binaries from imagemagick, from Link first, then cpan again, and cpan still fails....
This is the top part of the build log down to where it really goes south and starts kicking out errors:
cpanm (App::cpanminus) 1.6941 on perl 5.014002 built for MSWin32-x86-multi-thread
Work directory is C:\Users\dtbaker/.cpanm/work/1377281741.8420
You have make C:\Dwimperl\c\bin\dmake.exe
You have LWP 6.03
Falling back to Archive::Tar 1.80
Searching Image::Magick on cpanmetadb ...
--> Working on Image::Magick
Fetching http://www.cpan.org/authors/id/J/JC/JCRISTY/PerlMagick-6.86.tar.gz
-> OK
Unpacking PerlMagick-6.86.tar.gz
Entering PerlMagick-6.86
META.yml/json not found. Creating skelton for it.
Configuring PerlMagick-6.86
Running Makefile.PL
################################### WARNING! ###################################
# It seems that you are trying to install Perl::Magick on a MS Windows box with
# perl + gcc compiler (e.g. strawberry perl), however we cannot find ImageMagick
# binaries installed on your system.
#
# Please check the following prerequisites:
#
# 1) You need to have installed ImageMagick Windows binaries from
# http://www.imagemagick.org/script/binary-releases.php#windows
#
# 2) We only support dynamic (DLL) ImageMagick binaries
# note: it is not possible to mix 32/64-bit binaries of perl and ImageMagick
#
# 3) During installation select that you want to install ImageMagick's
# development files (libraries+headers)
#
# 4) You also need to have ImageMagick's directory in your PATH
# note: we are checking the presence of convert.exe and/or identify.exe tools
#
# 5) You might need Visual C++ Redistributable Package installed on your system
# see instructions on ImageMagick's Binary Release webpage
#
# We are gonna continue, but chances for successful build are very low!
################################################################################
Checking if your kit is complete...
Looks good
Note (probably harmless): No library found for -lMagickCore-6.Q16
Writing Makefile for Image::Magick
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.62)
Building and testing Image-Magick-6.86
cp Magick.pm blib\lib\Image\Magick.pm
AutoSplitting blib\lib\Image\Magick.pm (blib\lib\auto\Image\Magick)
C:\Dwimperl\perl\bin\perl.exe C:\Dwimperl\perl\lib\ExtUtils\xsubpp -typemap C:\Dwimperl\perl\lib\ExtUtils\typemap -typemap typemap Magick.xs > Magick.xsc && C:\Dwimperl\perl\bin\perl.exe -MExtUtils::Command -e mv -- Magick.xsc Magick.c
gcc -c -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"6.86\" -DXS_VERSION=\"6.86\" "-IC:\Dwimperl\perl\lib\CORE" -D_LARGE_FILES=1 -DHAVE_CONFIG_H Magick.c
Magick.xs:60:31: error: magick/MagickCore.h: No such file or directory
Magick.xs:167: error: expected specifier-qualifier-list before 'MagickRealType'
Magick.xs:188: error: expected specifier-qualifier-list before 'ImageInfo'
Magick.xs:210: error: 'MagickNoiseOptions' undeclared here (not in a function)
however we cannot find ImageMagick binaries installed on your system.
Is ImageMagick is in your path, as recommanded in the 4) point? Open cmd.exe and type convert -v or convert.exe -v. If you don't see informations about Image Magick (Windows have a built-in convert command), it is very likely you have to add it to your path.
You also have to check points 1), 3), and 5). After that try again to run installation process through cpanm.
Trying to install for Citrus Perl, I discovered on debugging through the Perl part of the install that the mingw64 install had not included 'pexports.exe'. Downloading that from https://sourceforge.net/projects/mingw/files/MinGW/Extension/pexports/
and placing it in the mingw64 directory was necessary to solve the problem of a long list of library export symbols not found.
Prior to that I had also set the environment variables CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH to point to the "include" directory of the ImageMagick install include directory in C:\Program Files (x86). (When you install ImageMagick you should check the box to install also for Strawberry Perl.)
I am trying to build the OpenCV samples which come with the source package and I get the following:
CMake Error at CMakeLists.txt:10 (ocv_check_dependencies):
Unknown CMake command "ocv_check_dependencies".
I did install OpenCV using
cmake .
make
sudo make install
and I got a tutorial snippet working (thus I suppose it is installed correctly as a library). However, compiling the samples does not work.
I guess I have to somehow configure CMake to have “ocv_check_dependencies” - but how? I am lost!
Actually for OpenCV 2.4.4 beta the root CMakeList.txt file says:
OCV_OPTION(BUILD_EXAMPLES "Build all examples"
-DBUILD_EXAMPLES=ON worked just fine for me.
I got it.
In order to build the samples one has to change the default configuration for cmake by providing it via -D. What I did wrong was that I tried to execute cmake from within the samples directory.
The proper way to build the samples is invoking cmake like so (from within the root directory of the unpacked archive):
cmake -DBUILD_SAMPLES .
which will turn samples ON. One can proceed using make, make install than. The samples can be found in bin after building.
See also FAQ
How to compile OpenCV sample code ?
# For OpenCV 3
cd /path/to/opencv/samples/cpp/
#Compile
g++ -ggdb `pkg-config --cflags --libs opencv` facedetect.cpp -o facedetect
#run
./facedetect
Works for me.
googled from this link
mydragonisland's build instructions almost worked for me; with a minor reordering and including accents:
g++ facedetect.cpp -o facedetect `pkg-config --libs opencv`
The macro 'ocv_check_dependencies' is defined in: your_path_to/opencv/cmake/OpenCVModule.cmake
# ensures that all passed modules are available
# sets OCV_DEPENDENCIES_FOUND variable to TRUE/FALSE
macro(ocv_check_dependencies)
set(OCV_DEPENDENCIES_FOUND TRUE)
foreach(d ${ARGN})
if(d MATCHES "^opencv_[^ ]+$" AND NOT HAVE_${d})
set(OCV_DEPENDENCIES_FOUND FALSE)
break()
endif()
endforeach()
endmacro()
The top level CMakeLists.txt contains 'include' commands for files from opencv/cmake/ . Which is why the macro is available when you compile by calling cmake from the root of the opencv sources.
Reason
error message context:
CMake Error at CMakeLists.txt:10 (ocv_check_dependencies):
Unknown CMake command "ocv_check_dependencies".
This error message happens because cmake can't find the definition of ocv_check_dependencies
That's why the console said Unknown CMake command
Solution
If cmake cannot find where ocv_check_dependencies is defined
Just like #Nick Hockings Said:
ocv_check_dependencies is a macro defined in Your/OpenCV/path/OpenCVModule.cmake
macro(ocv_check_dependencies)
set(OCV_DEPENDENCIES_FOUND TRUE)
foreach(d ${ARGN})
if(d MATCHES "^opencv_[^ ]+$" AND NOT HAVE_${d})
set(OCV_DEPENDENCIES_FOUND FALSE)
break()
endif()
endforeach()
endmacro()
The fastest way is to copy this snippet above to your CMakeList.txt file right above where ocv_check_dependencies is
Therefore, cmake can finally understand what it is
That should do the trick, i hope no one else will bother with this question in the future
I got similar errors. My approach is as following:
1) cd xxx/samples 2) mkdir build 3) cd build 4) cmake .. 5) make
Now it works. We could not build individual project under their source files.
Following steps works for me.
Export toolchain path.
cd opencv-3.3.0/samples
cross_cmake &&
cross_make
cd opencv-3.3.0/samples/cpp/
When I try to build Assimp by running build_ios.sh, it tells me:
CMake Error: your C compiler: "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-gcc" was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name.
CMake Error: your CXX compiler: "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-g++" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
What I need the path to be is:
/Applications/XCode.app/Contents/Developer/Platforms/...
I've tried changing DEVROOT in build_ios.sh and IPHONE_xxxx_TOOLCHAIN.cmake, because that's what CMAKE_C_COMPILER etc seem to get generated from, but it still gives me the same errors.
Option 1:
You can set CMake variables at command line like this:
cmake -D CMAKE_C_COMPILER="/path/to/your/c/compiler/executable" -D CMAKE_CXX_COMPILER "/path/to/your/cpp/compiler/executable" /path/to/directory/containing/CMakeLists.txt
See this to learn how to create a CMake cache entry.
Option 2:
In your shell script build_ios.sh you can set environment variables CC and CXX to point to your C and C++ compiler executable respectively, example:
export CC=/path/to/your/c/compiler/executable
export CXX=/path/to/your/cpp/compiler/executable
cmake /path/to/directory/containing/CMakeLists.txt
Option 3:
Edit the CMakeLists.txt file of "Assimp": Add these lines at the top (must be added before you use project() or enable_language() command)
set(CMAKE_C_COMPILER "/path/to/your/c/compiler/executable")
set(CMAKE_CXX_COMPILER "/path/to/your/cpp/compiler/executable")
See this to learn how to use set command in CMake. Also this is a useful resource for understanding use of some of the common CMake variables.
Here is the relevant entry from the official FAQ: https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-do-i-use-a-different-compiler
The cc and cxx is located inside /Applications/Xcode.app. This should find the right paths
export CXX=`xcrun -find c++`
export CC=`xcrun -find cc`
SOLUTIONS
Sometimes the project is created before installing g++. So install g++ first and then recreate your project. This worked for me.
Paste the following line in CMakeCache.txt:
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++
Note the path to g++ depends on OS. I have used my fedora path obtained using which g++
I've been using sbox with a Make-based codebase with no problems. Now
I'm using a scons-based codebase, and am getting some odd problems.
It seems that within scratchbox, scons can't find g++. For example, it
attempts to execute things like:
o hello hello.c
When it should be doing:
g++ -o hello hello.c
So presumably its g++ string variable is empty. g++ is present and in
the PATH - "which g++" produces /scratchbox/compilers/bin/g++.
The same source builds fine outside of scratchbox, so it shouldn't be
a problem with scons or the codebase. There are no special environment
variables set outside of scratchbox when it works.
If I symbolically link /usr/bin/g++ to /scratchbox/compilers/bin/g++,
it gets a bit further (produces the correct-looking g++ commands) but
then upon executing them produces:
sb_gcc_wrapper (g++):
/scratchbox/compilers/arm-linux-cs2007q3-51sb3/bin/sbox-arm-none-linux-gnueabi-g++:
No such file or directory
The file listed is present.
PATH contains /scratchbox/compilers/bin, SBOX_REDIRECT_FROM_DIRS contains /usr/bin and SBOX_REDIRECT_TO_DIRS contains /scratchbox/compilers/bin, so I think it should be able to find it.
Any suggestions would be appreciated!
Thanks,
Ray
Edit: Perhaps related - it also can't find pkg-config unless I prepend the full path within the scons file
scons does not propagate the PATH environment variable, so testing e.g. 'which g++' doesn't help much.
Either set the compilers directly, e.g.
env['CXX'] = '/scratchbox/compilers/bin/g++'
Build your own explicit PATH
path = ['/scratchbox/compilers/bin/','/bin', '/usr/bin', '/sbin','/usr/sbin']
env = Environment(ENV = {'PATH' : path})
Or use the PATH env variable from your shell
import os
env = Environment(ENV = {'PATH' : os.environ['PATH']})