The Eclipse CDT Binary Parser 'GNU Elf Parser' is having trouble on my Eclipse install on Windows.
All works fine on linux install
Problem
I have a compiled ELF in the GNU ELF 32 format. When I attempt to view this with the GNU Elf Parser, I get:
java.io.IOException: Cannot run program "objdump": Launching failed
at org.eclipse.cdt.utils.spawner.Spawner.exec(Spawner.java:347)
...
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
Deubg
Of course, this just means the CDT-plugins can't find objdump.
The ELF tested opens correctly in a linux-eclipse-cdt install
Say my objdump is located at 'C:\binutils\bin'
How the heck do you setup Eclipse's CLASSPATH to search there?
I've tried several things, from editing my system PATH, or CLASSPATH. I've also tried setting Workspace & C/C++ Build/Env settings. Nothing has worked.
Question
How the heck do you get this to work?
Edit - Basic Solution
Feel kind of silly, but to solve you just need to install MinGW and add C:/MinGW/bin to PATH. Then restart Eclipse.
I'm producing my own Eclipse distro with our own in-house toolchain & objdump versions, thus the mixup!
I've tried several other ways to get this to work (so I can eventually use our own objdump instance, but no luck!
Basic Solution Notes:
All you need from C:\MinGW\bin to make this work is:
objdump.exe
addr2line.exe
c++filt.exe
libgcc_s_sw2-1.dll
zlib1.dll
So if you move these to, say C:\myGnuBinUtils and add that to your system PATH (not some eclipse-setting, the actual path), then this works too.
these files are 24MB total; MinGW is 715MB...
Does anyone know how to achieve the same result with out HAVING to modify system PATH?
It sounds like you need an "ObjDump" Java wrapper. For example:
https://code.google.com/p/cdtplugin/source/browse/trunk/org.eclipse.cdt.core/src/org/eclipse/cdt/utils/Objdump.java?r=5
"CLASSPATH" is Java-only: it won't affect running a non-Java .exe
Java exec() will use the system PATH of your Java VM. You can, however, modify it at runtime. For example:
using Runtime.exec() in Java
ProcessBuilder proc = new ProcessBuilder("<Directory PAth>" + "Executable.exe");
proc.redirectOutput(ProcessBuilder.Redirect.INHERIT);
proc.directory(fi); //fi = the output directory path
proc.start();
Related
I have installed the latest version of Eclipse on my Windows 7 64-bit machine and the mingw compiler. In setting up a Hello World project, all goes well until I am asked for the Cross Settings what the Prefix is and the Path. The Path is obvious, it's the path to the compiler. However, I haven't the slightest idea what the Prefix is and Googling for much of the day hasn't enlightened me other than finding that a lot of other people have asked the question. Unfortunately the answers I've found appear to be for specific hardware. All I want to do is to produce an executable that will run on a Windows 32 bit or 64 bit machine.
So, what is the Prefix and how do I find what it should be?
What is probably happening here is that CDT is not locating your MingW or GCC installations.
simple - but unlikely reason - covering bases
There can be many reasons, from the simple - but unlikely at this point:
You don't have mingw installed
You don't have GCC installed
This can be tested easily by starting a shell and running gcc --version.
CDT heuristic not working
To more complicated reasons relating to your installation not being detected because the heuristic in CDT did not work on your machine. To find the correct settings, CDT will do:
Check $MINGW_HOME/bin for existence
Check <Eclipse install location>/mingw/bin for existence
Look for mingw32-gcc.exe or x86_64-w64-mingw32-gcc.exe on the PATH
Check C:\MinGW for existence
If CDT cannot find any of the above, you may lead to the situation you are in.
So, how to fix it!
Option 1
Start Eclipse from within a mingw set up shell. i.e. the one you can successfully run gcc --version from. That way Eclipse will inherit an environment that can launch GCC successfully.
Option 2
Set your environment up so that MINGW_HOME is properly defined. You can do this at the system level or within the build settings in Eclipse CDT. For example, on my machine in the build settings for the project (Right-click on the project, choose Properties, then choose C/C++ -> Environment) I have set:
MINGW_HOME to C:\MinGW
MSYS_HOME to C:\MinGW\msys\1.0
PATH to ${MINGW_HOME}\bin;${MSYS_HOME}\bin;<my normal path>
and this allows Eclipse to launch gcc as part of the build process.
NOTE The above setting were done automatically on my machine because mingw was correctly located by the heuristic.
Here is a screenshot of the build settings if it helps:
Prefix: Under the hood
To try and answer part of your original question about what Prefix is, I provide the below information. It is unlikely to be particularly helpf
Prefix, in GCC parlance, refers to the directory under which all the related GCC files are placed. With different prefixes you can have multiple GCC installed on your machine.
From the GCC FAQ:
It may be desirable to install multiple versions of the compiler on
the same system. This can be done by using different prefix paths at
configure time and a few symlinks.
The concept comes from autotools in general. Autotools is the standard GNU make system (where you do ./configure && make - simplified). The prefix is the command line option to the configure stage (--prefix) to specify where to install the tool to. GCC above uses the --prefix to allow multiple GCCs on your system.
If you really want to know more about this, read the autobook. The section on configuring covers --prefix:
‘--prefix=prefix’
The –prefix option is one of the most frequently
used. If generated ‘Makefile’s choose to observe the argument you pass
with this option, it is possible to entirely relocate the
architecture-independent portion of a package when it is installed.
For example, when installing a package like Emacs, the following
command line will cause the Emacs Lisp files to be installed in
‘/opt/gnu/share’:
$ ./configure --prefix=/opt/gnu
It is important to stress that this behavior is dependent on the generated files making use of this
information. For developers writing these files, Automake simplifies
this process a great deal. Automake is introduced in Introducing GNU
Automake.
Additionally, Mingw takes advantage of all this prefix options. Read more about that on mingw's site. But the short of it is that the main prefix for mingw is /mingw.
I installed cygwin (the latest 1.7.xx?), and then installed eclipse cdt (Juno).
When I tried to build a hello world project, despite eclipse identifying that cygwin was installed, it didn't work.
So I manually added c:\cygwin\bin to the path, which found all the executables in cygwin, including g++, make ld, etc.
Now, eclipse can build the project, but when debugging, gdb starts up and can't find the source code. It claims that it can't find:
/cygdrive/c/users/me/workspace/test1/test1.cc
.
even though that's exactly where it is. It's as though cygwin's directory system doesn't work.
I can manually load the source from:
c:\users\me\workspace\test1\test1.cc
and the debugger works, but the next time I start a new project, I have to do it again.
How do you instruct the eclipse/cygwin combo to correctly find source code?
Alternatively, is Mingw any easier? I have experienced similar problems with eclipse seeing that mingw is there, but build failing because it doesn't find the executable.
Here is how I made it work.
I goto Window ==> Preferences ==> C/C++ ==> Debug ==> Source Lookup Path
I Add a Path Mapping: Project Source
On the left side I put the path that Cygwin expects, i.e. \home\MyName\projects and on the right side I put the Windows path, i.e. C:\cygwin\home\MyName\projects
Then when I debug it finds the source file fine.
Go to Windows->Preference->C/C++ -> Debug -> Source Lookup Path. Add following 'Path mapping'.
\cygdrive\c -> c:\
Although Above are given good answers but still it might not solve the problem sometimes phew!!!!
Suppose you install Cygwin in C: but your eclipse workspace is in D: then there is a problem in your mounting
all you should do is, open the cygwing shell & type "mount" to get the following :
Ritvika#Ashutosh ~
$ ls
Ritvika#Ashutosh ~
$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
Ritvika#Ashutosh ~
$
here my Projects are all under D:\ECWorkSpace, so my mapping needs to be present
in Eclipse as:
/cygdrive/d d:/
Hence, now Armed with this knowledge do what PathM says
1. goto Window ==> Preferences ==> C/C++ ==> Debug ==> Source Lookup Path
2. Add a Path Mapping: Project Source
3. On the left side put "cygdrive\d", & on the right put : "D:\"
This should work. ( It did for me :) )
You can Check this FAQ as well : https://wiki.eclipse.org/CDT/User/FAQ#I.27m_using_cygwin_and_when_launching_the_debugger.2C_it_complains_that_it_can.27t_find_the_source_file
I use MinGW + CDT, and it is giving me great satisfaction. I installed it many times and never had any disagreement. No much to configure than what you did with cygwin. Download the Eclipse for C/C++ developers (probably what you did) to get CDT (MinGW Tool Chain -> gdb + gcc) directly operational. Set your \\MinGW\bin\ directory into your PATH and you should be good to go...
Note : Like Cygwin, MinGW provides a Linux-like Shell.
For MinGW-64, ready-made builds are a little bit more difficult to locate. See here.
Look at set-up of "Common Source Lookup Path" here: http://wyding.blogspot.dk/2009/04/setup-cygwin-toolchain-in-eclipse-cdt.html
I replaced gdb with msys gdb. For example:
Current configuration:
... Application Configuration .. Debug .. Debug
GDB Debugger gdb
to
GDB Debugger path to msys gdb (like for example c:\msys\bin\gdb.exe
I'm having problems debugging a JNI application. I've read several threads in StackOverflow, like this one, this one or this one. I've also tried to start gdb in a separated shell and attach it to the running java process. In both cases, the problem is the same: GDB can't find the sources to debug. Things tried
Add "dir" line to gdbinit, pointing to C++ sources folder
Adding the C++ sources folder to the GDB debbuging configuration in Eclipse, in the "Sources" tab.
Adding set environment LD_LIBRARY_PATH=/path/to/library.so, being library.so the library file built from C++ source files
Attach ddd to the java process, but then I get an error because pthread_join.c is not found in the working directory. I don't have this file in my hard disk. I don't know what is this about.
Nothing worked. I've spent several days on this. I know my bug is in the C++ code called by the JNI wrapper, but I can't debug it. Any hints? If helps, I'm running Eclipse Juno in Debian 7 under a Parallels VM on Mac OS.
Many thanks in advance,
You need to have debug information in your native library. You should pass -g to your compiler and linker to have this information in the executable. You may also want to add -O0.
As an alternative to attaching to the Java process, you can create a C++ app and debug it directly. You just need to link in the functions you want to test. In the main function, create the VM, register the functions with RegisterNatives, and kick off a Java test class the uses them.
Hopefully, the debugger has no problem finding the sources since it is just part of the normal compile/link/debug loop of a C++ app.
I would suggest to start with the latest ADT bundle. You can even download the Mac version, so you will not even need Parallels (see a detailed instructions). Then, choose Debug Android Native Application in launch menu.
For the past week, i have been hunting a free development environment for STM32F1xx, which is supported by FreeRTOS. And no success yet :( .
Now I've found this: http://www.stf12.org/developers/ODeV.html
It's an Eclipse configuration for STM32 compiling and debugging, and there is a FreeRTOS demo too. Perfect!
So I downloaded a preconfigered version of eclipse and tried to compile a demo project to get this error:
Cannot run program "cs-make": Launching failed.
Depressing. Please help, i am very bad at configuring IDE's, compilers and linkers so this has to be newbie-friendly :)
The Eclipse project is configured for CodeSourcery toolchain. You need to install CodeSourcery compiler toolchain from: http://www.mentor.com/embedded-software/codesourcery. Choose Lite Edition, ARM-NONE-EABI package. After the installation make sure you can start cs-make from command prompt (by typing it's name there). Generally, you want all toolchain programs to be accessible from command prompt, which implies that their installation path must be in system PATH variable.
P.S.
Make sure the path DOES NOT contain spaces like standard Windows programs directory "C:\Program Files", instead install the tools in a directory like "C:\arm-none-eabi", "C:\ARM_tools" or something like that.
Ah, thank you got it to work now!
And I ran into another problem too. When I tried to compile another error came up saying something like: "C:\Program is no file or directory". I Solved it by placing all compilers and OpenOCD in the root of my C-drive. I think it's because the make doesn't understand spaces in the make file, if anyone else get the same problem.
I had developed a small program in netbeans using c++. I need to know how can i deploy/run the package on another linux system
Abdul Khaliq
I have seen your code, you probably missing XML files in the current folder... where the executable is located... paste then and then run as ./your-executable
I recommend that you use a makefile to recompile on your target machine which will ensure that your program is deployed properly.
You should use a makefile as suggested. I know that NetBeans can generate one, but it's been a while since I last did so. Maybe this can help: http://forums.netbeans.org/topic3071.html
Typically, once compiled, your executable will need several libraries. Chance is that those libraries will also be available on the target linux system.
Thus, you can simply copy your executable over to the other system. If you run ldd on your executable, you should see the list of libraries your executable is dynamically loading. Those libraries should be available on the target system as well.
In case your executable makes use of resources such as images and other binary files, you can use a resource system (e.g. Qt Resource System) and compile those binary files into your executable.
The easiest way to test is to do the copy, run
ldd yourExecutable
on the target system. It will tell you if you are missing any library. Install those libraries using the system package manager.
Of course, you also have the option to statically build all libraries into your executable. However, this is not recommended since it makes the executable too large and complicates matters.
What type of package is your netbeans compiler creating? deb,rpm? If you are moving the package to a different linux install you will need to use that distributions package type. Ubuntu - deb
Fedora/Redhat - rpm
etc...
I'm not sure how you change this in netbeans but I'm pretty sure it has the ability to. A google search could help you more.