So for the past couple of days I’ve been trying to get a Hello, World! program to run using C++ in Eclipse Juno on my MacBook Pro running OS X 10.8.3. After getting the project to build in Eclipse and getting a successful compile, I kept getting the following error when running the executable: “cannot execute binary file”. The binary file also was being shown in the Project Explorer in Eclipse with a puzzle piece icon, rather than the executable “play” icon. As it turns out, by default Eclipse will set up the project to generate a shared Library rather than an executable, or so it seems. To fix the issue, go into the project properties and under MacOS X C++ Linker, uncheck Shared (-dynamiclib) in the Shared Library Settings sub section. Apply the changes, run a build and presto!
This solution is all thanks to this post. I’m just reposting the solution to firstly help remind myself of what to do and secondly in hopes that the reposting will help someone else find the solution faster than I did.
As far as I can tell, OpenGL had little to do with the problem, but since I noticed the problem after trying to run an OpenGL project, I thought it valuable to tag it.
Okay, so in Eclipse you can switch your workspace, right? Well, what if you open a workspace that you no longer use? It just keeps showing up on the list of recent workspaces. So, how do you remove it? Pretty simply actually.
You’ll need to navigate through some hidden folders to do so, in which case it’s usually easier to do through a Terminal window. Note: these instructions will work with Linux and OS X. If you’re on Windows, you’ll have to call Bill Gates, although it’s possible this will also work.
In the terminal, navigate to eclipse/configuration/.settings, where eclipse is your Eclipse installation folder. In this folder there is a file called: org.eclipse.ui.ide.prefs. Edit this file, and you should quickly see the line that says “RECENT_WORKSPACES=” followed by various paths to workspaces you’ve used. Simply delete the workspaces you don’t want. They are separated by “/n”. So make sure to leave a “/n” between each workspace. Additionally, you must leave the information on a single line. Do not break it out to multiple lines.
QUICK ANSWER: eclipse/configuration/.settings/org.eclipse.ui.ide.prefs
About a week ago I got the Nexus One from Google. Today I decided to delve into the SDK and see if I could get a “Hello, World!” script running on the phone. Following the Android Developers website, I downloaded the SDK and installed the Eclipse plugin for Android. I was able to get the Hello, World! script running fine in the virtual Android machine, but when I started trying to connect my phone for debugging I started running into issues. I’m using the Nexus One which is currently on Android 2.1 and I’m on OS X 10.6 (Snow Leopard). It seemed that whenever I ran the command adb devicesin the terminal, I got an empty list of devices. Frustrating.
Well after scouring the internets with no results, I remembered that when I installed the SDKs with Eclipse, there seemed to be a lack of overlap between the two. When installing the Eclipse Plugin, it creates a folder in the workspace called com.google.android.sdk, except this SDK doesn’t line up with the SDK from the Android Developers site. When I had initially put things together I simply copied over some of the files created by Eclipse to avoid breaking the plugin. But when running adb devices, it was running from the Eclipse provided SDK. Upon trying again with the adb command from the Android Developer’s SDK, the phone shows up on the list of devices. So now I’m copying arranging files to use the good SDK.
Not sure if this will have an effect on the Eclipse plugin. I’m assuming not. My guess is that the Eclipse plugin was simply packaged with an older version of the SDK. We’ll see though. So happy to see the Android SDK is in Java though. Way better than the iPhone SDK.
UPDATE:
Looks like you don’t want to overwrite any files. Simply leave the com.google.android.sdk directory as is and point to the downloaded SDK in the Android preferences pane in Eclipse (SDK Location). I had to delete and recreate my helloworld project in Eclipse to repair the errors due to the missing core library (android.jar).
I’ve finally found the Eclipse prefs file that stores the local file path to linked resources (linked libraries). Linked resources are basically shortcuts to files/folders on your local system. Buried in the Workspace/.metadata/.plugins/loc.eclipse.core.runtime/.settings/ folder (on OS X), the loc.eclipse.core.resources.prefs file contains the absolute paths to those linked libraries.
A few months ago I began working with Ant tasks in Eclipse. Specifically, I was using fdtkit along with Ant in Eclipse to generate JavaDocs for my Actionscirpt 2.0 libraries using as2api. For the most part fdtkit is a fabulous tool, or rather toolbox for generating JavaDocs and numerous other tasks with the use of Ant. However, the issue that I very soon found myself confronted with was documenting classes from linked libraries in Eclipse. Normally I will set up a project with a src containing code specific to that project, and then make use of linked libraries to make use of code from other projects/api’s. When running an Ant task to create my JavaDocs I was unable to intelligently identify the paths to my linked libraries to add to the documentation.
The way Eclipse and FDT handle linked libraries is through the IDE and the .project file found in the root of the project folder. Opening the .project file, you might see something like this (assuming you are using linked libraries):
<link>
<name>core</name>
<type>core</type>
<locationURI>FP8</locationURI>
</link>
Looking at the link object, you will see two important pieces of information the name property and the locationURI property. Now the name property represents the name associated with the linked library (obviously) and then there’s the locationURI. The locationURI is a reference to the linked resource. The problem here is where the hell is the identity of that locationURI? In the Eclipse IDE you can select a linked library in the Explorer view and then examine it with the properties view. Here you will see the value for the resolved location, which is the full, absolute path to the linked library on your local system. But how the hell to I get that property with Ant? How to I access it all? Well, I’ve been asking that question for quite some time, scouring the Internet and finding nothing. Today, I found my answer.
Determined to know how linked resources were being saved on my system I began digging deep in the my Eclipse folder to find property in some buried file. Note, I’m running Eclipse 3.3 on OS X. I would imagine the path is similar on Windows, but probably not exactly the same (I’m guessing it’s pretty damn close to the same in Linux). Anyway…
The file location is: ${your_eclipse_workspace_folder}/.metadata/.plugins/loc.eclipse.core.runtime/.settings/loc.eclipse.core.resources.prefs
This file looks something like:
pathvariable.FP7 = /Users/local/Workspace/fdtkit/lib/FP7
pathvariable.FP8 = /Users/local/Workspace/fdtkit/lib/FP8
pathvariable.FP9 = /Users/local/Workspace/fdtkit/lib/FP9
So now, through Ant task it is possible to have your build.xml (relative to your project) parse the .project file of the project for linked libraries and with the locationURI parameters to grab the absolute path to the class library from the loc.eclipse.core.resources.prefs file.
Please feel free to contact me if you have any questions regarding this post. I’m sure this isn’t the most straight forward explanation of what I’ve found here, but I’m a little to jacked up on coffee to form clear coherent thoughts right now.
Note: Linked resources are Workspace specific. Different workspaces have a different set of linked resources.