Project

Profile

Help

Bug #4707

closed

Library libsaxonhec.dll is not present in the system (Windows)

Added by O'Neil Delpratt over 4 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Category:
Windows
Start date:
2020-09-02
Due date:
% Done:

0%

Estimated time:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Found in version:
1.2.1
Fixed in version:
11.1
SaxonC Languages:
SaxonC Platforms:
SaxonC Architecture:

Description

Reported by user:

When I create my new project I always got error message that library libsaxonhec.dll is not present in the system despite the path was correct and the library was in the appropriate directory.

Finally I found, that the problem is when compiling and define –DUNICODE is present. In this case this makes type mixture between const char* and const wchar_t* in macro LoadLibrary(…). Please see the file SaxonCGlue.c from line 137:

I have changed the code to (see below) and the problem disappeared (I’m running Win7 64bit and IDE is MS Visual Studio 2017):

#if !(defined (__linux__) || (defined (__APPLE__) && defined(__MACH__)))
#ifdef UNICODE
  wchar_t* wc = malloc(sizeof(wchar_t)*(strlen(name)+1));
  size_t convertedChars = 0;
  mbstowcs_s( &convertedChars, wc, strlen(name)+1, name, _TRUNCATE );
  HANDLE hDll = LoadLibraryW(wc); // Used for windows only
  free(wc);
#else
  HANDLE hDll = LoadLibraryA(name); // Used for windows only
#endif
#else
  HANDLE hDll = LoadLibraryA(name);
#endif

Related issues

Has duplicate SaxonC - Bug #4953: SaxonCGlue - C/C++ UNICODE Interop - add doc somewhereDuplicate2021-03-30

Actions
Actions #1

Updated by O'Neil Delpratt over 4 years ago

  • Status changed from New to In Progress

I have applied the suggested fix in the function loadDll of the SaxonGlue.h file. Change made in Saxon/C 1.2 and on the trunk.

Although it is not clear to me that the following part is in the second preprocessor else branch required changing from LoadLibrary(name) to LoadLibraryA(name) therefore I have only made the following change:

#if !(defined (__linux__) || (defined (__APPLE__) && defined(__MACH__)))
#ifdef UNICODE
  wchar_t* wc = malloc(sizeof(wchar_t)*(strlen(name)+1));
  size_t convertedChars = 0;
  mbstowcs_s( &convertedChars, wc, strlen(name)+1, name, _TRUNCATE );
  HANDLE hDll = LoadLibraryW(wc); // Used for windows only
  free(wc);
#else
  HANDLE hDll = LoadLibraryA(name); // Used for windows only
#endif
#else
	HANDLE hDll = LoadLibrary(name);
#endif

Testing required.

Actions #2

Updated by O'Neil Delpratt over 3 years ago

  • Has duplicate Bug #4953: SaxonCGlue - C/C++ UNICODE Interop - add doc somewhere added
Actions #3

Updated by Martin Ba over 3 years ago

I like to note here that the use of mbstowcs here is 99.9% superfluous.

The whole point of the LoadLibrary/A/W thing (*) is that the LoadLibraryA function does the CP_ACP conversion for you. LoadLibrary is just a macro that points to either LoadLibraryA or LoadLibraryW.

So, unless one has any reason to need to work with the active C locale encoding explicitly instead of the CP_ACP, using the extra 4 lines for mbctowcs does not buy anything.

Any code passing a char* should just use LoadLibraryA and be done with it.

(*) See also: https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya https://docs.microsoft.com/en-us/windows/win32/intl/conventions-for-function-prototypes

Actions #4

Updated by O'Neil Delpratt almost 2 years ago

  • Status changed from In Progress to Closed

I am closing this bug issue as no further action. Please reopen if problem still exists.

In SaxonC 12 we have moved away from Excelsior Jet to Graalvm.

Actions #5

Updated by O'Neil Delpratt almost 2 years ago

  • Fixed in version set to 11.1

Please register to edit this issue

Also available in: Atom PDF