Eclipse 3.0 DLL-loading with cyclic dependencies [message #272686] |
Sat, 25 September 2004 11:13  |
Eclipse User |
|
|
|
Originally posted by: edmund_reinhardt.yahoo.ca
I was told that if DLLs are in the "os/win32" subdirectory they can be
loaded via System.loadLibrary() for native JNI access. It was explained to
me that the "os\win32" directory was added to the search path for loading
DLLs.
This works for statically linked DLLs that do not cyclically link to each
other or dynamically link other DLLs.
But when we tried to do this cyclically linked DLLs we got Exceptions
thrown. Is this a hard limitation of Eclipse's DLL loading support. It
seems to contradict what I was told about "os\win32" being added to the DLL
loading search path?
Can someone set me straight on what is or is not possible and why?
We would really appreciate it.
|
|
|
|
|
Re: Eclipse 3.0 DLL-loading with cyclic dependencies [message #272705 is a reply to message #272698] |
Sun, 26 September 2004 09:53   |
Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
The light is not really shiny.
I feel like this is a bug (or something that is not possible with
eclipse). Please enter one against Platform > Runtime summarizing the
problem. Thx.
My two cents on what is happening
Basically, when we say it's on the library path, it is not the exact
truth because we do not modify the value of this variable. Instead, it
is the eclipse classloader which calls several times the loadLibrary()
in the various locations (os, os/win32, ...).
Therefore when a dll load another, it feels like the jvm does not
redelegate the loading of the library to the classloader, which
therefore causes the problem you see.
PaScaL
Edmund Reinhardt wrote:
> Thanks for asking
>
> All DLLs are in os\win32
> If A links to B links to C
> Then I can load C, then B then A using System.loadLibrary() and we are all
> happy.
>
> However if A links to B links to C links to A, then no matter which DLL I
> start with, System.loadLibrary throws an exception.
> You are absolutely right that it if I try loading A, the error will be that
> it cannot find B on the current path.
>
> If 'os\win32' were truly in the path as advertised, then loading A would
> discover B and C in the path and no exception would be thrown.
>
> Can someone show some light?
>
> .
> "Pascal Rapicault" <pascal@ibm.canada> wrote in message
> news:cj58lc$n48$1@eclipse.org...
>
>>Just to make sure that I did not get it wrong:
>>You can load a dll from os/win32 using System.loadLibrary() but when the
>>dll itself tries to load another dll, then it fails? Correct?
>>
>>Where is located the second library? In the same os/win32 folder?
>>
>>PaScaL
>>
>>Edmund Reinhardt wrote:
>>
>>
>>>I was told that if DLLs are in the "os/win32" subdirectory they can be
>>>loaded via System.loadLibrary() for native JNI access. It was explained
>
> to
>
>>>me that the "os\win32" directory was added to the search path for
>
> loading
>
>>>DLLs.
>>>
>>>This works for statically linked DLLs that do not cyclically link to
>
> each
>
>>>other or dynamically link other DLLs.
>>>
>>>But when we tried to do this cyclically linked DLLs we got Exceptions
>>>thrown. Is this a hard limitation of Eclipse's DLL loading support. It
>>>seems to contradict what I was told about "os\win32" being added to the
>
> DLL
>
>>>loading search path?
>>>
>>>Can someone set me straight on what is or is not possible and why?
>>>
>>>We would really appreciate it.
>>>
>>>
>
>
>
|
|
|
Re: Eclipse 3.0 DLL-loading with cyclic dependencies [message #273199 is a reply to message #272686] |
Fri, 01 October 2004 11:38  |
Eclipse User |
|
|
|
Originally posted by: edmund_reinhardt.yahoo.ca
Just to conclude this thread. I did open a bug report and I was told that
the JVM does not have any opportunity to get involved when a native DLL
tries to load another DLL so this is a limitation of Eclipse.
"Edmund Reinhardt" <edmund_reinhardt@yahoo.ca> wrote in message
news:cj41mc$es5$1@eclipse.org...
> I was told that if DLLs are in the "os/win32" subdirectory they can be
> loaded via System.loadLibrary() for native JNI access. It was explained
to
> me that the "os\win32" directory was added to the search path for loading
> DLLs.
>
> This works for statically linked DLLs that do not cyclically link to each
> other or dynamically link other DLLs.
>
> But when we tried to do this cyclically linked DLLs we got Exceptions
> thrown. Is this a hard limitation of Eclipse's DLL loading support. It
> seems to contradict what I was told about "os\win32" being added to the
DLL
> loading search path?
>
> Can someone set me straight on what is or is not possible and why?
>
> We would really appreciate it.
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.04872 seconds