t/pmc/nci.t fails on windows

[whiteknight]

t/pmc/nci.t test #29 fails on windows. This is because passing PMCNULL as the first in-arg to dlfunc does not appear to work on windows. A null function pointer is returned from Parrot_dlsym, and an Undef is returned from the dlfunc opcode.

I suggest we do one of two things, in order of preference:

• Fix Parrot_dlsym to look inside libparrot when a NULL Handle value is received (Fix the test)
• Don't support the behavior of allowing a null argument to dlfunc in the first place on any system (Remove the test, and maybe add warnings).

We should try to get something in place today, before 3.6 is released

[whiteknight]

This problem is also breaking t/library/nciutils.t on win32. Same exact issue.

[whiteknight]

I have put in a fix this morning which fixes t/pmc/nci.t, but does not fix t/library/nciutils.t. I don't know why the same fix isn't working for both tests.

[NotFound]

There is a problem with dlsym usages: there are modules linked from libparrot and code that tries to dynamically load the library, fails, and the programs work anyway because they find the libraries in the current process. If we fix dlsym we risk to break existent code.

On windows there is a function to get handle to look for symbols in the current process image, but I don't remember...

[jkeenan]

Point of information:

See recently closed tickets TT #2117, TT #2116 and TT #1979. At the point we closed these, Smolder was down so we probably couldn't assess impact of patches on Windows.

[whiteknight]

I've fixed this particular test, but I haven't been able to completely fix the underlying issue. I'm going to open a new ticket to track the remaining windows nci-related tickets.