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.

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

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

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

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

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.

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

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