Ticket #2150 (new bug)
t/library/nciutils.t fails on windows
Reported by: | whiteknight | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | |
Component: | testing | Version: | master |
Severity: | fatal | Keywords: | nci |
Cc: | Language: | ||
Patch status: | Platform: | all |
Description
t/library/nciutils.t is failing on windows. This is because of a particular expected behavior that is not supported on that platform. On windows, passing a NULL handle to GetProcAddress returns a null function pointer (equivalent operations on linux, a NULL library handle will look up the function in the current process).
I fixed a related failure in #2148 by checking in src/platform/win32/dl.c:Parrot_dlsym for a NULL handle, and calling GetModuleHandle("libparrot"). That call looks up the libparrot binary in the current executing process, and returns a handle to it. Passing that handle to GetProcAddress allows us to find function in libparrot. That works (so long as the module is called "libparrot", which might be a little bit brittle, but that's another issue)
t/library/nciutils.t uses a null library handle to look up functions from libc, which works on linux because a null handle looks up in the current process. My fix on windows only looks up the function in the libparrot module. I don't know if there is a way to look up a function in an entire process, but I haven't been able to find such a method yet.
There are two options:
- Change the test to explicitly load a library by name, instead of using a null library PMC and hoping the magic behavior just works in a cross-platform way
- Mark the test TODO on windows, and keep searching for a way to make it work the same way as it does on Linux.