Community
Participate
Working Groups
Build Identifier: 20090920-1017 In project A's Java Build Path, a native library location containing A.dll is specified for project A's source folder. A Run Configuration is created in project B. The code executed by the run configuration depends on Java code from project A and on A.dll. If project A is added to project B's Java Build Path, the native library location is included when the run configuration is executed, and A.dll is found. However, if project A is _not_ added to project B's Java Build Path, but is instead added under User Entries to the run configuration's Classpath, A.dll is not found. This difference in outcomes depending on the method of classpath inclusion seems inconsistent. Reproducible: Always Steps to Reproduce: 1. Create project A. 2. Create a Test class in project A with a main method that attempts to System.loadLibrary("A"). 2. Specify A.dll's location as the native library location for project A's source folder. 3. Create project B. 4. Create a new Run Configuration. 5. Set the run configuration's Project to be project B. 6. Set the run configuration's Main class to be Test. 7. Add project A under User Entries in the run configuration's Classpath. 8. Run the run configuration. 9. Add project A to project B's Java Build Path. 10. Re-run the run configuration.
Move to JDT/Debug
I also have an issue with native library, it sound like it originate from the same bug, but I could be wrong. If I add an external package, the application cannot find the referenced native library, except in the case specified at the below: If my workspace consists of a single project, and I import an external package 'EX_package.jar' from a folder outside of the project folder, I can assign a folder to the native library location via: mouse over package -> right click -> properties -> Native Library -> Enter your folder. This does not work. In runtime the application does not load the library, System.mapLibraryName(Path) also does not work. Further more, if I create a User Library, and add the package to it and define a folder for the native library it still does not. If it works for you then I have a major bug since it does not work on my computer I test this in any combination I could think of, including adding the path to the windows PATH parameter, and so many other ways I can't even start to remember, nothing worked, I played with this for hours and had a colleague try to assist me, but we both came up empty. Further more, if I have a main project that is dependent on few other projects in my workspace, and they all need to use the same 'EX_package.jar' I MUST supply a HARD COPY INTO EACH OF THEM, it will ONLY (I can't stress the ONLYNESS, I got freaked out by this) work if I HAVE A HARD COPY of the package in ALL of the project folders that the main project has a dependency on, and ONLY if I configure the Native path in each of them!! please tell me there is a solution to this, coping 10 files and assigning to lib to them every time drives me nuts... Thanks, Adam Zehavi.
Based on the original bug report, and examining the code, I can confirm that the "java.library.path" is computed at launch time from the project and required projects being launched. Extra entries on the runtime classpath are not currently considered (which is a bug). (In reply to comment #2) > I also have an issue with native library, it sound like it originate from the > same bug, but I could be wrong. The setup in comment #2 is not clear to me, so I'm not sure it's the same bug. Could you attach example projects with the problematic setup?
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.
