Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Including 64 bit 3rd party DLL


This question is answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 5 - Last Post: Jan 23, 2016 5:54 PM Last Post By: Roland Seidel
Roland Seidel

Posts: 6
Registered: 4/22/03
Including 64 bit 3rd party DLL  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 21, 2016 2:35 PM
I'm having trouble working with a 64 bit 3rd party DLL.

I've used the 32 bit one for some time and the process was:
- make a .lib with IMPLIB keylib32.lib keylib32.dll
- include the .lib in the project
- put the DLL in the directory with the .exe

I figure the 64 bit equivalent is
- make a .a with MKEXP keylib64.a keylib64.dll
- include the .a in the project
- put the DLL in the directory with the .exe

But when the compiler encounters any of the dll funcs I get eg "no matching function for pp_semcount"
I figure that means it found the .h and knows about the function, but it can't find the function itself.

XE8.1, XE10.1

Any clues on what might be wrong?
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Including 64 bit 3rd party DLL  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 21, 2016 5:48 PM   in response to: Roland Seidel in response to: Roland Seidel
Roland wrote:

But when the compiler encounters any of the dll funcs I get eg
"no matching function for pp_semcount"

What is the COMPLETE error message? And is it a compiler error or a linker
error? The compiler uses the .h file, the linker uses the .lib/.a file.

--
Remy Lebeau (TeamB)
Roland Seidel

Posts: 6
Registered: 4/22/03
Re: Including 64 bit 3rd party DLL  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 22, 2016 3:02 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
thanks for looking, Remy - I had assumed it was a problem with the .a structure but expanding the message points to something else.
It is a bcc64 error with a second line

[bcc64 Error] SOLODiagnostic64Win.cpp(88): no matching function for call to 'pp_semcount'
KeyLib.h(689): candidate function not viable: no known conversion from 'long' to 'void *' for 1st argument; take the address of the argument with &

KeyLib.h(689) is
LONG PPPEXPORT WINAPI PP_SEMCOUNT( PPLFHANDLE handle, LONG semtype, LPSTR prefix_server, LPSTR name, LPLONG number );

and their PPLFHANDLE = HGLOBAL = HANDLE = VOID*

Does this suggest the .a has the first param as a long?
Is there something different I should be doing with MKEXP?
Is there a tool that shows the function calls in a .a?
.....


Remy Lebeau (TeamB) wrote:
Roland wrote:

But when the compiler encounters any of the dll funcs I get eg
"no matching function for pp_semcount"

What is the COMPLETE error message? And is it a compiler error or a linker
error? The compiler uses the .h file, the linker uses the .lib/.a file.

--
Remy Lebeau (TeamB)
Antonio Estevez

Posts: 665
Registered: 4/12/00
Re: Including 64 bit 3rd party DLL  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 22, 2016 4:06 PM   in response to: Roland Seidel in response to: Roland Seidel
El 23/1/16 a las 0:02, Roland Seidel escribió:
thanks for looking, Remy - I had assumed it was a problem with the .a structure but expanding the message points to something else.
It is a bcc64 error with a second line

[bcc64 Error] SOLODiagnostic64Win.cpp(88): no matching function for call to 'pp_semcount'
KeyLib.h(689): candidate function not viable: no known conversion from 'long' to 'void *' for 1st argument; take the address of the argument with &


The error means that in the line 88 of SOLODiagnostic64Win.cpp you are calling to pp_semcount passing, as the first
parammeter, a variable of type LONG instead of a variable of type HANDLE.


KeyLib.h(689) is
LONG PPPEXPORT WINAPI PP_SEMCOUNT( PPLFHANDLE handle, LONG semtype, LPSTR prefix_server, LPSTR name, LPLONG number );

and their PPLFHANDLE = HGLOBAL = HANDLE = VOID*

Does this suggest the .a has the first param as a long?
Is there something different I should be doing with MKEXP?
Is there a tool that shows the function calls in a .a?


The problem is in compiler time. It has nothing to do with either the linker nor the .a library
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Including 64 bit 3rd party DLL  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 22, 2016 4:44 PM   in response to: Roland Seidel in response to: Roland Seidel
Roland wrote:

Does this suggest the .a has the first param as a long?

No. It means the code that is calling pp_semcount() is using a variable
that is declared as 'long' instead of 'void*'. According to the API documentation:

http://www.softwarekey.com/help/plusman/Content/SWKeyCL/SWKeyCL_Parameter_And_Return_Value_Syntax.htm

PPLFHANDLE
License file handle. Defined as LONG when compiling a 32-bit application
or HGLOBAL when compiling a 64-bit application.

The code needs to be fixed to declare its variable using the PPLFHANDLE type
so it always matches what the API is expecting:

PPLFHANDLE handle;
...
pp_lfopen(..., &handle);
pp_semcount(handle, ...);
...
pp_lfclose(handle);


--
Remy Lebeau (TeamB)
Roland Seidel

Posts: 6
Registered: 4/22/03
Re: Including 64 bit 3rd party DLL  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 23, 2016 5:54 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
thanks, Remy - they changed the declaration of a bunch of things in this version. After carefully following the new header decs I got it going. Wish I'd spotted that earlier but with new compiler, new libraries, new version, it was difficult to see through it. Thanks for the direction.
Roland


Remy Lebeau (TeamB) wrote:
Roland wrote:

Does this suggest the .a has the first param as a long?

No. It means the code that is calling pp_semcount() is using a variable
that is declared as 'long' instead of 'void*'. According to the API documentation:

http://www.softwarekey.com/help/plusman/Content/SWKeyCL/SWKeyCL_Parameter_And_Return_Value_Syntax.htm

PPLFHANDLE
License file handle. Defined as LONG when compiling a 32-bit application
or HGLOBAL when compiling a 64-bit application.

The code needs to be fixed to declare its variable using the PPLFHANDLE type
so it always matches what the API is expecting:

PPLFHANDLE handle;
...
pp_lfopen(..., &handle);
pp_semcount(handle, ...);
...
pp_lfclose(handle);


--
Remy Lebeau (TeamB)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02