Windows support

[VitalyArtemiev]

Hello.

I am trying to get these headers (from lubusb-1.0 branch) to work under Windows (currently just trying to compile your example project test1library).
In the LibUsb unit there are the following lines:

{$LINKLIB c}

{$LINKLIB usb-1.0}

As far as I understand, there is no access to libc on windows. Other questions on similar topics suggest replacing libc with libmsvcrt. I've replaced the above code with the following:

{$ifdef windows}
  {$linklib msvcrt}
{$else}
  {$LINKLIB c}
{$endif}

{$LINKLIB usb-1.0}

Of course, this gets rid of the "Import library not found for c" error, however instead I get errors about undefined symbols (seems like every symbol defined in LibUsb unit):

test2controlsync.pas(120,52) Hint: Variable "DescrConf" does not seem to be initialized
test2controlsync.pas(136,52) Hint: Variable "DescrIntf" does not seem to be initialized
test2controlsync.pas(153,50) Hint: Variable "DescrEP" does not seem to be initialized
Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_CONTROL_TRANSFER$crc40A776B7
Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_INIT$PLIBUSB_CONTEXT::=::\LONGINT
Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_EXIT$PLIBUSB_CONTEXT
Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_SET_DEBUG$PLIBUSB_CONTEXT$LONGINT
Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_GET_VERSION::=::\PLIBUSB_VERSION
Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_HAS_CAPABILITY$LONGWORD::=::\LONGINT
Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_ERROR_NAME$LONGINT::=::\PCCHAR

...
etc.

I don't know if this is connected to the libc/libmsvcrt issue or if this is a separate problem. I'm quite a noob when it comes to header translation, linking etc. Do you have any pointers as to which direction I need to be digging?

I am using the latest lazarus/FPC build and the latest version of libusb from https://libusb.info/
(BTW, in your readme file the link to linkusb site no longer works).

[hansiglaser]

Hi Vitalii! Thanks for your inquiry! I doubt that the problems are coming from libc. It seems that the FPC compiler uses Pascal symbols for the LibUSB functions (e.g., LIBUSB_INIT$PLIBUSB_CONTEXT::=::\LONGINT) instead of the original C symbols (e.g., libusb_init), which would be correct. In lines 45-49 of libusb.pas the macro "extdecl" is defined, which is set to "stdcall" in Windows. The "extdecl" is then used for all external function headers. This should have prevented that. Are you sure you still include that in the source file? Bye Hansi PS: Thanks for the hint for the broken link. I've fixed it in the mentioned branch. Am Freitag, den 05.07.2019, 11:16 -0700 schrieb Виталий Артемьев:

…

Hello. I am trying to get these headers (from lubusb-1.0 branch) to work under Windows (currently just trying to compile your example project test1library). In the LibUsb unit there are the following lines: {$LINKLIB c} {$LINKLIB usb-1.0} As far as I understand, there is no access to libc on windows. Other questions on similar topics suggest replacing libc with libmsvcrt. I've replaced the above code with the following: {$ifdef windows} {$linklib msvcrt} {$else} {$LINKLIB c} {$endif} {$LINKLIB usb-1.0} Of course, this gets rid of the "Import library not found for c" error, however instead I get errors about undefined symbols (seems like every symbol defined in LibUsb unit): test2controlsync.pas(120,52) Hint: Variable "DescrConf" does not seem to be initialized test2controlsync.pas(136,52) Hint: Variable "DescrIntf" does not seem to be initialized test2controlsync.pas(153,50) Hint: Variable "DescrEP" does not seem to be initialized Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_CONTROL_TRANSFER$crc40A776B7 Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_INIT$PLIBUSB_CONTEXT::=::\LONGINT Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_EXIT$PLIBUSB_CONTEXT Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_SET_DEBUG$PLIBUSB_CONTEXT$LONGINT Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_GET_VERSION::=::\PLIBUSB_VERSION Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_HAS_CAPABILITY$LONGWORD::=::\LONGINT Error: Undefined symbol: LIBUSB_::=::\_LIBUSB_ERROR_NAME$LONGINT::=::\PCCHAR ... etc. I don't know if this is connected to the libc/libmsvcrt issue or if this is a separate problem. I'm quite a noob when it comes to header translation, linking etc. Do you have any pointers as to which direction I need to be digging? I am using the latest lazarus/FPC build and the latest version of libusb from https://libusb.info/ (BTW, in your readme file the link to linkusb site no longer works). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[VitalyArtemiev]

I have not changed anything in the source file except for the libc part. The macro is there and is highlighted as active. I've also tried to replace all 'extdecl' modifiers with 'stdcall' outright just now, but that didn't have any effect either.

Maybe it's the compiler version? I'll try with 2.6.0 tomorrow and see if that works.

[VitalyArtemiev]

I've solved (or, rather, sidestepped) the problem. I replaced the libusb-1.0.a file that I was linking against with libusb-1.0.dll.a and libusb-1.0.dll and also changed the stdcall key word in the windows macro to cdecl. So now, I guess, I am linking dynamically instead of statically? I still would like to know how to link statically but I guess it works, so you may close the issue.

The part of source file I changed now looks like this:

{$macro on}
{$ifdef windows}
  {$define extdecl:=cdecl}
{$else}
  {$define extdecl:=cdecl}
{$endif}

Interface

Uses CTypes;

{$ifdef windows}
  {$linklib msvcrt}
{$else}
  {$LINKLIB c}
{$endif}

{$LINKLIB usb-1.0.dll.a}     

(I understand that the macro now does nothing, but I left it like that in case I need to tamper with it further)

If you want, I'll submit a pull request, but it's not the proper way to do it, so I don't think I should.

[hansiglaser]

Hi Vitaly! Am Sonntag, den 07.07.2019, 16:26 -0700 schrieb Виталий Артемьев:

I've solved (or, rather, sidestepped) the problem. I replaced the libusb-1.0.a file that I was linking against with libusb-1.0.dll.a and libusb-1.0.dll and also changed the stdcall key word in the windows macro to cdecl. So now, I guess, I am linking dynamically instead of statically? I still would like to know how to link statically but I guess it works, so you may close the issue. The part of source file I changed now looks like this: {$macro on} {$ifdef windows} {$define extdecl:=cdecl} {$else} {$define extdecl:=cdecl} {$endif} Interface Uses CTypes; {$ifdef windows} {$linklib msvcrt} {$else} {$LINKLIB c} {$endif} {$LINKLIB usb-1.0.dll.a} If you want, I'll submit a pull request, but it's not the proper way to do it, so I don't think I should.

Thanks for your further effort and finding a solution! Unfortunately I too don't understand enough regarding Windows and linking, therefore I'm not sure whether your solution is the correct solution, which would also fit for everybody else. Therefore I'd prefer to keep the source code as is, and if anybody else has the same problem as you, I hope he finds this issue and discussion thread to help him out. Additionally I'd ask him to notify me or send a pull request. Then I'll fix it in the source code. Thanks Hansi

[Zaaphod]

Hi Hansi,
I'm wondering if you plan to include the changes to make pas-libusb compatible with windows?
I would be happy to do whatever further testing on windows is needed.
James

[hansiglaser]

Hi James!

As discussing in our Freepascal thread I'll be happy to include all changes. When you are satisfied with your work in your fork, just send a pull request.

Thanks
Hansi