Is there a simple guide available anywhere on how to install a recent version of Eclipse on Linux as a "normal" application?
The version in the Debian repositories, even for Debian 9, is a 3.X version of Eclipse, which must be very old, as they are now at V4.7.
The default method for the "eclipse.org" versions to install themselves is to put everything in the home directory, which is not a great approach for a system where the home directory is supposed to only contain user data (e.g. the whole home directory is backed up daily)
I can't believe that something so widely used does not have any good instructions for how to install it as a normal application would be - where all the application files are in a shared folder under /opt, and only user data is stored in the home folder.
I have found this thread, which may be promising:
https://www.eclipse.org/forums/index.php/t/1080525/
And a previous question seemed reasonably good, but on trying to follow it, the installer screens have changed, and everything about "bundle pools" became very confusing!
https://askubuntu.com/questions/695382/how-to-install-eclipse-using-its-installer
Not sure if you are still looking for an answer. This is how I have been doing for a few years now.
Download it from website and extract eclipse folder under /opt
Change ownership of the folder to your user and make it readonly recursively.
Create a desktop file to launch it as a regular user.
You can make the folder writable once in a month to make sure latest updates are installed then make the folder readonly again.
TL;DR give up now
I found this when Googling for how to do a multi-user install on Linux Mint 20.
Although Eclipse publish specific documentation on how to do a multi-user installation this little correlation with the current reality.
I first tried installing the package version of Eclipse. That installed the flatpak package, not a native package. It turns out that flatpak has a bug (opened in 2017) whereby it creates a new image each time you run the binary - and at 1.2G that was eating my enterprise storage very quickly. Although the package installed from the command line use apt it did not add any record to the installed package list - so I couldn't uninstall it with apt (using flatpak uninstall eclipse seems to have worked).
I then downloaded the tarball eclipse.
This has a GUI installer which would not run via [x]sudo - so I had to subvert the usual security model on Mint/Ubuntu and make the root user a logon account.
I specified the install location as /usr/local/eclipse. The installer did its thing. Sadly it did not provision a menu entry for the program. Since it actually installs in a sub-directory of the target named with versioning information (/usr/local/eclipse/jee-2019/12/) I created a shell script in /usr/local/bin/ to point to the binary (so when I upgrade, I just need to change the shell script to point to the new location). I then created a .desktop entry to run the shell script and ran:
xdg-desktop-menu install --novendor eclipse.desktop
I also copied the eclipse.desktop file to /etc/skel/Desktop and to /root/Desktop
From my root session, opening the .desktop file by double clicking, or running the shell script started eclipse.
Sadly, this did not create a start menu entry (it has worked for me with other applications).
Logging on a different user, copying the .desktop file to ~/Desktop and running it resulted in....
(Of course it would have been far too easy to display the failure reason in the dialog, or even put the path to the log file in a widget where I could copy and paste it)
Looking at /usr/local/eclipse/jee-2019/12//eclipse.ini, I find this:
-startup
plugins/org.eclipse.equinox.launcher_1.5.600.v20191014-2022.jar
--launcher.library
/root/.p2/pool/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.1100.v20190907-0426
-product
org.eclipse.epp.package.jee.product
-showsplash
/root/.p2/pool/plugins/org.eclipse.epp.package.common_4.14.0.20191212-1200
--launcher.defaultAction
openFile
--launcher.appendVmargs
-vm
/usr/lib/jvm/java-11-openjdk-amd64/bin
-vmargs
-Dosgi.requiredJavaVersion=1.8
-Dosgi.instance.area.default=#user.home/eclipse-workspace
-XX:+UseG1GC
-XX:+UseStringDeduplication
--add-modules=ALL-SYSTEM
-Dosgi.requiredJavaVersion=1.8
-Dosgi.dataAreaRequiresExplicitInit=true
-Xms256m
-Xmx1024m
--add-modules=ALL-SYSTEM
-Declipse.p2.max.threads=10
-Doomph.update.url=http://download.eclipse.org/oomph/updates/milestone/latest
-Doomph.redirection.index.redirection=index:/->http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/
There is a whole catalog of issues here.
I replaced the relative path for -startup with an absolute one, copied /root/.p2/pool to /usr/local/eclipse/pool and updated the -startup and -showsplash entries in the file.
I got a whole new error message:
!SESSION Fri Feb 19 11:11:27 GMT 2021 ------------------------------------------
!ENTRY org.eclipse.equinox.launcher 4 0 2021-02-19 11:11:27.893
!MESSAGE Could not find extension: reference:file:org.eclipse.osgi.compatibility.state_1.1.600.v20190814-1451.jar
!ENTRY org.eclipse.equinox.launcher 4 0 2021-02-19 11:11:28.070
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
...
I get exactly the same error after converting the Fedora 33 RPM to a .deb and installing that.
I'm going to go check the price of intellij licences.
Related
I am trying to install package control in Sublime Text editor 3 on Ubuntu 14.04 . I follow simple instruction from https://sublime.wbond.net/installation.
But I get follow error:
Package Control: Error downloading channel. b'curl: (7) Failed to connect to sublime.wbond.net port 443: Network is unreachable' downloading https://sublime.wbond.net/channel.json.
error: Package Control
Go back to the installation page and follow the instructions in the Manual section:
Click the Preferences > Browse Packages… menu
Browse up a folder and then into the Installed Packages/ folder
Download Package Control.sublime-package and copy it into the Installed Packages/ directory
Restart Sublime Text
This should install Package Control for you without any problems.
EDIT
Please read through this issue here, and follow wbond's instructions to install from git. First, completely quit Sublime, then remove all traces of Package Control - any folders in ~/.config/sublime-text-3/Packages, any files in ~/.config/sublime-text-3/Installed Packages, the folder ~/.config/sublime-text-3/Packages/User/Package Control.cache, and any files in ~/.config/sublime-text-3/Packages/User that start with Package Control.* - Package Control.last-run, Package Control.sublime-settings, Package Control.system-ca-bundle, and anything else you can find.
Next, assuming you have git installed (run sudo apt-get install git if you don't), switch to ~/.config/sublime-text-3/Packages and run
git clone https://github.com/wbond/package_control.git "Package Control"
to clone the master repo (make sure you've completely quit Sublime before running this). Restart Sublime and see if everything installs properly. If not, follow the instructions for creating a debug log, restart Sublime to generate the log, open the Console by selecting View -> Show Console, then copy the entire contents (it'll be a lot) into a new file. Open a new issue and describe exactly what the problem is, including all the details above and the fact that you just installed from the master branch, and paste in the contents of the debug log (make sure you put it in a code block by adding triple backticks ``` before and after). Will Bond (wbond) should get in touch with some suggestions.
Good luck!
Note for users of other operating systems: I'm not sure if this is a Linux-only problem or not, but in case it isn't, Mac users will find Packages and Installed Packages in ~/Library/Application Settings/Sublime Text 3, while Windows users with standard (i.e., non-portable installs) will find them in your user directory under AppData\Roaming\Sublime Text 3. For Windows portable installs, the directories should be in your install directory under Data.
For the sublime text version 3126 onward Package Control is disabled by default. Just go to Preferences > Settings and remove Package Control from the ignored_packages setting.
I was having the same problem on Linux Mint 18.1 (Ubuntu derivative), and after reading a few posts here and there, it occurred to me that something had likely become corrupted, so I: 1) uninstalled sublime; AND then 2) deleted everything related to sublime from "/home/thom/.config/". Step 2 was the real key. Then I reinstalled sublime according to "apt" section HERE. Once reinstalled, package control was able to install without error.
Consider these 4 pieces of software:
COBRA 2.05
LibSBML 5.10
MATLAB R2013a (Also known as 8.1, 64-bit; MATLAB no longer supports 32-bit Linux anyway)
A 64-bit Linux OS (such as Ubuntu 14.04 or the latest Mint but not restricted to them)
Intro
The COBRA toolbox is an optimization suite that runs on top of MATLAB aimed at the development of MATLAB code for metabolic network modelling. Such a "network" is a system of equations that can have a very large number of equations and variables (such as thousands). Therefore, routines to read and write those large models according to some format specification are a must-have, and COBRA uses the standard SBML for that.
Problem
Unlike the Windows versions, the Linux binary packages do not integrate well out-of-the-box: to begin with, the pre-compiled Linux binary of libSBML (open-source) available for download does not come with MATLAB support. If one tries to use the pre-compiled libSBML, COBRA won't find the "MATLAB bindings" and therefore won't be able to, for example, read and write SBML XML files from the disk in a m-script.
The question
What needs to be done to make COBRA 2.05 running on top of MATLAB R2013a under Linux (Ubuntu 14.04 or the latest Mint, but this is not likely distro-specific) able to read and write SBML XML files? In other words, what needs to be done system-wide to make COBRA pass its own testSBML test?
This is how I got it working and what I could learn from all the hassle regarding how my Linux box works. I hope I am not forgetting/missing/mistaking anything.
1. MATLAB
1.1. Install MATLAB
Install it in its default location (you will need root access for this), don't be stubborn like I tried to be. Why:
1.1.1. Integration
It is very likely you will want to install some other software that uses the MATLAB framework at some point, and in the real world software doesn't always find other software even if you know how to tell it where to look for.
1.1.2. Make your life easier
Even though it seems like a good idea to install a big software in a place where you have lots of available space and that you can use in multiple machines (specially in Linux, which doesn't have that abomination called Registry, and has symbolic links), that would only perhaps be a good idea - apart from item 1.1.1 - if that place is a partition with a Linux filesystem, since at some point, some executable/script will need execution permission, and mounting the entire partition with execution permission for all its files is rather unsafe. Therefore, do not put MATLAB in an NTFS partition of an external HD; perhaps creating a Linux partition in the external HD just for Linux-specific stuff could work for this matter, but how much hassle is that?
1.2. Setup MATLAB so people and other software can launch it
Even though I have seen somewhere that the MATLAB installer eventually shows an option to create symbolic links in the system path for convenience, it didn't in my case. But that is OK, since I would have to replace the symbolic link /usr/local/bin/matlab by the following shell-script (same path, same filename) anyway:
#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH
exec /usr/local/MATLAB/R2013a/bin/matlab $*
OBS: That LD_LIBRARY_PATH is needed for MATLAB to find SBML bindings later and to be able to use them. Also, if you install some third-party solver such as TOMLAB, you will most likely need to add some more paths in this little launcher script.
OBS 2: In my case, the installation script didn't automatically create any launchers or shortcuts, but I have found an iconless and extension-less Matlab 8.01 file and a matlab icon as a png file, and that first file was a template .desktop file that I could edit to fit my needs and put in /usr/share/applications so the Unity Dash would find it. The contents of this Matlab.desktop file are:
[Desktop Entry]
Type=Application
Icon=/usr/local/MATLAB/R2013a/Matlab.png
Name=Matlab 8.01
Comment="Start Matlab 8.01"
Exec=/usr/local/MATLAB/R2013a/bin/matlab -desktop
Categories=Development;
Name=Matlab 8.01
GenericName=Matlab 8.01
Comment="Start Matlab 8.01"
2. libSBML
2.1. Install libSBML
libSBML is provided by a deb package specific for Ubuntu (and for CentOS), and also versions for several flavours of Windows and MacOSX (their home page: http://sbml.org/Software/libSBML). Guess which is the only platform whose binaries weren't compiled with MATLAB support? Linux, of course. That means you will need to compile from source (and that the deb package is therefore useless to you). To compile:
2.1.1. Install dependencies
The dependency libxml2-dev (from software manager or from a terminal):
sudo apt-get install libxml2-dev
2.1.2. Save yourself some time in the future
Usually, one would do configure, make and then make install. But this is not recommended for the same reason as installing anything that doesn't come in a pretty little package: you will loose control of which files went where, and will need to keep the source-code to be able to run make uninstall if you need to uninstall it later. So, install checkinstall and use it to replace the step make install, since checkinstall creates a package for your system that can be later uninstalled or reinstalled just as any regular packaged software (from software manager or from a terminal):
sudo apt-get install checkinstall
2.1.3. Configure the compiling-process
Get LibSBML source code and extract it to some folder. From a terminal, navigate to that folder and configure the compilation:
./configure --with-matlab
OBS: with the with-matlab flag, the configure script will fail it it cannot find an executable whose filename is matlab. If it fails, it outputs that the matlab file could not be found, but the test it performs is actually both for the existence of the file and whether it is executable. So, if the file is in an NTFS partition, configure will fail even if it finds the file, but will tell you the file couldn't be found. You can enforce it to look for the executable in /path/to/matlab/root by passing (it will look for a bin folder inside that path, and for the executable inside that bin folder):
./configure --with-matlab=/path/to/matlab/root
OBS: This will install libSBML in the default location: /usr/local/lib. Again, it is a good idea to just let it install in its default location, but if you need to change it, you can pass the path with the flag: --prefix=/your/installation/path
OBS 2: You might ask why libSBML needs to find and execute matlab to be compiled with support for it: it needs to fire up MATLAB later to build MEX-files (compiled MATLAB code), so I would speculate you wouldn't be able to install libSBML after all if your MATLAB has no compiler to generate MEX-files.
2.1.4. Build and install libSBML
make
checkinstall
VERY IMPORTANT OBS:
I) checkinstall asks for confirmation of the metadata of the package it is about to create. In my case, the string for the version field came by default as "Source" (without the quotes), which caused checkinstall to fail because dpkg (the system tool that actually builds the deb file) failed complaining the version number must start with, well, a number. So, save yourself some time and make sure the string in the version field starts with a number (i.e. "5.10", without the quotes obviously)
II) checkinstall asks if you want to exclude from the future package files that the make install command would put in your home folder and says it is a good idea to exclude them. LibSBML has a test.xml file that it needs to be in the $HOME folder later, or else it won't let you integrate with MATLAB. And even though it tells you a test.xml is missing, it doesn't tell you where that file should be or if that file was something that came with the library. I only noticed it because checkinstall had found a $HOME/test.xml reference earlier (that I excluded from the package, of course) and I had found that odd. So, save yourself some time and exclude $HOME/test.xml from the package generated by checkinstall, and then search for test.xml inside the source-code folder and copy it to $HOME as soon as libSBML finishes being installed by checkinstall.
2.2. Integrate libSBML to MATLAB
Fire up MATLAB, navigate to where the SBML MATLAB-bindings were installed in step 2.1.5 (in my case: /usr/local/lib) and run the file installSBML.m that should be there.
2.2.1. Shared libraries problems
In my case, I had an error due to an old unresolved issue: libstdc++.so.6 not having a reference to GLIBCXX_3.4.15. Turns out that MATLAB was trying to use a libstdc++.so.6.0.13 (libstdc++.so.6 was a symbolic link pointing to this file) that came with it in /usr/local/MATLAB/R2013a/sys/os/glnxa64, which indeed didn't have that reference (one could verify that by issuing:
strings /usr/local/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6.0.13 | grep GLIBC
). My system has a libstdc++.so.6.0.19 located in /usr/lib/x86_64-linux-gnu that has that reference, so I enforced MATLAB to use 6.0.19 one by setting the LD_LIBRARY_PATH properly (refer to step 1.2) and also by renaming the libstdc++.so.6 that came with MATLAB to something else so it would not find it and would keep looking until it found my system's. A friend of mine running Linux Mint didn't need to rename anything: for him, setting the LD_LIBRARY_PATH was enough.
2.2.2. Other problems
installSBML.m will fail if it doesn't find that $HOME/test.xml file mentioned in step 2.1.5, regardless of whether the library actually works. It assumes that if it could not test itself using a file that it assumes to be in $HOME, the user shouldn't have the option to install it anyway.
3. COBRA / SBML toolbox
3.1. Setup COBRA
In MATLAB, navigate to <YOUR_COBRA_ROOT_FOLDER_HERE>/external/toolboxes/SBMLToolbox-4.1.0/toolbox and run the file install.m there. You should have all set so it finds the MATLAB-bindings you set up in step 2.2.
3.2. MATLAB setpaths problems
I had to manually edit the file /usr/local/MATLAB/R2013a/toolbox/local/pathdef.m as root to include the folder /usr/local/lib (where libSBML and its MATLAB-bindings are) to make that setting persistent. Every time I restarted MATLAB, its setpath had gone back to the default, no matter if I started MATLAB as root when setting its setpath via the MATLAB GUI.
3.3. Test
Now you have hopefully connected all the dots. Try it: in MATLAB, navigate to <YOUR_COBRA_ROOT_FOLDER_HERE> and issue:
initCobraToolbox
testAll
If you haven't got any third-party solvers installed and configured, it should pass 14 of the 19 tests, including the SBML test (testSBML). Now you can load SBML files into MATLAB and play with them.
I also needed to add a symbolic link from /usr/local/lib/libsbml.so.5 to the MATLAB sys folder by:
sudo ln -s /usr/local/lib/libsbml.so.5 /usr/local/MATLAB/R2014a/sys/os/glnxa64/
This finally made the installation possible.
I installed using Cmake. To do this it is necessary to find the FindMatlab.cmake in the source package and insert the MATLAB path manually!
.............
elseif(EXISTS "/Applications/MATLAB_R2008a.app/")
set(MATLAB_ROOT_PATH "/Applications/MATLAB_R2008a.app/")
endif()
else()
if (EXISTS "/usr/local/MATLAB/R2014a/")
set(MATLAB_ROOT_PATH "/usr/local/MATLAB/R2014a/")
endif()
endif()
..........
FYI, to resolve the shared library issue at point 2.2.1 I needed to install the package matlab-support (in Ubuntu repositories)
I have created an Ubuntu package to install my RCP app. The installed files are owned by root. Is it possible for a user to subsequently install updates through P2? Documentation about Eclipse multi-user installs suggests that it is possible, along with the answer to this question.
However, when I start up the application, it does not automatically check for updates as usual, and the Update Site that I had specified in p2.inf is not listed in the "Install New Software..." dialog.
Using the -configuration or -data runtime options did not help.
I can make it work with a hack by running sudo chown -R <my_username> /opt/<my_app_installation>. When I subsequently launch the application, it does properly check for updates on startup, and my update site is properly listed in the "Install New Software..." dialog. Certainly I would prefer that whatever data it is writing to that installation directory be instead written to the user's home directory.
Supplementary info:
Here is a list of files and folders that showed up in my installation directory only after the directory was given ownership by <my_username> and the program was run.
/opt/<my_app_installation>/configuration/org.eclipse.core.runtime
/opt/<my_app_installation>/configuration/org.eclipse.equinox.app
/opt/<my_app_installation>/configuration/org.eclipse.osgi
/opt/<my_app_installation>/p2/org.eclipse.equinox.p2.engine/profileRegistry/profile.profile/1339896994308.profile.gz
/opt/<my_app_installation>/p2/org.eclipse.equinox.p2.engine/profileRegistry/profile.profile/.data/.settings/org.eclipse.equinox.p2.ui.sdk.prefs
/opt/<my_app_installation>/p2/org.eclipse.equinox.p2.engine/profileRegistry/profile.profile/.data/.settings/org.eclipse.equinox.p2.ui.sdk.scheduler.prefs
/opt/<my_app_installation>/p2/org.eclipse.equinox.p2.repository
More experimental results:
Even with a writable (chown'd) installation directory, no files are placed there when the
-configuration $HOME/.my_app_files runtime option is supplied.
There are lots of limitation of p2 itself for share install. AFAIK there is no significant improvement in latest release Juno as well.
But a guy from Redhat is working on p2 install with RPM package, you can read his progress in his blog post. The work and idea could be shared with Debian package.
I've just been setting up a Ubuntu workstation and wanted to add some settings to eclipse.ini. When I searched for the file I found:
/etc/eclipse.ini
/usr/lib/eclipse.ini
My questions are:
Does Eclipse actually use both files?
If so, in what order does it read them?
How does it merge them?
Both of the files I found are system wide, is there a location in my home directory I could put one that would effect only my instances?
Here's how to determine which eclipse.ini file you should use (joomla.org):
If you downloaded Eclipse IDE manually from internet the "eclipse.ini" file is just inside the unpacked folder
If you installed Eclipse via terminal or software center the location of the file is "/etc/eclipse.ini"
In some Linux versions the file can be found at "/usr/share/eclipse/eclipse.ini". Do not use this file if you found a config file at "/etc/eclipse.ini".
To be sure where your Eclipse folder is, check $ECLIPSE_HOME, and if not specified (these directions at least work for Juno):
Open Eclipse as you normally do.
Click Help -> About Eclipse SDK
Click Installation Details
Go to the Configuration tab
Find "eclipse.home.location=file:PATH". PATH is where eclipse is installed.
sources:
http://docs.joomla.org/Configuring_Eclipse_IDE_for_PHP_development/Linux:
There is only one file.
lrwxrwxrwx 1 root root 16 Aug 8 2012 /usr/lib/eclipse/eclipse.ini -> /etc/eclipse.ini
You probably have already found this out, chances are when you installed Eclipse the installation created (or you did manually) a file /usr/bin/eclipse which if you check it probably looks like the following:
#!/bin/sh
export ECLIPSE_HOME="/opt/eclipse"
$ECLIPSE_HOME/eclipse $*
especially if you followed instructions similar to the ones like these on If-not-true-then-false
On the other hand if you have installed from a package, I suspect you will find that eclipse ends up in /usr/bin, most likely a symbolic link to /usr/lib/eclipse/eclipse (or at least I found it on my Fedora system after using yum to install eclipse).
I have Ubuntu 18 and eclipse installation is squashed in a file
/var/lib/snapd/snaps/eclipse_40.snap
which is mount on /snap/eclipse/40 as read only. Just run
mount | grep eclipse*.snap
This eclipse.ini file is really read only, that means, you cannot modify it, even with sudo. However, I also have a eclipse.ini.ignored file in HOME/.eclipse/some number/configuration. This is being by default ignored, but you can change the "launcher.ini" in the eclipse launcher command.
According to https://wiki.eclipse.org/Eclipse.ini
Eclipse startup is controlled by the options in
$ECLIPSE_HOME/eclipse.ini. If $ECLIPSE_HOME is not defined, the
default eclipse.ini in your Eclipse installation directory (or in the
case of Mac, the Eclipse.app/Contents/MacOS directory) is used.
The certain way to make sure is to run strace on eclipse. In the output you'll see where is eclipse actually trying to pull the file from.
I´m doin a unattended cygwin installation and I was wondering if there will occure any problems without a setup.ini.
Following: my "install-folder" includes a setup.exe and a subfolder release (within all the packages packed).
I´m starting the setup silent (with Nsis) and install the packages. In NSIS I define the Root, the location of the packages etc.
I think it works so far (I´m not sure because i´ve got a curious error in cmake). There are many instructions how to modify the whole setup for an offline installation. But I don´t get the point why I have to modify it at all.
I hope anyone has got experience with this issue!
#Daniel Le cygwin installs the packages without the .ini (all of them). And there has nothing to be downloaded because the packages are on the local machine.
I believe the setup.ini is essential to the setup process, as it indicates which packages to be downloaded and installed.
The Ini file is so far only a description for file locations and paths to be set as default. It is not necessary to have the ini file if you wanna install some packages!
That´s my conclusion.