Those files should not be present here: [kdaniel@kdanielX220Fedora bundles]$ pwd /home/kdaniel/.eclipse/org.eclipse.platform_4.2.0_793567567/configuration/org.eclipse.osgi/bundles [kdaniel@kdanielX220Fedora bundles]$ find . -name *.so ./154/2/.cp/os/linux/x86_64/libunixfile_1_0_0.so ./105/2/.cp/os/linux/x86_64/libspawner.so ./711/2/.cp/libswt-cairo-gtk-4229.so ./711/2/.cp/libswt-pi-gtk-4229.so ./711/2/.cp/libswt-atk-gtk-4229.so ./711/2/.cp/libswt-webkit-gtk-4229.so ./711/2/.cp/libswt-gtk-4229.so [kdaniel@kdanielX220Fedora bundles]$ But what is interesting, they *are* extracted where it is required: [kdaniel@kdanielX220Fedora eclipse]$ pwd /usr/lib64/eclipse [kdaniel@kdanielX220Fedora eclipse]$ find . -name "*.so" ./libswt-awt-gtk-4229.so ./libswt-atk-gtk-4229.so ./libswt-webkit-gtk-4229.so ./libswt-glx-gtk-4229.so ./libswt-cairo-gtk-4229.so ./libswt-pi-gtk-4229.so ./libswt-gtk-4229.so ./plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20120426-1529/eclipse_1503.so ./configuration/org.eclipse.osgi/bundles/43/2/.cp/libgnomeproxy-1.0.0.so ./configuration/org.eclipse.osgi/bundles/158/2/.cp/libswt-awt-gtk-4229.so ./configuration/org.eclipse.osgi/bundles/158/2/.cp/libswt-atk-gtk-4229.so ./configuration/org.eclipse.osgi/bundles/158/2/.cp/libswt-webkit-gtk-4229.so ./configuration/org.eclipse.osgi/bundles/158/2/.cp/libswt-glx-gtk-4229.so ./configuration/org.eclipse.osgi/bundles/158/2/.cp/libswt-cairo-gtk-4229.so ./configuration/org.eclipse.osgi/bundles/158/2/.cp/libswt-pi-gtk-4229.so ./configuration/org.eclipse.osgi/bundles/158/2/.cp/libswt-gtk-4229.so ./configuration/org.eclipse.osgi/bundles/40/2/.cp/os/linux/x86_64/libunixfile_1_0_0.so
My current understanding is that Eclipse processes cascaded configuration, not cascaded temp location for osgi innern files, therefore the /usr/lib*/eclipse/configuration/org.eclipse.osgi/* is completely ignored... I don't think I can change it.
Krzysztof, there is o.e.equinox.initializer which was used to fix this issue. See http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.eclipse-build.git/tree/eclipse-build/build.xml#n930 for details.We need to fix that as this was causing a problem before due to our so files having same version-qualifier but different contents due to patches (this might have been fixed lately?). Still we would better not have so files copied to ~/.eclipse as this was causing problems with nfs-mounted homes.
Alex, I'm aware of the initializer, and I do call it in eclipse.spec. The problem is that initializer correctly extracts libs in /usr/lib64/eclipse/configuration, but Eclipse ignores them because of a cascaded configuration and falls back on user home. I will check the osgi implementation to see how it searches for paths.
My system has: /usr/lib64/eclipse/configuration/org.eclipse.osgi/bundles/35/1/.cp/os/linux/x86_64/libunixfile_1_0_0.so and .eclipse/org.eclipse.platform_4.2.0_793567567/configuration/org.eclipse.osgi/bundles/143/1/.cp/os/linux/x86_64/libunixfile_1_0_0.so The most important bit here is the number between bundles/ and /1 which is the number of the Osgi bundle. The problem is that those numbers are not constant. The may change each time the configuration is changed (new packages are installed using dropins) or eclipse -clean is called. The read-only configuration just cannot work. The only thing that initializer was doing was extracting so's and allowing for further processing of them, and, in some-cases, preventing from unpacking in user.home, but only if the assigned numbers were matching (but since now we are using reconciler heavily, the chances for that are next to 0).
Alex, I found this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=90540c2 "The 6 depends on the order in which plugins get installed in osgi. This order is uncontrolled. The only way to know is to run once which does not mean to run a UI. For example you can try running with -initialize." This means that we can't eliminite *.so files from user.home (unless we heavily patch OSGi itself).
There may be something I can do upstream.
For the record: The issue was introduced by sorting the bundles.info. Earlier bundles.info was unsorted, and new content was just appended. After sorting bundles.info, the id (number) of bundles assigned by OSGi is changed, and therefore it is not possible to reuse the *.so files anymore. The patch cannot be reverted, because bundles needs to be sorted after the version to ensure that always the latest bundle is wired when import-package is used. We can't have both sortings at once.
There is new hope :-).
Fixed by extracting plugins with *.so during the build.