I've been trying to research this for a while and my limited experience with compiling is hindering my ability to figure it out.
Basically, I have some code which is being written in Qt Creator, then built with these build steps:
qmake.exe [project name].pro -spec win32-msvc "CONFIG+=qtquickcompiler"
jom.exe in C:\eclipseworkspace\[project directory]
I'd like to use the Fortify SCA (Static Code Analyzer) to automatically scan this code for vulnerabilities, but most of its user-friendly features are designed towards Java. I haven't given up, though, because Fortify does claim to be able to scan C++ code that uses 3rd Party Compilers (which I assume Qt falls into that category).
(Page 37 of this document)
As a preliminary step to running Qt Creator on my actual code, I've wanted to see if I can at least get it to run on any Qt sample project, to see what the steps to do that would be.
I'm using Qt 5.12.7
on a Windows 10 OS
with the MSVC2017 32bit compiler,
but I feel any correlation between Qt and Fortify that works will be enough to set me off in the right direction.
Or perhaps my optimism is misplaced and I just don't understand the limitations of what I want to do. Either way, it'd be nice to know.
I have found this to be easiest on Linux. I think this solution translates to Windows.
You must inject the sourceanalyzer into your compiler command.
For example, I run cmake to configure my projects.
export CC="sourceanalyzer -b <your_project_name_here> gcc"
export CXX="sourceanalyzer -b <your_project_name_here> g++"
cmake <bunch of my cmake definitions> <path_to_src>
# I do a clean to remove what sourceanalyzer picks up during configuration time tests.
sourceanalyzer -b <your_project_name_here> -clean
sourceanalyzer -b <your_project_name_here> -scan -f scanResults.fpr
I cloned LEDE repository from github and wanted to debug my simple program on router. To do this, I configured LEDE build (like here: https://wiki.openwrt.org/doc/devel/gdb) using menuconfig:
Advanced configuration options (for developers) → Toolchain Options → Build gdb
Development → gdbserver
Development → gdb
Then I compiled my simple program with -ggdb3 flag and wanted to start debugging. However, it is impossible because gdbserver binary seems to be missing on router after sysupgrade (it does not appear in /bin, /sbin, /usr/bin, /usr/sbin). Have I missed something in this configuration?
OK, I figured it out. When you build the system image and total package size is bigger than your available ROM (in my case 4MB), your .bin in /bin/targets/ directory won't be updated and you will get your old image. Everything without any warning message!
The Online LLVM demo page had an option to generate LLVM C++ API code as backend from a source code. However, that demo page is now disabled. I was wondering how we can do it ourselves using the available LLVM tools.
I tried the following
clang++ -c -emit-llvm input.cpp -o input.ll
llc -march=cpp -o input.ll.cpp input.ll
which gives the following error
llc: error: invalid target 'cpp'.
I am using LLVM/Clang version 3.2.
The LLVM C++ backend has to be enabled during configuration when building LLVM. It's enabled by default in the configure (autotools) build, but not in the CMake build when you build on Windows. You can enable it by setting the appropriate flags while configuring with CMake. See this page for more information.
Quote:
LLVM_TARGETS_TO_BUILD:STRING
Semicolon-separated list of targets to build, or all for building all targets. Case-sensitive. For Visual C++ defaults to X86. On the
other cases defaults to all. Example:
-DLLVM_TARGETS_TO_BUILD="X86;PowerPC".
UPDATE
Since version 3.9 the CppBackend is no more a valid target. They've removed from their code as the generated code were presenting a few issues.
Check this commit
Remove bit-rotten CppBackend.
This backend was supposed to generate C++ code which will re-construct
the LLVM IR passed as input. This seems to me to have very marginal
usefulness in the first place.
However, the code has never been updated to use IRBuilder, which makes
its current value negative -- people who look at the output may be
steered to use the *wrong* C++ APIs to construct IR.
Furthermore, it's generated code that doesn't compile since at least
2013.
Differential Revision: http://reviews.llvm.org/D19942
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk#268631 91177308-0d34-0410-b5e6-96231b3b80d8
Sadly, this appears to no longer be possible in more recent versions of LLVM. The associated commit message explains it pretty well.
As you can see in the following commit,
Remove bit-rotten CppBackend, the generated code would show issues.
commit 257fabb18605265a79397d35dd79a3973760ffaf
Author: ---
Date: Thu May 5 14:35:40 2016 +0000
Remove bit-rotten CppBackend.
This backend was supposed to generate C++ code which will re-construct
the LLVM IR passed as input. This seems to me to have very marginal
usefulness in the first place.
However, the code has never been updated to use IRBuilder, which makes
its current value negative -- people who look at the output may be
steered to use the *wrong* C++ APIs to construct IR.
Furthermore, it's generated code that doesn't compile since at least
2013.
Differential Revision: http://reviews.llvm.org/D19942
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk#268631 91177308-0d34-0410-b5e6-96231b3b80d8
So, I've got some stuff that I need to develop with pintools, and I'm having a hard time using eclipse with it all.
I found this, but it doesn't give very specific details. I was hoping that someone could provide very specific instructions as to how to use eclipse on Mac (or linux) to develop pintools.
I tried it a little, and found that on mac you have to install the clang build toolchain, and even then, doing a simple import of the MyPinTool was harder than it seemed because the makefile specifies a lot of extra options/variables that I don't know how best or correctly to configure in eclipse.
You can download pintools. The makefile that I'm talking about is in source/tools/MyPinTool, it sources a file located at tools/makefile.gnu.config
EDIT: by the way, I'm on Mac OS X Lion with an i7 using pin 2.12
c++ --version returns this:
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM
3.1svn) Target: x86_64-apple-darwin11.4.2 Thread model: posix
I'll guess that you are using the newest version of Eclipse (4.2) and that you start working from the template MyPinTool pintool in "source/tools". I'll take those guesses because it is much easier to configure CDT to recognize the pin environment from a compiling tool, rather than manual configuring it.
First create a makefile project from existing source:
Then go to your project properties and select under "C/C++ General" -> "Preprocessor Include..." the "CDT GCC build output parser", make sure that it is enabled and if you are using clang++ as the compiler, that you add it in the compiler pattern:
Now build your pintool from within eclipse (either click on the hammer icon in the toolbar, or right click your projet and select "Build Project"). CDT should parse the build output and resolve all the paths and required macros from it. Basically, now you are good to go... But...
I have found that CDT has some quirks, if this doesn't work, try and do the following:
Check if you are working on a "deep" path (/a/b/c/d/e/f/g/h/i/j/k/l/m), sometimes CDT takes the relative build path used by the make file, and translates it to a wrong absolute path. I've found that working in a "shallower" path resolves this issue (I should open a bug report for this...).
Sometimes the indexer doesn't kick in right away. Try refreshing the project, rebuilding the index (Right click on project then "Index" -> "Rebuild"), and even restarting eclipse then doing this again.
I know it is a bit of voodoo magic, but I got it working :)
I tested this procedure on a fresh kit with MyPinTool but if it still doesn't work, please provide the steps you did and what errors does eclipse give you.
I am quite troubled as this shouldn't be causing me such a headache. I've downloaded the most recent Eclipse Indigo and all CDT C++ plugins for MAC OS X 10.7.1/
Upon restarting after installing the above CDT plugins, I've developed a simple 'hello world' c++ application and have tried running the application, "Launch failed. Binary not found." error message. I've read multiple fixes but none have worked. I tried adding the -arch i386 flag to the linker and compiler commands, still no luck.
Has anyone successfully gotten Eclipse C++ running on 10.7.1?????? This blows my mind. I can simply write the same program in VIM and compile it just fine via the terminal and execute just fine. ECLIPSE DOESN'T WANT TO PLAY ALONG.
I will be deeply indebted to anyone who can help!!!!!
EDIT: compiler output
**** Build of configuration Debug for project HelloWorld ****
make all Building file: ../main.cpp
Invoking: GCC C++ Compiler g++ -I/Developer/SDKs/MacOSX10.6.sdk/usr/include -O0 -g3 -Wall -c -fmessage-length=0 -arch i386 -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.cpp"
Finished building: ../main.cpp
Building target: libHelloWorld
Invoking: MacOS X C++ Linker g++ -arch i386 -dynamiclib -o "libHelloWorld" ./main.o
Finished building target: libHelloWorld
**** Build Finished ****
I am using Eclipse Juno with CDT on a 2007 Macbook running Snow Leopard. I have the two symptoms:
No Binaries folder in Project Explorer, and
The 'Launch failed. Binary not found' error.
I have spent hours searching on Google for an answer, long enough to ascertain that these two symptoms are indicative of any number of problems which have been reported for not quite a decade without adequate resolution. That is a problem right there because after a decade there should have been more than enough input data to provide one troubleshooting procedure somewhere which walks the user step by step through the elimination of all possible causes.
Instead, for hours I have read about a multitude of people, many of whom have resolved their particular problem but all of them seeming to have had to do something slightly different to get there.
This should not be that difficult to resolve. Particularly in cases such as mine [but I am not the only one] when the Console view displays a Build with no errors yet the user can copy the binary file [which Eclipse bizarrely says it can not find] to the Desktop and run it without any problems from either Finder or a bash terminal session.
All of this seems to be pointing rather emphatically toward the lack of adequate indicators in the Mach0 64 binary parser which should be designed to tell us exactly what it needs which it is not seeing.
Admittedly, this is exacerbated in the case of MacBooks like mine which are running a 64bit OS [Snow Leopard] on a 64bit CPU which the manufacturer, unfortunately, hamstrung with a 32-bit bootup kernel. But, be forewarned, I have already tried the -arch i386 g++ switch, and the relinking of g++ to g++-4.0 without any change in the symptoms.
ADDENDUM ADDED 10/07/2012:
I am adding this checklist in the hope of clarifying a Way for the undoubtedly many others who will ask this question in the years to come. This Way reflects what I found to be necessary when using Eclipse Juno with a Mac running Snow Leopard:
1) Go to Preferences->C/C++->New CDT Project Wizard, and under Preferred Toolchains, make sure all the Executable project types are set to MacOSX GCC.
2) This is a biggie. I was able to get a Binaries folder in Project Explorer, and hence be able to run the project after building it, by using a Project name which does not contain dots ['.']. This I learned from another answer here, edited a few hours after my previous message. This requirement is easy to miss, hence a common one particularly if you are Eclipse experienced but only with other languages, because tutorials for other language plugins [such as with PyDev or for Java] frequently have you create Projects with dots in the name. If you have developed that habit with other languages, break it when using CDT for C/C++. Be forewarned, however, that it is not enough to just do a Right-Click and Rename an existing project name this time not using dots. The simplest Way is to delete your old project and create a new one with a name without dots.
3) There are many websites cautioning you to make sure you either use the -arch i386 compiler switch or change the links for /usr/bin/gcc and /usr/bin/g++ to point to gcc-4.0 and g++-4.0 instead of gcc-4.2 and g++-4.2. I created a bash script to ease switching back and forth and investigated if this was necessary. It was not, at least not with my Macbook. Based on what I read at one site from a Mach-O developer, I suspect that the current version of Mach-0 64 goes both ways. Which is a good segue to ...
4) In the Project Properties, not Preferences, go to C/C++ Build->Settings and under Binary Parsers make sure Mach-O 64 Parser is checked. Make sure this, and not the deprecated Mach-O parser, is checked.
5) At this point, after you build your project, several things should be evident in the Project Explorer:
6) There should now be a Binaries folder under project's folder.
7) Within that Binaries folder should now be your executable file. It should have [x86_64/le] next to it if, like me, your Mac is effectively 32bit. Now is not the best time to get into the confusing topic of whether your Mac is effectively 32bit or 64bit. If you do not know, and a lot folks don't because Apple does make it confusing, check out the little app which can be downloaded from http://www.ahatfullofsky.comuv.com/English/Programs/SMS/SMS.html which will tell you What Is Truth. It is free, but the 'price' is that you have to scroll pass the ads at the top of the page reflecting the programmer's political disposition.
For those of you that are new to programming/eclipse/IDEs and get the same error but the solutions above don't work, I solved my "Launch Failed. Binary Not Found." error by doing the following: Simply be sure to build your project ("Project" > "Build All") before attempting to run or debug. I was thinking that the IDE would do the building when I clicked debug or run, but that is not the case (obviously, in retrospect). Newbie lesson learned. Once you build you should see a "Binaries" and "Debug" folder under the root directory of the project.
I was using OS X 10.7.3, if it matters, though I assume the mistake I made is fundamental and any eclipse distro would give the same error.
on mac:
Make sure you have xcode installed. Test it by writing "info g++" you must see proper information about the compiler.
Build your project.
Go to the folder of your project. You should see an executable file in Debug or realise folder, depending to your building configurations. If you d-click on the executable file you should see the result on the terminal.
Back to Ecliipse, from Run/Run Configurations... and then browse to the folder that you have the executable file - one you already found - you can also change build configurations as you wish in that window. And make build automatic for each run.
Run again it should work.
Good luck !
I had the same problem, then I found a solution on this site.
Let me explain shortly;
Create your c++ project,
Have a look at project properties(⌘I),
Select Mach-O parser under binary properties,
Write your codes down,
Do not forget building your project (⌘B) before run.
You should change the settings for your project to build an executable instead of a dynamic library:
Invoking: MacOS X C++ Linker g++ -arch i386 -dynamiclib -o "libHelloWorld" ./main.o`
Go to project properties -> C/C++ Build -> Settings -> Build artifact, and select Executable in the first drop down list.
I am using Eclipse Oxygen and the following fixed my problem:
Right-click on your project and go to properties. Navigate to C/C++ Build > Tool Chain Editor and select MacOSX GCC in the Current toolchain, and Apply and Close.
Build your project with CMD+B and then run it.
I was having the same problem. The answer can be hard to find as the "binary not found" issue has cropped up several times before, with different causes and solutions (selecting the 64-bit parser, etc.).
It turns out that, in my case, the fix was simple: you have to do a manual build, just once, for every new project you create. After that, works as usual.
Details: using a fresh fresh install of Eclipse Indigo Service Release 1 on Mac OS 10.7.2.
If your project name contains a "." (dot), the binary file will not be generated on building project.
Remove all the "."(dots) from the project name and rebuilt it or try creating a new project.
Happy coding!
If you can successfully built but when try to run it getting error:
Possible solution could be adding new configuration with full path to your binary output file
(Run->Run Configuration...->Main->C++ Application):
I solved a similar problem with Eclipse by creating a "Launch Configuration". I am using the Indigo release of Eclipse on OSX Lion with CDT (C/C++ dev environment). I found the option to create a new launch configuration in Project->Properties->Run/Debug Settings.
I encountered this problem after creating and building an empty "Hello World Ansi C Autotools Project". The build process created a working executable as src/a.out. I could run a.out successfully from the terminal but Eclipse did not understand that this was an executable for my project until I created a launch configuration pointing to it. Once I did that I was able to run a.out as usual using the green run button.
I had the same problem, even when i had set the artifact to executable. It was because the shared lib setting was ticked and this causes a dylib to be made even though you have specified an executable.
I go this to run by setting the Builder Type to Internal Builder on the C/C++ Build tab, in the project properties dialog.
No matter which approach to take to solve this issue on your workspace, this problem seemed to have become native to the project that I had created. Neither using the arguments or making sure the gcc version for linking did not work. I did find an intuitive solution. Here it is:to the "...binary not available..." error.
Do the following:(remember the following steps are after you have taken either of the above routes and none of those have solved the issue.
1.) delete everything - the project and the files.
2.) create new project and source files
I had the similar issue but code was different. In File.h file make sure
virtual ~Destructor () {}; //Don't forget Curly braces {}
Above statement shows destructor initialized () and defined with curly braces { } . In my code I forgot to define Destructor.
Hope this helps
I was having the same problem, so I fiddled around a littpe bit and found out that if I clicked on the "profile" button (green play icon with a little clock under it), to the right of the "run" button, my program would Run the next time I clicked on the Run button.
I actually dont know what that did, but it allowed me to run the code.
if anybody knows why this helped, and whether it is an actual solution or not dont hesitate to relpy!