• Dr.No (33/33) May 27 2018 I'm trying to use wkhtmltopdf[1] with D. I converted this
• sarn (5/7) May 27 2018 From an ABI point of view, the raw pointers won't care about the
• Dr.No (2/9) May 28 2018 Yep, the C version work just fine.
• Mike Parker (28/39) May 28 2018 This sort of issue is most often caused by a mistake in the
• Nicholas Wilson (4/15) May 28 2018 this is represented by extern(System) in D which does the
• Nicholas Wilson (2/20) May 28 2018 Apparently I can't read.
• Nicholas Wilson (6/39) May 27 2018 You're missing const on a couple of the pointer parameters, but

Dr.No <jckj33 gmail.com> writes:

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

sarn <sarn theartofmachinery.com> writes:

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?

Dr.No <jckj33 gmail.com> writes:

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.

Mike Parker <aldacron gmail.com> writes:

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.

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

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.

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

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.

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

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.