mingw-w64-v2.0.6.tar.gz - define environment variables path - c++

I download the latest version of minGW - mingw-w64-v2.0.6.tar.gz . Then I extract in into C:\MinGW . As I saw in some articles, now I have to define the path under environment variables .
In C:\MinGW now have -
I tried to set the variable value of path as C:\MinGW , but when I do in eclipse juno build path for some project I get -
make all
Cannot run program "make": Launching failed
Error: Program "make" not found in PATH
EDIT:
I downloaded GCC+binutils 64-bit ,exctract to c:\mingw64 , change the path to c:\mingw64\bin and changed the build command to mingw32-make.
Now when I build the project I get error -
mingw32-make all
mingw32-make: *** No rule to make target `all'. Stop.
2nd EDIT :
finally I succeeded to run a project by chose -
Note that it must uncheck the show project type and toolchians only if they are supported on the platform otherwise it not let to chose Executable Project type . In addition the build command should be stay on "Use default build command" .

You downloaded the source package.
You need a toolchain (GCC+binutils and maybe make/gdb). Those are located here:
32-bit
64-bit
I recommend my (rubenvb) Personal builds. They are tidy, full-featured and up to date.
After extracting the toolchain anywhere (say, D:\), add D:\mingw64\bin or D:\mingw32\bin to PATH. Or double-click on the batch scripts I include with my latest builds and it'll be done for you.
Note that you'll need to set up Eclipse for MinGW compilation, which means using mingw32-make, not make.
Lastly, I also suggest using MinGW-w64's support channels (forum and mailing list; please subscribe before posting to mingw-w64-public) in the future. I linger there, among other generally nice and helpful people.

Related

Why can I use CMake supplied modules (CMakeDependentOption.cmake specifically) locally, but not on CI or Docker?

I have a cmake project that successfully builds locally but errors with
include could not find load file:
CmakeDependentOption
when trying to build on a CI platform or in Docker. Note that CMakeDependentOption.cmake is a script that comes with cmake itself. So it should just be available. On CI to install cmake, I wget the relevant cmake release from their downloads page, unzip it and add the bin directory to the PATH environment variable. Then I use the cmake command to build my library. The result is the above error.
I suspect this means that a CMake variable (such as "CMAKE_MODULE_PATH" but not, since this variable seems to be empty at the start of the cmake script) is messed up or not set somehow. The path to the correct file to include is
<cmake_root>/share/cmake-3.18/Modules/CMakeDependentOption.cmake
And I have verified that it exists manually. My question: is there a way to locate this directory from within cmake? Perhaps a cmake --config or cmake --libs mode (a bit like pkg-config?)
Failing that, does anybody have any suggestions as to why this is happening and how to get around it.
You can locally because most likely you don't use a linux based platform, like windows or mac. This is because linux filesystem are case sensitive. Which means CmakeDependentOption is different from CMakeDependentOption.
Docker runs containers in linux, so filenames are gonna be case sensitive, and the include is going to fail if the cases are different.

Export Eclipse Compiler to cmd

I try to compile an eclipse-project written in c++ which is building a .so-File. Now i try to build the project without an IDE. I tried it with MinGW but the created .so doesn't work. I think there are used some special packages but how can I get the information's.
Is there a way to Export the build settings and import them into MinGW?
How can i else set the compiler?
This is the ToolChainEditor which i would recreat in MinGW.
You can't import a configuration into mingw, but you can tell mingw where to find a configuration of sorts.
Eclipse can be configured to generate a makefile (At least as recent as Neon). Select your project and use the main menu to navigate Project->Properties->C/C++ Build->Tool Chain Editor. Set the "Current builder" to Gnu Make Builder and build the project.
In the generated folder where you would find the finished executable you will find three more files: makefile, objects.mk and sources.mk and can use the make utility that often comes with mingw. It can also be downloaded separately if you have to.
From the command line, enter the folder and type make. Magic will happen. If you want to know more about the magic, make is a very deep topic well worth learning, even if only as a gateway drug to more modern build systems that descended from it.

Using scons to compile C++ code under windows, scons adds "/Fo" as compile option

Using the following:
Python version 2.7.13, Scons version 2.5.1, Visual Studio 2012 express is installed, but I am not planning to use it.
Code blocks and MinGW-W64-builds-4.3 are installed.
Using Scons to compile C++ code (networkit toolkit) under windows. Scons adds "/Fo" as compile option. This option works only with VC++ and not with MinGW which I am trying to use. Why does Scons add this flag? I have checked my Sconstruct and the reference build.conf files and cannot seem to find this flag getting set explicitly.
My Sconstruct file is here(http://www103.zippyshare.com/v/jSrMapGz/file.html) and the build.conf file is here (http://www11.zippyshare.com/v/aXGQA5b5/file.html).
I want to get the compilation done with "-o" flag for g++, which is the equivalent of /Fo flag for VC++. I just cant figure out where Scons is picking this flag from :(
I am a novice with python and scons. I typically use VC++ 2012 but have to use networkit toolkit for a project, but it uses C11 features. And I cannot update to VC++ 2015/2017 yet.
Thanks for your help!
I checked your SConstruct file, and you are initialising your build environment as
env = Environment()
, which leaves the environment variable "tools" set to its standard value "default". The latter setting means: let SCons figure out which tools/compilers are installed in the current system, and add corresponding Builders to the build environment automatically. Under Windows, SCons will prefer "vc" over "mingw"...this is hardcoded at the moment (we're working on changing this for future versions of the core source).
What you can do, since you know that you have a "mingw" compiler installed that you want to use explicitly, is to tell SCons that you want to work with "mingw" only.
The following example from the page https://bitbucket.org/scons/scons/wiki/SconstructShortMingwWin32 shows the basic recipe for this:
import os
#don't use the default environment
DefaultEnvironment(tools=[])
#create an environment that uses mingw tools
env = Environment(ENV=os.environ, tools=['mingw'])
#the target will be myprogram.exe (in win32)
#the source files will be every file in the
#current directory that matches "*.cpp"
env.Program(target='myprogram', source = Glob('*.cpp'))
For further help and as reference, please consider checking out our User Guide and Man page.

Where is the lib folder (or its replacement) in the current OpenCV?

I'm following a book written for the older version of OpenCV (OpenCV 2 Computer Vision, by PACT) and it tells me to include the lib folder in my Visual Studio 2013 Property Manager when creating a new property sheet.
I don't see a directory called lib in the current GitHub version (opencv-master, which is OpenCV 3.1.x). Has this folder been replaced by something else?
I built OpenCV with cmake. I found a 4 year old unanswered question wherein someone was also looking for this folder. They tried building the library from another directory that no longer exists, but that didn't work for them anyway...
Another OpenCV user just told me that GitHub doesn't include the libraries, so you have to cmake them locally. I'm still not clear on where / how I can cmake them.
I realize the pre-built binaries have this, but I'm avoiding them because I need the SURF functions in opencv_contrib, so I needed to build it from source.
The pre-built binaries will have a library folder in the corresponding path
Local System Path(Opencv Folder)-> build->x64/x86->vc10/vc11/vc12->lib.
As you mentioned that you don't wish to use it then the only option left for you is to build it locally which is a much better option if you plan to use Opencv libraries for varied functions and projects as it resolves many build errors that you might face later.
I used the Cmake Graphical user interface to build opencv, following are the steps I followed to successfully build the libraries on my system .
So, you would need to create a new folder that will contain all
the Makefiles generated.
Please refer to this image for clearer understanding:
In GUI you define source directory path where OpenCVConfig.cmake is present, according to your image it's the
current folder in your image opencv-master.
Similarly, define the path to the new directory you created where all the build files would be stored.
Make sure to uncheck Build_Examples to avoid configuration errors.
Then click Configure at the bottom when configuring is done .(you may need to configure it twice)
After click the tab adjacent to configure, Generate to create the solution file.It will ask you for the compiler name
select the
compiler installed on your system from the list of choices. After
generation is done.
Go to this path Build_New_Directory(the directory you created) you will find OpenCV.sln build this project, it will take around 10-15 minutes depending on your processor, wait patiently .If you get a build error at this point don't invest your time in debugging on Visual Studio go back to Cmake GUi and configure it again and this time give the path to dependent libraries on your system that it could not find .Repeat the process it should be successfully build now.
After it is successfully build you can now locate the path of all opencv libraries build on your system as follows.
Build_New_Directory(the directory you created)->
install->x64->vc10(compiler I used)->lib.
As an update to Nikita's awnser:
There is a cmake build bug where the x64 folder will not be created if OpenCV_RUNTIME is not set. This will happen if you build an old OpenCV (e.g. <= 3.2.0) with a newer Visual Studio Version than was available at that time (e.g. Visual Studio 2017)
To fix this, add the correct MSVC_VERSION elseif-cases in both ./cmake/OpenCVDetectCXXCompiler.cmake and the ./cmake/templates/OpenCVConfig.root-WIN32.cmake.in (or ./cmake/OpenCVConfig.cmake in < v3.2.0) files:
[...]
elseif(MSVC_VERSION EQUAL 1900)
set(OpenCV_RUNTIME vc14)
# old version ends here with endif()
elseif(MSVC_VERSION GREATER 1909 AND MSVC_VERSION LESS 1920)
set(OpenCV_RUNTIME vc15)
elseif(MSVC_VERSION GREATER 1919 AND MSVC_VERSION LESS 1930)
set(OpenCV_RUNTIME vc16)
endif()
[...]

Netbeans project imported from existing cmake application fails to build with filesystem error on Windows

I am attempting to import a manually-created cmake project that I had been using in a different IDE into Netbeans 8.0.2 on Windows 7. Needless to say, my cmake configuration worked fine there.
Netbeans seems to import the directory fine. I imported it in "automatic" (cmake) mode. However, when I attempt to build the project, I get a rather cryptic (Java?) error message:
Makefile:76: recipe for target 'all' failed
process_begin: CreateProcess(NULL, /C/MinGW/bin/make.exe -f CMakeFiles/Makefile2 all, ...) failed.
make (e=2): The system cannot find the file specified.
Knowing very little about Java, I am not sure how to interpret this error. The first directory (/C/MinGW/bin/make.exe) stands out to me as not being in Windows-format, but I am not sure if that's incorrect. I do indeed have a file by that name, as I copied the longer-named mingw make binary so I would only need to type "make".
Presuming this is being run in the project root, and that the first directory is formatted correctly, I don't see any problem with finding these files.
My CMakeLists.txt is:
cmake_minimum_required(VERSION 2.8.4)
set(Project_Name "Test")
set(Test_VERSION_MAJOR 1)
set(Test_VERSION_MINOR 0)
project(${Project_Name})
include_directories(
"${CMAKE_CURRENT_SOURCE_DIR}/inc"
"${CMAKE_CURRENT_SOURCE_DIR}/inc/SDL"
"C:/Users/Bakaiya/Documents/ogre/OgreMain/include"
)
file(GLOB SOURCE_FILES "${CMAKE_CURRENT_SOURCE_DIR}/src/*.cpp")
link_directories(${CMAKE_CURRENT_SOURCE_DIR} ${OPENGL_LIBRARIES})
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_executable(${Project_Name} ${SOURCE_FILES})
target_link_libraries(${Project_Name} SDL2main SDL2 OgreMain) #Ogre
Running the "generate makefile" command in the IDE completes without issue, but does not fix the problem. Additionally, clean fails, but "help" does work.
This is a problem within the IDE, it seems, because if I run make from the command line in the project root, it builds without issue.
Also, I fiddled with the file path mode setting under C/C++ -> Project Options, and it did nothing. Even set to absolute, what seems to be a relative path (CMakeFiles/Makefile2) is still in the failed command. I'm not sure if that option is expected to change that sort of reference or not.
What could be wrong with this imported project to cause this issue?
However, when I attempt to build the project, I get a rather cryptic (Java?) error message:
This is an error shown by netbeans to tell you, that it was unable to execute make command successfully. Usually this indicates a wrong setting of your (mingw-) tools.
Here are some points you can check:
Don't use make from mingw/bin, you have to use the one from mingw/msys/... There's a mingw make within mingw's msys folder, usually C:\<Path to MSYS>\<Version>\bin\make.exe - this bin-path must also be set in PATH environment variable! If MSys wasn't installed with your mingw installation, please install it.
Please check the tools set in Tools -> Options -> C/C++ -> Build Tools; you can test them by clicking Versions....
(If existing) Clean the CMake generated files and clean the cmake's cache. If not done yet, please use an out-of-source build as described here.
Can you build your project from terminal (without netbeans)?
The first directory (/C/MinGW/bin/make.exe) stands out to me as not being in Windows-format, but I am not sure if that's incorrect.
This is ok and intended by mingw - it uses linux / unix like paths.
Update
Which make program should I use?
Many MinGW users have a problem because they use mingw32-make.exe from
the MinGW installation. While this seems like the right choice, it
actually breaks the build. The problem is that this is a non-Posix
implementation of the Unix make program and doesn't work well at all.
In fact, thats why the MinGW people renamed it! They've also made a
FAQ entry explaining why you should not use mingw32-make.exe. Instead,
you should use the make.exe program from the MSYS package.
As of NetBeans 6.1, the Build Tools panel no longer allows a user to
select mingw32-make. If you choose a MinGW compiler collection it will
default to make in MSYS. If MSYS is not found, it will tell you no
make program has been found.
(http://wiki.netbeans.org/MinGWInCCDevelopmentPack)