Bug 832053 - Investigate why *.so are present in .eclipse
Investigate why *.so are present in .eclipse
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
17
All Linux
high Severity high
: ---
: ---
Assigned To: Krzysztof Daniel
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-14 07:54 EDT by Krzysztof Daniel
Modified: 2014-01-12 19:27 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 02:51:00 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Krzysztof Daniel 2012-06-14 07:54:06 EDT
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
Comment 1 Krzysztof Daniel 2013-01-02 09:32:14 EST
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.
Comment 2 Alexander Kurtakov 2013-01-02 09:42:18 EST
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.
Comment 3 Krzysztof Daniel 2013-01-02 11:11:15 EST
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.
Comment 4 Krzysztof Daniel 2013-01-02 12:50:43 EST
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).
Comment 5 Krzysztof Daniel 2013-01-03 01:50:34 EST
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).
Comment 6 Krzysztof Daniel 2013-01-07 06:09:24 EST
There may be something I can do upstream.
Comment 7 Krzysztof Daniel 2013-01-22 09:07:53 EST
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.
Comment 8 Krzysztof Daniel 2013-01-25 13:26:02 EST
There is new hope :-).
Comment 9 Krzysztof Daniel 2013-02-13 02:51:00 EST
Fixed by extracting plugins with *.so during the build.

Note You need to log in before you can comment on or make changes to this bug.