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

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

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)

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

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

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. ;)

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

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.