www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - how to export callbacks on win64?

reply captaindet <2krnk gmx.net> writes:
struggling to get my code working with LDC, it works fine with 
DMD-2.071.2 (32bit optlink as well as 64bit MS link).

i want to export a callback to use with GTK / GtkD (D bindings to GTK), 
i.e. after the GTK.Builder has built my GUI, it connects signals via 
GTK.Builder.connectSignals(null) - again: this works fine with the DMD 
toolchain.

current example code for export:

extern(C) export void myCallback(GtkButton* _0){
	...
}

however, using ldc2-1.1.0-beta3-win64 w/ VS2015 i get the following GTK 
warning "Could not find signal handler 'myCallback'.  Did you compile 
with -rdynamic?"

this lead me to the following post
https://forum.dlang.org/post/n1p0j7$1j0v$1 digitalmars.com
indicating that adding "-L-rdynamic" might help in case of the GCC 
toolchain. however, MS link does not seem to have "-L-rdynamic".

so how do i make this work on windows? is there an equivalent to 
"-L-rdynamic"?

thanks
/det
Oct 24 2016
parent reply Jacob <noreply noreply.com> writes:
On Tuesday, 25 October 2016 at 03:23:41 UTC, captaindet wrote:

 however, using ldc2-1.1.0-beta3-win64 w/ VS2015 i get the 
 following GTK warning "Could not find signal handler 
 'myCallback'.  Did you compile with -rdynamic?"



What are you trying to do? Make a D shared library on windows? 
LDC might not export the functions making them visible. If you 
are making a DLL you might try using a .def file with the linker. 
https://msdn.microsoft.com/en-us/library/d91k01sh.aspx
Oct 24 2016
parent reply captaindet <2krnk gmx.net> writes:
On 2016-10-25 16:28, Jacob wrote:

 On Tuesday, 25 October 2016 at 03:23:41 UTC, captaindet wrote:

 however, using ldc2-1.1.0-beta3-win64 w/ VS2015 i get the following
 GTK warning "Could not find signal handler 'myCallback'.  Did you
 compile with -rdynamic?"



 What are you trying to do? Make a D shared library on windows? LDC might
 not export the functions making them visible. If you are making a DLL
 you might try using a .def file with the linker.
 https://msdn.microsoft.com/en-us/library/d91k01sh.aspx


negative. building an executable that happens to have callback functions 
that shall be called by GTK dynamic libraries. again: this compiles fine 
with DMD -m64 (and -m32). (also, creating extra .def files is not an 
option in my case)
Oct 24 2016
parent reply Kagamin <spam here.lot> writes:
You can also use the /export option: 
https://msdn.microsoft.com/en-us/library/7k30y2k5.aspx
Oct 25 2016
parent reply captaindet <2krnk gmx.net> writes:
i appreciate that you are trying to help. however, you are indicating 
workarounds for something that should work out of the box.

again, D has the export attribute for this reason
https://dlang.org/spec/attribute.html
and my code/use-case works fine with DMD (and the MS linker).

the lack of replies addressing the root problem seems to indicate that 
LDC does not respect the export attribute. maybe i should file a bug.

On 2016-10-26 01:10, Kagamin wrote:

 You can also use the /export option:
 https://msdn.microsoft.com/en-us/library/7k30y2k5.aspx


these workarounds don't work for me. with respect to the three methods 
given under 'remarks' (see your link):


 1. __declspec(dllexport) in the source code


as i understand it, this is what D's export attribute is supposed to 
trigger. but it does not seem to work with LDC.


 2. An EXPORTS statement in a .def file
 3. An /EXPORT specification in a LINK command


out of the question for my use-case. i got a large number of such 
callback functions and - and this is the real deal-breaker - they are 
generated and mixed in during CT. even if i could produce a .def file or 
linker commands during CT (which is currently not possible nor is it a 
desirable route to go), they would not be used for that compilation.

as it stands this is a blocker for me, meaning i cannot use LDC for my 
project.

/det
Oct 25 2016
next sibling parent reply kinke <noone nowhere.com> writes:
Hey,

On Tuesday, 25 October 2016 at 21:28:50 UTC, captaindet wrote:

 i appreciate that you are trying to help. however, you are 
 indicating workarounds for something that should work out of 
 the box.

 again, D has the export attribute for this reason
 https://dlang.org/spec/attribute.html
 and my code/use-case works fine with DMD (and the MS linker).

 the lack of replies addressing the root problem seems to 
 indicate that LDC does not respect the export attribute. maybe 
 i should file a bug.


Sometimes the issues are already known and a quick GitHub search 
reveals them:
https://github.com/ldc-developers/ldc/issues/1745


 as it stands this is a blocker for me, meaning i cannot use LDC 
 for my project.


Yep. Contributions are always welcome though. ;)
Oct 25 2016
parent captaindet <2krnk gmx.net> writes:
On 2016-10-26 10:48, kinke wrote:

 Sometimes the issues are already known and a quick GitHub search reveals
 them:
 https://github.com/ldc-developers/ldc/issues/1745


i was just about to crawl through the issue list, thanks for the feedback.

if this ever gets fixed please make sure it is mentioned in the release 
notes / changelog.



 as it stands this is a blocker for me, meaning i cannot use LDC for
 my project.


 Yep. Contributions are always welcome though. ;)


i appreciate your work on LDC. i am a simple user though and lack any 
knowledge about internals.

/det
Oct 25 2016
prev sibling parent Laeeth Isharc <laeethnospam laeethnospam.com> writes:
On Tuesday, 25 October 2016 at 21:28:50 UTC, captaindet wrote:

 i appreciate that you are trying to help. however, you are 
 indicating workarounds for something that should work out of 
 the box.

 again, D has the export attribute for this reason
 https://dlang.org/spec/attribute.html
 and my code/use-case works fine with DMD (and the MS linker).

 the lack of replies addressing the root problem seems to 
 indicate that LDC does not respect the export attribute. maybe 
 i should file a bug.

 On 2016-10-26 01:10, Kagamin wrote:

 You can also use the /export option:
 https://msdn.microsoft.com/en-us/library/7k30y2k5.aspx


 these workarounds don't work for me. with respect to the three 
 methods given under 'remarks' (see your link):


 1. __declspec(dllexport) in the source code


 as i understand it, this is what D's export attribute is 
 supposed to trigger. but it does not seem to work with LDC.


 2. An EXPORTS statement in a .def file
 3. An /EXPORT specification in a LINK command


 out of the question for my use-case. i got a large number of 
 such callback functions and - and this is the real deal-breaker 
 - they are generated and mixed in during CT. even if i could 
 produce a .def file or linker commands during CT (which is 
 currently not possible nor is it a desirable route to go), they 
 would not be used for that compilation.

 as it stands this is a blocker for me, meaning i cannot use LDC 
 for my project.

 /det


Fwiw we have a similar problem with generating excel bindings for 
D functions programmatically.   Current approach will be to 
compile once with a version switch to generate a main that 
produces a DEF file,  run main,  then build without the version 
switch using the DEF file produced in the first stage.   You 
don't need to compile the whole program again if it is built as a 
library.   There may be a better option,  but haven't been able 
to think of one.
Oct 26 2016