On Fri, 9 May 2025 17:42:14 GMT, Benjamin Peterson wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
>> called on the target library file before it is passed to the system library
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman wrote:
>> Would it be possible to paste in here, or in the JBS issue, some examples of
>> the path provided to LoadLibrary with some commentary on the sym links
>> created on the file system.
>
>> You might be correct. We'll see what @AlanBateman an
On Fri, 9 May 2025 09:10:21 GMT, Alan Bateman wrote:
> Is this documented in the Microsoft document for LoadLibrary? We don't want
> to rely on undocumented behavior as it could break at any time.
[LoadLibraryEx`
documentation](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/n
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
> called on the target library file before it is passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
> symlinks on Windows. This had unintended consequences for pass
On Thu, 8 May 2025 19:39:17 GMT, Benjamin Peterson wrote:
>> The appending of the "." is specific to the case where there isn't a .dll
>> suffix.
>
> `LoadLibrary` appears to happily load files with a `.dll` extension even if a
> trailing `.` is appended. So, special casing doesn't appear neces
On Thu, 8 May 2025 19:13:46 GMT, Alan Bateman wrote:
>> Conditional on what?
>
> The appending of the "." is specific to the case where there isn't a .dll
> suffix.
`LoadLibrary` appears to happily load files with a `.dll` extension even if a
trailing `.` is appended. So, special casing doesn'
On Thu, 8 May 2025 19:05:56 GMT, Benjamin Peterson wrote:
>> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line
>> 124:
>>
>>> 122: return null;
>>> 123: }
>>> 124: name = file.getCanonicalPath() +
>>> ClassLoaderHelper
On Thu, 8 May 2025 19:00:26 GMT, Alan Bateman wrote:
>> Benjamin Peterson has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix spelling
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 124:
>
>> 122:
On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
>> called on the target library file before it is passed to the system library
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
>> called on the target library file before it is passed to the system library
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Thu, 8 May 2025 17:43:31 GMT, Benjamin Peterson wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
>> called on the target library file before it is passed to the system library
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
> called on the target library file before it is passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
> symlinks on Windows. This had unintended consequences for pass
On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman wrote:
> > You might be correct. We'll see what @AlanBateman and others have to say
> > about it.
>
> I'm still puzzled as to why the DLLs have been moved from the JDK bin
> directory to some other location, and renamed so they don't have the ".dll
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
> called on the target library file before it is passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
> symlinks on Windows. This had unintended consequences for pass
On Wed, 7 May 2025 19:05:17 GMT, Alan Bateman wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
>> called on the target library file before it was passed to the system library
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>> s
On Wed, 7 May 2025 23:21:20 GMT, Benjamin Peterson wrote:
> > So is it correct to say that the link resolution appears correct but
> > `LoadLibrary`'s quirks cause the intended behavior to fail?
>
> Yes. The `getCanonicalPath` canonicalization indeed produces the file pointed
> to by the symli
On Wed, 7 May 2025 23:02:41 GMT, Brian Burkhalter wrote:
> > > > At this point, the path to load will be `$PWD\rando` due to symlink
> > > > resolution.
> > >
> > >
> > > Which is in fact correct, no?
> >
> >
> > Correct in that that's the library that should be loaded. `LoadLibrary`
> > do
On Wed, 7 May 2025 21:47:37 GMT, Benjamin Peterson wrote:
> > > At this point, the path to load will be `$PWD\rando` due to symlink
> > > resolution.
> >
> >
> > Which is in fact correct, no?
>
> Correct in that that's the library that should be loaded. `LoadLibrary`
> doesn't want to cooper
On Wed, 7 May 2025 21:19:41 GMT, Brian Burkhalter wrote:
> > > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value
> > > .\rando
>
> What if instead this were the following
>
> ```
> > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value
> > .\rando.dll
> ```
On Wed, 7 May 2025 19:21:38 GMT, Benjamin Peterson wrote:
> > New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value .\rando
What if instead this were the following
> New-Item -Path .\jdk-24\bin\jimage.dll -ItemType SymbolicLink -Value
> .\rando.dll
where `.dll` is appended to t
On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote:
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
> called on the target library file before it was passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote:
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
> called on the target library file before it was passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Wed, 7 May 2025 17:28:23 GMT, Alan Bateman wrote:
> Are you the submitter of JDK-8348828?
Yes, I am.
> Asking because the configuration described seems very unusual and sounds like
> something that changed the JDK image so the DLLs from the JDK bin directory
> are moved to somewhere else a
On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote:
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
> called on the target library file before it was passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Mon, 28 Apr 2025 17:44:31 GMT, Benjamin Peterson wrote:
>> This issue has the "oca" label so we cannot engage, sorry.
>
>> This issue has the "oca" label so we cannot engage, sorry.
>
> Ah, sorry. I only asked because I saw a colleague of yours helping out with
> OCA verification over at
>
On Mon, 28 Apr 2025 16:42:35 GMT, Alan Bateman wrote:
> This issue has the "oca" label so we cannot engage, sorry.
Ah, sorry. I only asked because I saw a colleague of yours helping out with OCA
verification over at
https://github.com/openjdk/jdk/pull/23905#issuecomment-2762865417. Also, the
On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote:
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
> called on the target library file before it was passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Wed, 16 Apr 2025 17:01:06 GMT, Benjamin Peterson wrote:
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
> called on the target library file before it was passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
called on the target library file before it was passed to the system library
loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
symlinks on Windows. This had unintended consequences for passing a
29 matches
Mail list logo
