Most of my team uses a .bat file to set paths and then run a build. The .bat file allows selection of multiple different compiler/target platforms, but all use some version of GCC/G++ or similar compiler.
I created an Eclipse project that simply uses the .bat file rather than re-inventing the wheel and tracking down all the paths needed for each build (which I'd need to update if anyone ever updated the .bat file anyway).
This works great for building, and I can even see compiler errors/warnings, but there are some extra errors always present:
Program "gcc" not found in PATH
Program "g++" not found in PATH
I've seen many questions about these and similar errors, but in those case the user couldn't build, and the solution was to install the tools and/or update their PATH or Eclipse environment settings. I don't want to do that; all the tools I need are installed, and the .bat file works just fine to set the PATH for building. Is there a way to suppress these errors, or have Eclipse not try to find the compiler executable, since the build succeeds anyway?
Edit: As suggested in the answer I've received so far, here is output on the console after putting a full path to a compiler in the global discovery settings, which isn't exactly my favorite solution even if it worked, but I'll probably deal with it. Regardless the errors don't go away:
15:27:24 **** Running scanner discovery: CDT GCC Built-in Compiler Settings MinGW ****
"C:\\redacted\\localapps\\MinGW5\\bin\\g++.exe" -E -P -v -dD C:/Project_Files/redacted/code_workspaces/redacted/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Reading specs from C:/redacted/localapps/MinGW5/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
C:/redacted/localapps/MinGW5/bin/../libexec/gcc/mingw32/3.4.2/cc1plus.exe -E -quiet -v -P -iprefix C:\redacted\localapps\MinGW5\bin\../lib/gcc/mingw32/3.4.2/ C:/Project_Files/redacted/code_workspaces/redacted/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C -dD
ignoring nonexistent directory "C:/redacted/localapps/MinGW5/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/include"
#define __cplusplus 1
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/../../../include/c++/3.4.2"
#define __STDC_HOSTED__ 1
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/../../../include/c++/3.4.2/mingw32"
#define __GNUC__ 3
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/../../../include/c++/3.4.2/backward"
...
And then a bunch of #defines
The command string I used in the discovery options for this output was C:\redacted\localapps\MinGW5\bin\${COMMAND}.exe ${FLAGS} -E -P -v -dD "${INPUTS}".
Based on the information provided, these errors are coming from the scanner discovery part of CDT.
On my machine the full error looks like this:
Description Location Type
Program "g++" not found in PATH Preferences, C++/Build/Settings/Discovery, [CDT GCC Built-in Compiler Settings MinGW] options C/C++ Scanner Discovery Problem
Program "gcc" not found in PATH Preferences, C++/Build/Settings/Discovery, [CDT GCC Built-in Compiler Settings MinGW] options C/C++ Scanner Discovery Problem
Or as a screenshot
What is going on here is Eclipse CDT is (attempting to) launch GCC and G++ to find out what the global settings are for things like include paths, etc.
To fix the problem, go to the Location specified in the error message and adjust the scanner settings. Here is the matching setting to go with the specific error I received.
Your error might be in the project or in the global settings.
To update the MinGW setting, you can provide the path to a batch file that looks like GCC/G++ but sets up your environment correctly first, or you can point directly at the GCC that Eclipse CDT did not find on its own.
For example you can have:
D:\path\to\my\compilers\${COMMAND}.exe ${FLAGS} -E -P -v -dD "${INPUTS}"
As the setting instead of the default.
To aid the debugging, check the Allocate console in the Console View to see exactly what is being run and what output is being generated.
And here is what you might see when it does not work. Hopefully the error messages in the console are sufficient to resolve the problem on your machine.
21:12:54 **** Running scanner discovery: CDT GCC Built-in Compiler Settings MinGW ****
"D:\\path\\to\\my\\compilers\\g++.exe" -E -P -v -dD C:/Temp/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Cannot run program "D:\path\to\my\compilers\g++.exe": Launching failed
Error: Program "D:\path\to\my\compilers\g++.exe" not found in PATH
PATH=[\bin;\bin; -- snip --]
21:12:54 Build Finished (took 37ms)
Here is a screenshot to match:
If it does work, you should see lots of #defines and the like showing the global state of your compiler.
Related
I've downloaded the binaries: or-tools_VisualStudio2022-64bit_v9.3.10497
I'm using vs2022 on win10. My shell has cygwin in the path if it's related.
I ran
%comspec% /k "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat"
cl.exe is in the path, and which.exe finds it.
I ran make test_cc, but it complained
the cl command was not found in your PATH
exit 127
make: *** [Makefile:271: test_cc] Error 127
The var CXX_BIN was empty even though which cl returned the correct path. I set it manually to cl.
Then, there was a complaint about echo and a newline, which I commented out. Then, it couldn't find md, so I created manually md objs.
A few of the examples were built, but then it stopped with another error. For now, I just got what I want:
make run SOURCE=examples/cpp/solve.cc
but probably there was an easier way to get it?
I tried to build it from the source using cmake. Doesn't work off-the-shelf as well:
Build abseil-cpp: OFF
...
CMake Error at C:/prj-external-libs/vcpkg/scripts/buildsystems/vcpkg.cmake:824 (_find_package):
By not providing "Findabsl.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "absl", but
CMake did not find one.
Could not find a package configuration file provided by "absl" with any of
the following names:
abslConfig.cmake
absl-config.cmake
Add the installation prefix of "absl" to CMAKE_PREFIX_PATH or set
"absl_DIR" to a directory containing one of the above files. If "absl"
provides a separate development package or SDK, be sure it has been
installed.
Call Stack (most recent call first):
cmake/deps.cmake:33 (find_package)
CMakeLists.txt:304 (include)
If finds gurobi95.dll, but it can't find the function GRBtunemodeladv.
On failure, solve.exe crashes with (unknown) names in the stack trace. Need to add debug symbols and graceful error handling.
cmake looks more promising, and I was missing dependencies. Should give it a flag -DBUILD_DEPS:BOOL=ON.
OR-Tools depends on few external dependencies so CMake build will try to find them using the idiomatic find_package() => your distro/env(vcpkg ?) must provide them, just regular CMake stuff here.
ref: https://cmake.org/cmake/help/latest/command/find_package.html
note: we provide few findFoo.cmake here https://github.com/google/or-tools/tree/main/cmake
We also provide a meta option to build statically all our dependencies, simply pass -DBUILD_DEPS=ON cmake option at configure time.
You can also build only some of them, please take a look at
https://github.com/google/or-tools/tree/main/cmake#dependencies
Concerning Gurobi and GRBtunemodeladv symbol, this one has been removed by last version of Gurobi so we fix it in v9.4/main/stable branch...
see: https://github.com/google/or-tools/commit/d6e0feb8ae96368523deb99fe4318d32e80e8145
My goal has been to create multi-threading programs, and I can not even get a simple thread
to execute ON ECLIPSE CDT. my Tools:
ECLIPSE 3.8.1 CDT
Ubuntu 13.10
I have noticed very similar issues regarding mine. I have tried those other solutions but I could not get them to work for me.
When I type the code in Eclipse CDT, Eclipse does not 'resolve' the symbols 'thread', however, It can find the header file 'thread'. 'Mutex' also does not resolve. Furthermore, after building, I run the program, eclipse returns :
"terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted"
Some additional notes:
I can compile and execute the code in the terminal using:
'clang++ c.cpp -pthread -std=c++11'
but...
'g++ c.cpp -pthread -std=c++11' compiles and
produces the same error as quoted above. So it looks like it's a compiler issue. I did
start to write the code in a new project within Eclipse CDT with the clang++ compiler and now that gives the same non-resolved 'thread' and produces the error as quoted above. So now I think I have some wrong settings, paths or flags set in Eclipse.
include <iostream>
include <thread>
using namespace std;
void p1(){
cout<<"process 1 is processing"<<endl;
}
int main() {
thread t1(&p1);
cout<<"Hello from main()"<<endl;
t1.join();
return 0;
}
I have been struggling with the very same issue and I finally resolved it. Here is what I did:
1) Add -std=c++11 for c++ build. To do that right-click your project, select properties and then: C/C++ Build -> Settings -> GCC C++ Compiler -> Miscellaneous(last option)
In other flags append -std=c++11. My Other flags now looks like: -c -fmessage-length=0 -std=c++11 but yours may be a bit different.
2) Add some linker options. In the same view(C/C++ Build -> Settings) as above select the GCC C++ Linker option and from there go to Miscellaneous(second to last option). Add the following Linker flags(the field was empty for me): -Wl,--no-as-needed -pthread. Hit apply.
3) Add a macro. Again from the project properties menu(project->right click->properties). Navigate to C/C++ General -> Paths and symbols -> Symbols. Select GNU C++. Add a symbol with the name __GXX_EXPERIMENTAL_CXX0X__ and no value. Again hit apply.
4) Navigate to C/C++ General -> Preprocessor Include paths.. Select the providers tab. In this tab leave only the following two options checked: CDT GCC Built-in Compiler Settings and CDT Managed Build Setting Entries. Select CDT GCC Built-in Compiler Settings uncheck the checkbox Share setting entries between projects(global provider) and now the text box labeled Command to get compiler specs should be enabled. In this text box append the good old -std=c++11. The text now looks like this for me ${COMMAND} -E -P -v -dD ${INPUTS} -std=c++11. Hit apply one last time.
5) Rebuild the index for the project. To do that right click the project->Index->Rebuild
Following these steps I was able to compile a c++11 multithreaded program, execute it and also Eclipse CDT did not report any errors and was helpful with the autocompletion. Unfortunately this setting has to be done separately for Release and Debug(or at least I have not found a way to share it). Hope this helps.
I am running Ubuntu 64bit version, and downloaded the latest 64bit Eclipse.
Installed g++ along with build-essential. Tested g++ to make sure it works from terminal, and it works fine.
alex#ubuntu:~/Desktop$ g++ test.cpp -o test
alex#ubuntu:~/Desktop$ ./test
Hello World!alex#ubuntu:~/Desktop$
However, trying to build simple C++ Hello Word project(one of the default projects that comes with Eclipse), I am getting error.
Description Resource Path Location Type
Program "g++" not found in PATH Preferences, C++/Build/Settings/Discovery, [CDT GCC Builtin Compiler Settings] options C/C++ Scanner Discovery Problem
I have added Environment variable named g++ with value /usr/bin/g++ and the above error went away, however, now I am getting unresolved errors, though project compiles and in the Console shows !!!Hello World!!!
Description Resource Path Location Type
Symbol 'endl' could not be resolved test_hello.cpp /test_hello/src line 13 Semantic Error
Symbol 'cout' could not be resolved test_hello.cpp /test_hello/src line 13 Semantic Error
Symbol 'std' could not be resolved test_hello.cpp /test_hello/src line 10 Semantic Error
Have I correctly entered Environmental variable ?? How can I get fix the "unresolved" error ?? Thanks !
When compiling there are two important things to consider:
1.) Is my path up-to-date with executables?
2.) Is my library path correct?
It appears you satisfy 1.) but not 2.)
The unresolved symbol error means that Eclipse cannot find your library via LD_LIBRARY_PATH or some other medium. It's attempting to locate the standard compiled C++ library.
How did you install g++?
Kindly do this and post the results:
Project > Properties > C/C++ Build > Environment
If everything there appears nominal, you can try
/sbin/ldconfig
which should hopefully re-parse your system library paths and might update your environment.
Something like this:
cmake --get-variable=MY_CMAKE_VARIABLE
The variable may exist in an included CMake file.
If you have an existing cache file, you can do:
grep MY_CMAKE_VARIABLE CMakeCache.txt
If you do not yet have a cache file and you want to see what options there are in a CMakeLists.txt file, you can do (in a different directory since this will write a cache file):
cmake -L /path/to/CMakeLists.txt | grep MY_CMAKE_VARIABLE
which will return to you something like
<VARIABLE>:<TYPE>=<VALUE>
If it is an advanced variable, add the -A flag to the same command and it will include advanced variables. Of course, if you only want the value, you can do:
cmake -L /path/to/CMakeLists.txt | grep MY_CMAKE_VARIABLE | cut -d "=" -f2
EDIT
For example, with a CMakeLists.txt that is:
cmake_minimum_required(VERSION 2.8)
project(test)
include(otherFile.txt)
set(MY_VAR "Testing" CACHE STRING "")
And where otherFile.txt is:
set(MY_OTHER_VAR "Hi" CACHE STRING "")
The command (run from another directory):
cmake -L ../cmaketest
Gives:
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tgallagher/cmaketest-build
-- Cache values
CMAKE_BUILD_TYPE:STRING=
CMAKE_INSTALL_PREFIX:PATH=/usr/local
MY_OTHER_VAR:STRING=Hi
MY_VAR:STRING=Testing
So, it does show variables from other files. It should parse the entire build. The issue though is that it will not show any variables that are not marked with CACHE. And it will not show any that are cached INTERNAL, and will only show ADVANCED if -LA is used instead of -L.
If your variables are marked as INTERNAL or not CACHE'd at all, then there is no method within CMake to pull it out. But, non-CACHE'd variables are meant to be transient, so I'm not sure why you would need them outside of a build environment anyway.
Use:
cmake -LA -N /path/to/project
to get a listing of all cache values. The -N is important; it prevents cmake from trying to generate any build files, and just shows you what's in the cache.
If the variable you want is not something you're setting, but something from the defaults, you can use
cmake --system-information
And grep that. Note it does seem to take a second or two which seems kinda slow.
If for example you're trying to do this to configure your cmake vars in the first place, it avoids getting the cart out in front of the horse. :)
You can also pass this a file name. So you can try only generating it if it doesn't exist, and parse the file if it does (to save that 1-2 seconds).
If you need get non cached user variable but can't edit original cmake script, you may resort to a trick. Create new CMakeLists.txt file in another directory with the following content:
include(<Path to original CMakeLists.txt>)
message(STATUS "MY_VAR={${MY_VAR}}")
It is quite possible, cmake will made a lot of errors while running in new directory. Relative paths, if used in original script, is definitely a cause for such errors. But cmake will print last value assigned for your variable. Further, filter all errors and warnings using any well known text processor (assume UNIX familiar), for example:
cmake . | sed -n 's/-- MY_VAR={\(.*\)}/\1/p' 2>&1
I use this approach in projects maintenance scripts, it is reliably as long as original CMakeLists.txt has no syntax errors.
-D <var>:<type>=<value>:
When cmake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project. This option may be used to specify a setting that takes priority over the project's default value. The option may be repeated for as many cache entries as desired.
This feels silly, but its been 2 days...somewhere after upgrading from Ubuntu 10.04 to 10.11 and from Eclipse Helios to Eclipse Indigo, I got stuck with the following problem:
Problem Description:
I'm trying to use a function in math.h called isinf(), but the problem also occurs with things like isnan(). The program compiles fine on the command line using make and fine in eclipse using build. But if I open the program file in eclipse it reports that it cannot reolve the isinf() function call. If I just insert the program contents into a new project and new source file, the error appears immediately. This problem did not occur under 11.04 with Eclipse Helios CDT
Questions:
Why are these errors only reported when the program file is opened and not on when the program is compiled; why are the errors not detected make is run from the command line? Is there a solution/workaround available?
Version Info
Linux Ubuntu 10.11 64-bit
Eclipse CDT Indigo, Service Release 1, Build id: 20110916-0149
(Also using Eclipse EE Indigo – if that makes a difference)
GNU Make 3.81
gcc 4.6.1-9Ubuntu3
To Duplicate:
Please find the two files you'll need to replicate below:
Step 0. Verify that everything is fine outside of Eclipse
Copy the attached source file and make file
create a directory e.g. Mkdir FunTest
Save the source file a 'Test.cpp' and the makefile as 'makefile'
Open a command prompt and navigate to the directory e.g. FunTest
Enter 'make'
Enter ./TestOut
Program responds “is not infinite”
Step 1. Create the project in Eclipse
Open Eclipse
Select File|New|MakeFile Project with Existing Code
Click Browse – navigate to the directory (FunTest) and click ok
Select 'Linux GCC' from the Toolchain selector
Click Finish
Step 2. Find the Error
Click Build All (Ctrl-B) – project builds without errors
Open the project in the project explorer to display the file in the directory
Double click on the file “Test.cpp”
Note the error icon next to line testing for infinity
Note the 2 error messages:
Semantic error: Function _isinff could not be resolved
Semantic error: Function _isinfl could not be resolved
Test.cpp:
include <math.h>
int main(int argc, char **argv)
{
int TestNum = 10;
if (isinf(TestNum) == 0)
printf("Not infinite\n");
return 0;
}
makefile:
# Specify the compiler
CC = g++
# Specify the compiler flags
CFLAGS += -c
# Specify the files making up the application
SOURCES = Test.cpp
OBJECTS = $(SOURCES:.cpp=.o)
EXECUTABLE = TestOut
all: $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
$(CC) $(LDFLAGS) $(OBJECTS) $(LDLIBS) -o $#
.cpp.o:
$(CC) $(CPPFLAGS) $(CFLAGS) $< -o $#
install:
#echo "Build complete!"
I have experienced similar problems of the CDT reporting errors even though the code compiled fine within Eclipse Indigo.
Project > Properties > Settings > Binary Parsers > "GNU Elf Parser"
helped in my case. I had the "Elf Parser" checked.
That looks like a problem that many others have had with eclipse CDT before. Sometimes shutting eclipse down and then starting it back up again is enough to help. If that isn't the case, take a look at what I have below:
Compilation ok, but eclipse content assist having problems
Check your includes: if you're using include<math.h> change it to include<cmath>. The same for stdio.h and stdlib.h, you should replace by cstdio and cstdlib. Another option may be change you project to a C project instead of a C++.
You are missing -lm option in your build preferences.
Project->Properties->Settings->Miscleanous->Other (linker) flags[]
For me, it was solved by adding a specific ‘Source Location’ folder, and removing the default. In Luna, it is under:
Project > Properties > C/C++ General > Paths and Symbols > Source
Location