If you have followed Building a cross-platform, feature-based Eclipse RCP Product with Tycho (the umpteenth), and have run the build on a Windows system, you will have ended up with non-executable products for Mac OS X and Linux.
What this means is that the product will build just fine, but when transferring the product zips to the target system (Mac OS X, Linux), unzipping them, and trying to run them by double-clicking on the executable, nothing will happen. This is due to the fact that Windows does not know about file system permissions, as used for *nix systems (such as Mac OS X and Linux). Hence, a Tycho build on Windows will not be able to set the executable bit needed for the OS X and Linux products to be executable “as is”. This behaviour is described for Mac OS in Bug 355370, an enhancement request on bugs.eclipse.org: https://bugs.eclipse.org/bugs/show_bug.cgi?id=355370.
Solution I: Set the executable bits manually
One solution to this problem is of course to set the executable bit for the launcher file manually, and re-compress the product for delivery, or make a script do it for you. The launcher file is located in the base directory of your unzipped product, and will be called eclipse (Linux) or eclipse.app (Mac OS X (Cocoa)) if you haven’t set a Launcher Name on the Product Configuration’s Launching tab, or given the respective file name if you have.
In Linux, this can either be done via the GUI, or on the command line.
Setting the executable bit via the GUI (on *buntu)
On Ubuntu or its friends, you can use the GUI to set the executable bit. Simply right-click on the launcher file, select Properties, select the Permissions tab, and check the Allow executing file as program checkbox.
Right-click on launcher file > Properties > Permissions > Allow executing file as program
Setting the executable bit via the command line
To set the executable bit on the launcher file via the command line from a terminal, navigate to the unzipped product directory, locate the launcher file (ls -l is your friend), and change the file system permissions of that file with
sudo chmod +x [launcher file name].
sudo chmod +x [launcher file name]
Mac OS X
On Mac OS X, setting the executable bit from the command line works just like in Linux, albeit with a slight difference, as setting it for the launcher file (e.g., eclipse.app) doesn’t change a thing. This is due to the fact that the .app file is in fact a folder archive. If you open this archive (let’s assume it is called eclipse.app) in Finder, you will find the actual launcher file in eclipse.app/Contents/MacOS/. It is simply called eclipse. In a terminal, you can simply navigate to the /MacOS/ folder, and call sudo chmod +x eclipse. Double-clicking on eclipse.app in finder will now execute your RCP application.
sudo chmod +x [launcher name].app/Contents/MacOS/[launcher file name]Note that moving eclipse.app to the Applications folder (as is usually done with Mac OS X apps for “installation”) will not work, as not all folders and files are inside the eclipse.app archive folder. If you want to provide this functionality, there is a workaround mentioned in another bug report (Bug 378021: https://bugs.eclipse.org/bugs/show_bug.cgi?id=378021#c5), but this will change all products regardless of OS, so you’d have to run one build for Mac OS with the workaround in place, and another one for all other OSs without the workaround.
Solution II: Change your build OS
The easiest solution for the executable bit issue, however, is of course to switch your build system to a *nix platform. This has been confirmed to be working in a comment by one of the Tycho committers on stackoverflow.com, and it does make sense, since an OS which knows executable bits should be able to set one.
Now, don’t fret about setting up a new system for builds exclusively (if you’re not running a build server anyway), simply use virtualization software, like the great, open source VirtualBox for example.
UPDATE (15 May 2013) re executable bits
If you have switched to using Linux for your Tycho builds, you may still encounter issues with the executable bits not being set correctly. This is due to a bug similar to Eclipse Bug #368089, where the executable bits are not set correctly if the system uses a non-English locale (via the environment variable $LANG). To fix this, set your locale to en_US.UTF-8 in a terminal as follows.
This should fix the issue.
|If you found this post helpful, you may want to consider donating to help cover server costs.|