Ticket #2150 (new bug)

Opened 11 years ago

Last modified 11 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 11 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 11 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 11 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.