I am attempting to build an application using g++ that is composed of several source files and also uses OpenCV 3.1.0.
The CMD command is:
g++ -o home_surveillance -static -std=c++11 -m64 -IC:\Tools\OpenCV\opencv\build\include -LC:\Tools\OpenCV\opencv\build\x64\vc14\lib -lopencv_world310 configuration_manager.cpp events.cpp image_processor.cpp main.cpp response_module.cpp scheduler.cpp
The error produced is:
C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopencv_world310
collect2.exe: error: ld returned 1 exit status
I have been trying various things and searching for answers for a couple days now. I should note that the application builds properly in Visual Studio 2015. I have tried compiling the source files using g++ with the -c option and they all seem to compile fine. It is just the linking phase that produces an error.
Things I have tried:
Just about every possible combination of the specified command. (Modifying order of the options, -lopencv_world310.a, -lopencv_world310.lib, -lopencv_world310, -l"full_path"+"opencv_world310", etc..)
Checked that all the paths and filenames are correct.
Reinstalled mingw to make sure I was using mingw-w64 since this is a 64-bit application.
Running CMD as admin thinking maybe CMD could not access the path specified with -L option.
Googling and reading every post I could find. (Most posts about "ld.exe cannot find "library_name" are a result of someone using "library_name".a or "library_name".lib as input to the -l option).
Reading mingw documentation on the use of GCC/g++ to ensure I wasn't missing anything obvious.
Praying to Bjarne Stroustrup.
Ritual sacrifice involving a Pentium 2.
Related
I am geetting this error while compiling the 010-TestCase.cpp file which is in examples in catch2. I am very new to this framework. Please respond if anyone have opinion about this.Cat
This seems to be issue when using examples with single-header distribution of Catch2 as an opposite to CMake installation.
What did the trick for me was removing offending -I$(CATCH_SINGLE_INCLUDE) from the example command. It didn't appear in Google Search but I expect it to contain path to which I do include barely as "catch2.hpp".
Test works for me after I've eended up with:
g++ -std=c++11 -Wall -o 010-TestCase 010-TestCase.cpp && ./010-TestCase --success
I'm trying to compile CMake using a non-default GCC installed in /usr/local/gcc530, on Solaris 2.11.
I have LD_LIBRARY_PATH=/usr/local/gcc530/lib/sparcv9
Bootstrap proceeds fine, bootstrapped cmake successfully compiles various object files, but when it tries to link the real cmake (and other executables), I get pages of "undefined reference" errors to various standard library functions, because, as running the link command manually with -Wl,-verbose shows, the linker links with /usr/lib/64/libstdc++.so of the system default, much older GCC.
This is because apparently CMake tries to find curses/ncurses libraries (even if I tell it BUILD_CursesDialog:BOOL=OFF), finds them in /usr/lib/64, and adds -L/usr/lib/64 to build/Source/CMakeFiles/cmake.dir/link.txt, which causes the linker to use libstdc++.so from there, and not my actual GCC's own.
I found a workaround: I can get the path to proper libraries from $CC -m64 -print-file-name=libstdc++.so then put it with -L into LDFLAGS when running ./configure, and all works well then.
Is there a less hacky way? It's really weird that I can't tell GCC to prioritize its own libraries.
Also, is there some way to have CMake explain where different parts of a resulting command line came from?
So I have installed / compiled speech_tools, and Festival (2.3) using Cygwin on my Win8.1 machine to the point that I can successfully produce speech using this command:
echo "hello world" | \src\main\festival --tts
The next step is for me to get FestVox running. I have downloaded FestVox 2.6 and I have run ./configure; however, the 'make' step is giving me trouble, producing this error:
gcc -O3 -Wall -o phonealign phonealign_main.o -LC:/cygwin64/Festival/build
/speech_tools/lib -lestools -lestbase -leststring -lncurses -lstdc++ -lm -lwinmm -luser32
/usr/bin/ld: cannot find -leststring
collect2: error: ld returned 1 exit status
Makefile:80: recipe for target 'phonealign' failed
So, I looked at my Makefile at where it might be trying to look for this file, and it looks like in that directory (build\speech_tools\lib) I am missing a libeststring.a partner for my libeststring.lib. Both libestbase and libestools have .lib and .a files in that directory.
At what step did I go wrong?? Should a libeststring.a have been created at some point??? When? How can I fix this?
I think the problem is that you should use compiler in Windows instead of gcc within Cygwin. The role in Cygwin for building Festival is to run configure to generate a Makefile for VC. Then run nmake in Windows command line not make within Cygwin.
Cygwin cannot build a native Windows application like what MINGW does. Application build in Cygwin can only run within Cygwin.
*.a is the static library for Linux, which is built by gcc. *.lib is the static library for Windows, which is built by VC.
So I suggest you taking a look at README, INSTALL files in FestVox. To find whether there is description for make a Makefile for Windows like process "3. Make makefile for VC in Cygwin" in my document (http://www.eguidedog.net/doc_build_win_festival.php)
Cameron
Following the guide over at http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-2-get-started/get-started/ and I got down to the part where you set up GLFW. Everything was going fine got CMake all installed properly and it went through the process just as shown on the images on the site. Everything installed fine to the /usr/local/include and /usr/local/lib folders. So the next thing to do is test that it installed fine and every time I try to do anything with whats in the glfw folder, gives me this error:
fatal error: 'GLFW/glfw3.h' file not found
These are the commands I've tried to run it with:
gcc boing.c -o boing
gcc -lglfw boing.c -o boing
gcc -lglfw3 boing.c -o boing
gcc -I/usr/local/include boing.c -o boing (different error)
The last one almost worked and gave several different errors, which I think may have been caused by something else. That's kind of besides the point though. What am I doing wrong here? To my knowledge gcc is meant to look in the /usr/local/include folder by default for libraries.
I am trying to compile a project that required freetype library so I was figuring out how to install freetype to mingw32 and the more safer way is to compile it.
Anyway the problem was compiling freetype-2.4.11
I went into bash provided in msys
I did ./configure within freetype's main dir and everything looks fine
next I did mingw32-make which created the problem
libtool: compile: gcc -pedantic -ansi -Ig:/Downloads/freetype-2.4.11/objs -I./b
uilds/unix -Ig:/Downloads/freetype-2.4.11/include -c -Wall -g -O2 "-DFT_CONFIG_C
ONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" g
:/Downloads/freetype-2.4.11/src/base/ftsystem.c -DDLL_EXPORT -DPIC -o g:/Downlo
ads/freetype-2.4.11/objs/.libs/ftsystem.o
Assembler messages:
Fatal error: can't create g:/Downloads/freetype-2.4.11/objs/.libs/ftsystem.o: No
such file or directory
g:/Downloads/freetype-2.4.11/builds/freetype.mk:198: recipe for target 'g:/Downl
oads/freetype-2.4.11/objs/ftsystem.lo' failed
mingw32-make[4]: *** [g:/Downloads/freetype-2.4.11/objs/ftsystem.lo] Error 1
g:/Downloads/freetype-2.4.11/objs/.libs/ftsystem.o seemed like it is trying to use a directory that is illegal in windows.
Thanks in advance
Try to use make instead (i.e. the one from MSYS distribution), and avoid using mingw32-make (from MinGW distribution) in the future to save yourself time and nerves. Extract from MinGW Wiki:
What's the difference between make and mingw32-make?
The "native" (i.e.: MSVCRT dependent) port of make is lacking in some functionality and has modified functionality due to the lack of POSIX on Win32. There also exists a version of make in the MSYS distribution that is dependent on the MSYS runtime. This port operates more as make was intended to operate and gives less headaches during execution. Based on this, the MinGW developers/maintainers/packagers decided it would be best to rename the native version so that both the "native" version and the MSYS version could be present at the same time without file name collision.