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
file didn't have a `.dll` extension, `LoadLibrary` try to load
> nonexistent file and fail.
>
> Fix this problem by appending a `.` to library paths after canonicalization
> on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior.
Benjamin Peterson has u
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: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/NativeLibr
file didn't have a `.dll` extension, `LoadLibrary` try to load
> nonexistent file and fail.
>
> Fix this problem by appending a `.` to library paths after canonicalization
> on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior.
Benjamin Peterson has u
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
file didn't have a `.dll` extension, `LoadLibrary` try to load
> nonexistent file and fail.
>
> Fix this problem by appending a `.` to library paths after canonicalization
> on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior.
Benjamin Peterson has u
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: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, 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 t
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 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 t
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
14 matches
Mail list logo
