I am compiling a .c file with a specified _D option MY_OPT. In the properties -> c++ build -> settings -> gcc c compiler -> symbols I creqated an entry and put MY_OPT in as the value.
When I compile I get error 127 saying that DMY_OPT cannot be found. I learned that error 127 means it realy came from bash and, after a bit of thought, I realized that since the dash is not there (as in -DMY_OPT) bash indeed would report that there is no input file named DMY_OPT to be found.
I searched google and stackoverflow and found lots of similar questions, but can't formulate one with narrow enough search terms to fine any remotely related answer, so I hope someone here can help.
NOTE: I removed the SYMBOL and instead put a -DMY_OPT in the miscellaneous field. No change (or I am getting the Eclipse Juno bug about not deleting previous errors.)
I discovered the answer to this question was the test of the overall command line built by Eclipse. Mine read
${COMMAND ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS} } ${FLAGS}
^ ^
} accidentally moved to here ---------------------->|
I had meant to move ${FLAGS} to the end of the command line but also managed to move the right side } form ${COMMAND}..
NOTE: This was done to get the compile command line to look like the linker command line where one should move ${FLAGS} to the end of the line thus putting the list of ".o's" and the "-o xxx" before the "_l's: and "-L's" as is required by some releases of gcc/g++.
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
I'm trying to go through the Software Foundations Coq book (http://www.cis.upenn.edu/~bcpierce/sf/current/toc.html), but when I compile Induction.v (which looks like http://www.cs.uml.edu/~rhenniga/coq/sf_induction.html), I get the error message "Error: The reference evenb was not found in the current environment." -- even after compilation of Basics.v. Any ideas why?
I can confirm that opening CoqIDE from the same directory works on macOS: cd <sf-dir>; /Applications/CoqIDE_8.5.app/Contents/MacOS/coqide
from: The reference "X" was not found in the current environment
Try to erase every blank character in the address related to Coq or software-foundation book.
In my case, when I struggled with the file
C:\Users\XxX\Documents\software foundation\lf\Induction.v
, CoqIDE failed to execute From LF Require Export Basics and to define evenb_S theorem. Also, I couldn't see any files like Basics.vo or Basics.glob created when Basics.v with [Compile] - [Compile buffer] function in CoqIDE.
Everything works fine when I change my folder name to
C:\Users\XxX\Documents\softwarefoundation\lf\Basic.v
The Coq installer had already informed this >>
Link to the screenshot image of Coq setup
Compiling Basic.v with coqc Basics.v command should produce Basic.vo and Basic.glob files in the same directory. Then you should be fine with compiling Induction.v in the same directory as well; coqc Induction.v.
I'm trying to install LibLinear for MATLABR2014a on linux. When compiling in MATLAB the read.mexa64 and write.mexa64 are created just fine, it's on the train.mexa64 that it fails. The error I used to get was:
/home/admin/Documents/Project/Software/liblinear-1.94/linear.cpp:2739:19:
warning: ignoring return value of ‘int fscanf(FILE*, const char*, ...)’,
declared with attribute warn_unused_result [-Wunused-result] fscanf(fp,"\n"); ^
If make.m fails, please check README about detailed instructions.
So I sorted out the handling of the return value in linear.cpp and it still fails, providing only the last line directing me to the README. I've also tried installing gcc-4.7, g++-4.7 and cpp-4.7 but the make process still terminates without any information. As it suggests I have the matlab directory set to:
MATLABDIR = /usr/local/matlab
and I have included
-U_FORTIFY_SOURCE
in the CFLAGS just in case it was the ignored values causing a fuss. I managed to compile it from the command line in the main directory and it works fine, but it would be awesome to have a nice MATLAB interface :) If anyone's managed to get it up and running I'd be super grateful for any help!
If anyone stumbles across this then I found a method that seems to work. I tried using the Makefile in the matlab folder directly but kept strange getting compiler errors asking to change the source directory. However, if you go into the Makefile and change the line
MEX_OPTION = CC\#$(CXX) CXX\#$(CXX) CFLAGS\#"$(CFLAGS)" CXXFLAGS\#"$(CFLAGS)"
to
MEX_OPTION = CC=$(CXX) CXX=$(CXX) CFLAGS="$(CFLAGS)" CXXFLAGS="$(CFLAGS)"
it should work.
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 have inherited code, trying to compile with gcc on Linux.
what library am I looking for that has __builtin_ia32_stmxcsr ?
apologies -- i was too fast to submit; running gcc inside of Nvidia Eclipse. actual error message is "Functuion . . . could not be resolved" so i jumped the conclusion i needed to reference some lib. As the offending lines hav a :#if defined(SSE) I take it to mean that the -msse2 switch is present although i cannot seem to find a copyh of the compile command line. [just learning this Eclipse tool -- very new!]
You don't need to link with anything - the "builtin" in the name is a clue that it's a gcc built-in (intrinsic) compiler function.
However you do need to be compiling for an x86 target with SSE enabled for this to be recognised, e.g. gcc -msse2 ....
Note that you can use the _mm_getcsr intrinsic from <xmmintrin.h> instead of __builtin_ia32_stmxcsr - this would be a little more portable.
This is a bug in eclipses indexer with gcc's __builtin* functions. The bug report is at https://bugs.eclipse.org/bugs/show_bug.cgi?id=352537
The problem is that even the glibc/gcc libraries themselves use these __builtin* functions, so eclipse complains about a faulty xmmintrin.h etc., which is of course nonsense.
There is a workaround given in the bug report, you can add the function prototypes as user defined macros for the indexer, but of course this becomes tedious if there are a few more and some type checking abilities are lost.