Community
Participate
Working Groups
After performing one click update platform does not restart due to the wrong persmissions on the downloaded SWT libaries. See bug 18376, where permissions were wrong in the new installation of Eclipse. Note, I have renamed the hp9000 directory to the PA_RISC directory inside the updated swt plugin, because I was running Eclipse with -arch PA_RISC option, and libraries would not be found at all otherwise. % ./eclipse -arch PA_RISC -vm /opt/java1.3/jre/bin/java java.lang.UnsatisfiedLinkError: /bluebird/teamswt/kkolosow/eclipse/plugins/org.e clipse.swt.motif_2.0.0.v2045/os/hpux/PA_RISC/libswt-motif-2045.sl: Permission denied at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:102) at org.eclipse.swt.internal.motif.OS.<clinit>(OS.java:14) at org.eclipse.swt.widgets.Display.createDisplay(Display.java:505) at org.eclipse.swt.widgets.Display.create(Display.java:491) at org.eclipse.swt.graphics.Device.<init>(Device.java:110) at org.eclipse.swt.widgets.Display.<init>(Display.java:317) at org.eclipse.swt.widgets.Display.<init>(Display.java:314) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1142) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:739) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:248) at org.eclipse.core.launcher.Main.run(Main.java:697) at org.eclipse.core.launcher.Main.main(Main.java:530) %
From: Konrad Kolosowski/Toronto/IBM@IBMCA Subject: http://dev.eclipse.org/bugs/show_bug.cgi?id=20305 On HP, shared libraries need to have r-x permissions (no write). On other Unixes, shared libraries do not need execute permission. There is no API to read permission from the zip in Java. The permissions inside a zip file is not a standard zip feature. That is why tar.gz is used to distribute files on Unixes today rather than zip. AIX and HP do not even ship with zip/unzip programs. To fix only this bug, we can do a hack: check if running of HP and file ends with .sl (shared library), then call Runtime.exec(chmod ...). I think there is a bigger problem, not mentioned in the bug: If a plug-in ships a main executable file (not a library), that file when updated will get default permissions and is not going to execute on any non windows platform, not just HP. There is no way to guess what the permission should be from file name in this case. The solution can be to change the format that updates are packaged. It can be a zip and an additional file with file permissions, or completely proprietary "Eclipse" format. In any case build tool would be probably needed - not a pretty solution.
F4 candidate Value: high (able to run on HPUX after update) Risk: if the fix is limited to the chmod slam on HPUX (as suggested) then low. Will need better solution for 2.0. A workaround for the general problem would be for the packager to provide a custom install handler for the feature that does the permission "fixup"
just a correction ... "will need a better solution after 2.0"
The suggested hack of chmod'ing downloaded *.sl files on HP-UX sounds reasonable. While eclipse clearly must do it for SWT, it remains to be seen how common it is for ISVs to be including HP-UX executables. If it rarely happens in practice, the suggested workaround of using a custom installer may be sufficient.
Fix to change permissions on *.sl files on HPUX went into 20020621 integration build.
Verified in 20020621 integration build. File permissions are set to r-xr-xr-x on SWT libraries and Eclipse comes up O.K. ufter updating entire SDK.
Question: I assume that this check has been added to the Update component specifically, and therefore wouldn't apply to the following situations: - retrieving SWT from CVS, then trying to self-host - retrieving SWT through Import -> Plugins and Frgaments, then trying to self-host I ask because I want to verify that these situations should be readme'd.
The fix only affects Update code. Permissions are changed on the files that Update retrieves from update site and installs under plugins directory. If there is problems with permission of files in the workspace, it would not be affected by the update fix.
