www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CTFE in .di files

reply Manu <turkeyman gmail.com> writes:
I've been having some problems like this:
https://issues.dlang.org/show_bug.cgi?id=18774

I have .di files with mixins that generate declarations using CTFE.
Trouble is, executing the CTFE seems to leave residual references to
symbols which result in unresolved link errors in the client of the
.di file.
This seems wrong to me. CTFE shouldn't leave residual dependencies on
runtime symbols... is this a well-known issue? Are there common
workarounds?

I'm surprised I haven't run into this before... I must have just
luckily managed to avoid the specific problem structure.
Apr 17 2018
next sibling parent reply Diego Lago <diego.lago.gonzalez gmail.com> writes:
Could this issue be related?

https://issues.dlang.org/show_bug.cgi?id=18485

It is about *.di files but it isn't related with CTFE.

--
Diego
Apr 18 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, April 18, 2018 07:25:17 Diego Lago via Digitalmars-d wrote:

 Could this issue be related?

 https://issues.dlang.org/show_bug.cgi?id=18485

 It is about *.di files but it isn't related with CTFE.


Without digging through the compiler internals, I couldn't say with 100%
certainty that they arent related, but what Manu is hitting isn't a
segfault, and I doubt that they're particularly related. Maybe the problems
come from similar sections of code, but the results are quite different.

In Manu's case, it's seems to be that when you import a module that uses
CTFE to generate code within that module, but you don't actually compile the
module into your program, then at least some of the time, some of the
symbols that were used during CTFE are referenced in the object file but
don't exist, so the linker gives an error. So, it seems like some symbol
references are getting into the object file when they shouldn't, and that's
very different from segfaulting.

Curiously, I can't reproduce the problem on my FreeBSD system, so I wonder
if it's Windows-specific (or at least that the linker on FreeBSD doesn't
choke in the same way - the object files may or may not have a similar
problem). I don't know if it's happening on Linux or OS X or not. If I
understand correctly, Manu has been hitting the problem with 64-bit Windows.

- Jonathan M Davis
Apr 18 2018
parent reply Jacob Carlborg <doob me.com> writes:
On Wednesday, 18 April 2018 at 08:12:43 UTC, Jonathan M Davis 
wrote:


 Curiously, I can't reproduce the problem on my FreeBSD system, 
 so I wonder if it's Windows-specific (or at least that the 
 linker on FreeBSD doesn't choke in the same way - the object 
 files may or may not have a similar problem). I don't know if 
 it's happening on Linux or OS X or not.


Same problem on macOS.


 If I understand correctly, Manu has been hitting the problem 
 with 64-bit Windows.


The mangling in the reported issue is the same as for Posix. Does 
Windows 64-bit use the same mangling as Posix?

Interestingly, if I add a call to  "zip" in the main D file, I 
get an additional missing symbol:

import test;

import std.range;

int main()
{
     // test_func(1, 2);
     auto b = zip(["int","int"], ["a","b"]);
     return 0;
}

Undefined symbols for architecture x86_64:
   "__D3std5range__T3ZipTAAyaTQfZQn6__initZ", referenced from:
       __D38TypeInfo_S3std5range__T3ZipTAAyaTQfZQn6__initZ in 
main.o
   
"__D3std5range__T3zipTAAyaTQfZQnFNaNbNiNfQtQvZSQBrQBq__T3ZipTQBnTQBrZQn",
referenced from:
       __Dmain in main.o

--
/Jacob Carlborg
Apr 18 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, April 18, 2018 09:16:14 Jacob Carlborg via Digitalmars-d 
wrote:

 On Wednesday, 18 April 2018 at 08:12:43 UTC, Jonathan M Davis

 wrote:

 Curiously, I can't reproduce the problem on my FreeBSD system,
 so I wonder if it's Windows-specific (or at least that the
 linker on FreeBSD doesn't choke in the same way - the object
 files may or may not have a similar problem). I don't know if
 it's happening on Linux or OS X or not.


 Same problem on macOS.


As in you're seeing the same problem Manu is, or as in you're not seeing it
on Mac OS X, just like I'm not seeing it on FreeBSD? I'd guess the latter
given how close FreeBSD and Mac OS X are, but the way you said it wasn't
clear.


 If I understand correctly, Manu has been hitting the problem
 with 64-bit Windows.


 The mangling in the reported issue is the same as for Posix. Does
 Windows 64-bit use the same mangling as Posix?


Well, with D name mangling, I don't see any reason for it to differ across
systems, since it's defined by us. It's the C++ name mangling that would be
different depending on the target, since that involves different C++
compilers, and for better or worse, the C++ folks never agreed on a standard
for name mangling.

- Jonathan M Davis
Apr 18 2018
parent Jacob Carlborg <doob me.com> writes:
On 2018-04-18 11:35, Jonathan M Davis wrote:


 As in you're seeing the same problem Manu is, or as in you're not seeing it
 on Mac OS X, just like I'm not seeing it on FreeBSD? I'd guess the latter
 given how close FreeBSD and Mac OS X are, but the way you said it wasn't
 clear.


I am seeing the same problem as Manu on macOS.


 Well, with D name mangling, I don't see any reason for it to differ across
 systems, since it's defined by us. It's the C++ name mangling that would be
 different depending on the target, since that involves different C++
 compilers, and for better or worse, the C++ folks never agreed on a standard
 for name mangling.


Right. I got those mixed up.

-- 
/Jacob Carlborg
Apr 18 2018
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 17 April 2018 at 22:19:19 UTC, Manu wrote:

 I've been having some problems like this: 
 https://issues.dlang.org/show_bug.cgi?id=18774

 I have .di files with mixins that generate declarations using 
 CTFE.
 Trouble is, executing the CTFE seems to leave residual 
 references to
 symbols which result in unresolved link errors in the client of 
 the
 .di file.
 This seems wrong to me. CTFE shouldn't leave residual 
 dependencies on
 runtime symbols... is this a well-known issue? Are there common
 workarounds?

 I'm surprised I haven't run into this before... I must have 
 just luckily managed to avoid the specific problem structure.


stick an empty extern(C) function into your module with the name 
the linker complained about.
Apr 18 2018
parent Manu <turkeyman gmail.com> writes:
On 18 April 2018 at 08:10, Stefan Koch via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 17 April 2018 at 22:19:19 UTC, Manu wrote:

 I've been having some problems like this:
 https://issues.dlang.org/show_bug.cgi?id=18774

 I have .di files with mixins that generate declarations using CTFE.
 Trouble is, executing the CTFE seems to leave residual references to
 symbols which result in unresolved link errors in the client of the
 .di file.
 This seems wrong to me. CTFE shouldn't leave residual dependencies on
 runtime symbols... is this a well-known issue? Are there common
 workarounds?

 I'm surprised I haven't run into this before... I must have just luckily
 managed to avoid the specific problem structure.



 stick an empty extern(C) function into your module with the name the linker
 complained about.


You sly dog! :P
Apr 18 2018