I'm trying to use wkhtmltopdf[1] with D. I converted this header[2] with little modification using htod tool which resulted in this[3].
The libray is passed to link using:

pragma(lib, "wkhtmltox.lib");
(that file is in wkhtmltopdf\lib folder)


and the module imported with:
import pdf;

but it crashes right upon the start with a SEGFAULT:

void main()
{
	
	wkhtmltopdf_global_settings * gs;
	wkhtmltopdf_object_settings * os;
	wkhtmltopdf_converter * c;
	
	/* Init wkhtmltopdf in graphics less mode */
	wkhtmltopdf_init(0);
}

toolset I'm using:

DUB version 1.8.1, built on Apr 29 2018
LDC - the LLVM D compiler (1.9.0):
  based on DMD v2.079.1 and LLVM 5.0.1
  built with LDC - the LLVM D compiler (1.9.0)
  Default target: i686-pc-windows-msvc
  Host CPU: skylake
  http://dlang.org - http://wiki.dlang.org/LDC

What's likely the reason of the crash? mismatch between D and C memory alignment?

[1]: https://wkhtmltopdf.org/index.html
[2]: https://github.com/clowder/wkhtmltopdf/blob/master/src/lib/pdf.h
[3]: https://pastebin.com/SrtDUhPf

On Monday, 28 May 2018 at 01:28:10 UTC, Dr.No wrote:
> What's likely the reason of the crash? mismatch between D and C memory alignment?

From an ABI point of view, the raw pointers won't care about the memory structure they point to.  The function call is the only thing that depends on the binary interface.

If you translate the code into C, does it work?

On Monday, 28 May 2018 at 01:28:10 UTC, Dr.No wrote:
> I'm trying to use wkhtmltopdf[1] with D. I converted this header[2] with little modification using htod tool which resulted in this[3].
> The libray is passed to link using:
>
> pragma(lib, "wkhtmltox.lib");
> (that file is in wkhtmltopdf\lib folder)
>
>
> and the module imported with:
> import pdf;
>
> but it crashes right upon the start with a SEGFAULT:
>
> void main()
> {
> 	
> 	wkhtmltopdf_global_settings * gs;
> 	wkhtmltopdf_object_settings * os;
> 	wkhtmltopdf_converter * c;
> 	
> 	/* Init wkhtmltopdf in graphics less mode */
> 	wkhtmltopdf_init(0);
> }
>
> toolset I'm using:
>
> DUB version 1.8.1, built on Apr 29 2018
> LDC - the LLVM D compiler (1.9.0):
>   based on DMD v2.079.1 and LLVM 5.0.1
>   built with LDC - the LLVM D compiler (1.9.0)
>   Default target: i686-pc-windows-msvc
>   Host CPU: skylake
>   http://dlang.org - http://wiki.dlang.org/LDC
>
> What's likely the reason of the crash? mismatch between D and C memory alignment?
>
> [1]: https://wkhtmltopdf.org/index.html
> [2]: https://github.com/clowder/wkhtmltopdf/blob/master/src/lib/pdf.h
> [3]: https://pastebin.com/SrtDUhPf

You're missing const on a couple of the pointer parameters, but if it segfaults on calling a function then my question is: is wkhtmltox.lib a library that was generated to link to a dynamic library (is there an associated .dll)? If so you need to ensure that it is loaded and the function pointers are initialised.

On Monday, 28 May 2018 at 02:10:48 UTC, sarn wrote:
> On Monday, 28 May 2018 at 01:28:10 UTC, Dr.No wrote:
>> What's likely the reason of the crash? mismatch between D and C memory alignment?
>
> From an ABI point of view, the raw pointers won't care about the memory structure they point to.  The function call is the only thing that depends on the binary interface.
>
> If you translate the code into C, does it work?

Yep, the C version work just fine.

On Monday, 28 May 2018 at 21:05:00 UTC, Dr.No wrote:
> On Monday, 28 May 2018 at 02:10:48 UTC, sarn wrote:
>> On Monday, 28 May 2018 at 01:28:10 UTC, Dr.No wrote:
>>> What's likely the reason of the crash? mismatch between D and C memory alignment?
>>
>> From an ABI point of view, the raw pointers won't care about the memory structure they point to.  The function call is the only thing that depends on the binary interface.
>>
>> If you translate the code into C, does it work?
>
> Yep, the C version work just fine.

This sort of issue is most often caused by a mistake in the bindings: incorrect calling convention, wrong parameter/return types, incorrect number of parameters, etc. In this case, if we look in pdf.h we can see it includes "dllbegin.inc'. There, you'll find the following:

#if defined _WIN32
#define CALLTYPE __stdcall
#else
#define CALLTYPE
#endif

#ifdef __cplusplus
  #define CAPI(type) extern "C" DLL_PUBLIC type CALLTYPE
#else
  #define CAPI(type) DLL_PUBLIC type CALLTYPE
#endif

https://github.com/clowder/wkhtmltopdf/blob/master/src/lib/dllbegin.inc#L43

In pdf.h, that CAPI macro is used in every function declaration. That means that on Windows, all of the functions have the __stdcall calling convention (which, in D, would be extern(Windows)) and the standard cdecl calling convetion on other platforms (extern(C) in D).

In the D binding, we see that all of the functions are declared as extern(C) (line 4 of pdf.d). That means on Windows, the calling convention on the D side is incorrect.

What you need to do is to change that extern(C) delcaration in pdf.d to extern(System). This will translate to extern(Windows) on Windows and extern(C) elsewhere to match the C headers.

On Tuesday, 29 May 2018 at 01:43:17 UTC, Mike Parker wrote:
> In pdf.h, that CAPI macro is used in every function declaration. That means that on Windows, all of the functions have the __stdcall calling convention (which, in D, would be extern(Windows)) and the standard cdecl calling convetion on other platforms (extern(C) in D).
>
> In the D binding, we see that all of the functions are declared as extern(C) (line 4 of pdf.d). That means on Windows, the calling convention on the D side is incorrect.
>
> What you need to do is to change that extern(C) delcaration in pdf.d to extern(System). This will translate to extern(Windows) on Windows and extern(C) elsewhere to match the C headers.

this is represented by extern(System) in D which does the conditional
extern(C) vs extern(Windows) for you.

On Tuesday, 29 May 2018 at 04:49:34 UTC, Nicholas Wilson wrote:
> On Tuesday, 29 May 2018 at 01:43:17 UTC, Mike Parker wrote:
>> In pdf.h, that CAPI macro is used in every function declaration. That means that on Windows, all of the functions have the __stdcall calling convention (which, in D, would be extern(Windows)) and the standard cdecl calling convetion on other platforms (extern(C) in D).
>>
>> In the D binding, we see that all of the functions are declared as extern(C) (line 4 of pdf.d). That means on Windows, the calling convention on the D side is incorrect.
>>
>> What you need to do is to change that extern(C) delcaration in pdf.d to extern(System). This will translate to extern(Windows) on Windows and extern(C) elsewhere to match the C headers.
>
> this is represented by extern(System) in D which does the conditional
> extern(C) vs extern(Windows) for you.

Apparently I can't read.