RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302

[Kevin Rushforth]

Is there a way you can link the launcher (e.g., something similar to 
RPATH on Unix systems) to look in the right place relative to the 
launcher? Otherwise, the solution with adding to the PATH seems OK to me.

-- Kevin


On 5/12/2020 5:22 AM, Andy Herrick wrote:
> Is the problem that by removing the copy of the microsoft dlls from 
> the applications bin directory, then on machines that do not have all 
> of these dll's already in the PATH (usually in C:\windows\system32) 
> they can no longer be found ?
>
> I don't like manually manipulating the PATH env variable either, but 
> if so I don't see what else can be done short of putting the app exe 
> in the bin dir of the runtime.
>
> /Andy
>
>
> On 5/11/2020 9:37 PM, Alexander Matveev wrote:
>> Hi Alexey,
>>
>> Updating PATH does not look like good solution to me. Did you try to 
>> load jli.dll by specifying full path to jli.dll when calling 
>> LoadLibary? If it does not work, then for AddDllDirectory() did you 
>> used LoadLibrary() or LoadLibraryEx() with 
>> LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you need to use 
>> LoadLibraryEx() with flag when using AddDllDirectory().
>>
>> Thanks,
>> Alexander
>>
>> On 5/11/2020 4:36 PM, Alexey Semenyuk wrote:
>>> Please review fix [2] for jpackage bug [1].
>>>
>>> Fix failure to load jli.dll from app launcher. The fix is to append 
>>> path to directory with jli.dll to PATH env variable and load jli.dll 
>>> with altered value of PATH if the first attempt to load jli.dll 
>>> without altering PATH fails.
>>>
>>> - Alexey
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8244634
>>>
>>> [2] http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00
>>>
>>