Bugzilla – Full Text Bug Listing
| Summary: | Bundle-NativeCode doesn't recognize Windows 7 Ultimate installations | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Russ Loucks <rjl> |
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | tjwatson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
|
Description
Russ Loucks
(In reply to comment #0) > The org.osgi.os.name variable shows 'Windows7". I assume you mean org.osgi.framework.os.name? > The os.name variable shows 'Windows 7'. This should work because "Windows 7" and "win32" can be used to alias Windows7 according to http://www.osgi.org/Specifications/Reference Do you happen to have multiple libraries that depend on each other? (In reply to comment #1) > (In reply to comment #0) > > The org.osgi.os.name variable shows 'Windows7". > > I assume you mean org.osgi.framework.os.name? That is correct. (sorry about that). > > > The os.name variable shows 'Windows 7'. > > This should work because "Windows 7" and "win32" can be used to alias Windows7 > according to http://www.osgi.org/Specifications/Reference Would be nice, wouldn't it... ;) > > Do you happen to have multiple libraries that depend on each other? I have multiple libraries and some do depend on each other. However, the one in question does not depend on any other libraries. Here's what I have for my Bundle-NativeCode (sorry, I obfuscted the lib names, but the names are consistent - '<lib1>' in one line is the same library in another line): Bundle-NativeCode: /lib/<lib1>.dll ; /lib/<lib2>.dll ; /lib/<lib3>.dll ; /lib/<lib4>.dll ; /lib/<lib5>.dll ; /lib/<lib6>.dll ; osname = Windows7 ; processor = x86, /lib/<lib1>.dll ; /lib/<lib2>.dll ; /lib/<lib3>.dll ; /lib/<lib4>.dll ; /lib/<lib6>.dll ; osname = Win32 ; processor = x86, /lib/libDSPLibrary.so ; osname = Linux ; processor = x86, /lib/libDSPLibrary.jnilib ; osname = Mac OS X ; processor = x86_64 In this case, <lib2> depends on <lib3>. The <lib5> library in the 'Windows7' line is the bugger here. it is only needed on Windows7 an no other systems. I can't get OSGI to find that library. If I just copy that library to a directory in my PATH, the Eclipse library loader finds it when I run my RCP app. (In reply to comment #2) > Bundle-NativeCode: > /lib/<lib1>.dll ; /lib/<lib2>.dll ; /lib/<lib3>.dll ; /lib/<lib4>.dll ; > /lib/<lib5>.dll ; /lib/<lib6>.dll ; > osname = Windows7 ; processor = x86, > /lib/<lib1>.dll ; /lib/<lib2>.dll ; /lib/<lib3>.dll ; /lib/<lib4>.dll ; > /lib/<lib6>.dll ; > osname = Win32 ; processor = x86, Windows 7 and win32 are equal. Win32 is an alias for Windows 7. So the framework just picks one. Since they are that same except for lib5 which is only need on Windows 7, just java a single Win32 clause with all the libs. The framework will make them all available for loading yet your code will only load lib5 on a Windows 7 system. All right. I had a chance to work on this special system again. Again, what I'm trying to do works on Windows 7 Professional systems; however, it does not work on Windows 7 Ultimate. I tried the game of a single 'Win32' line and included all of the libraries, including the Windows7-specific library and the rest of the libraries, regardless of the Windows version (e.g., they work on Windows 7, Vista, XP, etc.). It looks like: Bundle-NativeCode: /lib/<lib1>.dll ; /lib/<lib2>.dll ; /lib/<lib3>.dll ; /lib/<lib4>.dll ; /lib/<lib5>.dll ; /lib/<lib6>.dll ; osname = Win32 ; osname = "Windows 7" ; osname = "Windows Server 2008" ; osname = "Windows Server 2008 R2" ; processor = x86 I added the Win7 specific library in the one 'windows' line and called it <lib6> above. All other libraries are found (loaded correctly) on my Windows 7 Ultimate system. (Note the 'Windows Server 2008' and 'Windows Server 2008 R2' osnames in the line. There's a related bug that forces us to explicitly name those OS names when our software runs on those systems. Fortunately, that workaround works...). But back to the Win7 specific issue. The Win7 specific library (called <lib6> above) does *not* load on the Windows7 Ultimate system. The bug persists..... (In reply to comment #4) > But back to the Win7 specific issue. The Win7 specific library (called <lib6> > above) does *not* load on the Windows7 Ultimate system. The bug persists..... Does any java code call System.loadLibrary on lib6? This is necessary to get it loaded in the vm process. (In reply to comment #5) > (In reply to comment #4) > > But back to the Win7 specific issue. The Win7 specific library (called <lib6> > > above) does *not* load on the Windows7 Ultimate system. The bug persists..... > > Does any java code call System.loadLibrary on lib6? This is necessary to get it > loaded in the vm process. Absolutely it does. If I just copy the 'lib6' library to a directory that is in my java.library.path (e.g., my RCP installation directory), the library is loaded. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |