Ticket #2150 (new bug)

Opened 3 years ago

Last modified 3 years ago

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.

Change History

Changed 3 years ago by plobsing

Normally, it would be wise to simply refer to the library via a loadlib, but libc is peculiar in that it is difficult to have access to it in a cross-platform way. For example, on my machine, I am unable to get a handle on libc by using anything less than the full name ("/lib/libc.so.6").

Parrot needs some mechanism for accessing libc functions via NCI (because they are frequently useful). I recommend a Configure.pl probe and a parrot_config entry to determine how to refer to the system's libc.

Changed 3 years ago by NotFound

Maybe the solution is to use GetModuleHandle(NULL) when passed a null or undef library. I'm not sure if using the current module will give the same functionality as un unix, though.

Changed 3 years ago by NotFound

After last whiteknight fixes the tests using atoi, atol and other C library symbols still fails in my XP box. After some testing I think the problem is due to the libc used by Strawberry/mingw is statically linked and its symbols not exported for external linkage.

The simple solution I see is: delete that tests and document that getting functions from the libc via dlsym is platform dependant, not granted to work.

Note: See TracTickets for help on using tickets.