C++ extension doesn't work in 8.1.3

General
1 
foreign_t                                                               
pl_lowercase(term_t u, term_t l)                                        
{
    return 0;
}
extern "C" 
install_t                                                               
install()                                                               
{ 
    PL_register_foreign("lowercase", 2, pl_lowercase, 0);

Running that PL_register_foreign gives:
‘swipl-win.exe’ (Win32): Loaded ‘C:\vmm\2018\rule-processor\branches\gen3\nb_vector.dll’. Symbols loaded.
‘swipl-win.exe’ (Win32): Loaded ‘C:\Windows\System32\vcruntime140.dll’. Cannot find or open the PDB file.
‘swipl-win.exe’ (Win32): Loaded ‘C:\Windows\System32\msvcp140.dll’. Cannot find or open the PDB file.
Exception thrown at 0x0000000071599985 (libswipl.dll) in swipl-win.exe: 0xC0000005: Access violation reading location 0x00002FFD8B7AD904.

2

Little clue. How did you compile the C++? Suggests a runtime library incompatibility. Possibly other Windows users have a clue?

3

You may need extern "C" for pl_lowercase also.

4

Wait, i see the problem. That’s supposed to be Win64, not Win32

Nope, further checking does not corroborate. It does seem that all files are 64 bit, and only visual studio is confused by saying 32 but it really isn’t.~~

I think the true problem is this:
image
This is the lib directory and the lib file is not current, so linking to functions won’t behave.

5

@jan can you comment on this? Non-updated lib files seems like a problem with the distribution?

6

Considering the somewhat different layout of the new install tree created by CMake/CPack, it is probably a wise idea to delete the old installation first. Possibly best by removing or moving the swipl folder.

In my installed version, lib only contains the jpl.jar file. The libswipl.dll.a is in bin. I don’t know whether that is a good or bad idea. There is no libswipl.lib. I don’t know the current status of MinGW/MSVC interoperability. As far as I recall, the .lib file used to be created using a partial installation of the MSVC tools running under Linux Wine … If it can be avoided to set this up again, it would be a big gain.

Anyone aware of the current best practice?

7

of note, when I ran the install, it suggested I do an uninstall but when I clicked the button to do that, it never bothered.

8

Ah, so I copied libswipl.dll.a from bin to libswipl.lib in lib, and everything worked*. Visual C++ users don’t know about .dll.a as an extension so I would suggest having both names? I don’t have a problem with it being in the bin directory except that’s a change from previous versions, caught me by surprise.

  • By everything, I mean it loaded without crashing. Tests haven’t been conducted.
9

Hmm. There are zillions of claims that .dll.a files cannot be used by MSVC. Possibly these are old claims. I did a little research on the old setup and there it seems I was using MinGW to generate a .def file and then MS LIB.EXE to create the .lib file. If this can be changed using a simple additional install of the .dll.a file in lib, that would be great.

Let me know how the tests proceed.

10

Program seems to work as expected. What gets me about this is, aren’t there other people doing C extensions? Seems nobody noticed this lack in a year. Myself i was on a version of 7 that still had these libraries installed.

1 Like
11

I know of at least two commercial users of C extensions on Windows. Both use MinGW for compiling their extensions though. Apparently few people use MSVC for compiling extensions, although there are still many users using older releases. The current version is much better from the Prolog viewpoint, but the migration to CMake and CPack still causes regression in packaging and location issues when compiling C extensions.