I'm compiling with DMD 2.065 using dub, and I've gotten some undefined reference errors for symbols inside my own project.

Trying to run dustmite doesn't help, it keeps reporting that its done in one iteration, and gives me an empty results folder. I've used it before, its pretty straightforward, not sure whats going wrong.

I'm not sure what else to try. This is my first encounter with a linker error that didn't have to do with an external library.

Ok, I've gotten to the bottom of this issue but I'm not totally sure how to submit a bug report for this (no SSCCE: can't get dustmite to work on it, and the problem won't show itself when I use the offending module in isolation) so I will try to sum up the issue and maybe I can provide some useful information for the devs.

I have a generic Vector struct that is constructed by helper functions that deduce the length and element type and forward the arguments to the appropriate constructor. Almost all of them had a constraint on them that required the length of the vector the be at least 2, but the Vector class itself had no such constraint, and one of the helper functions was missing it as well.

When I added the constraint to either the Vector struct or the helper function (I've since added them to both) then everything links fine. It looks like what was happening was that a "fill constructor helper function" (intended use: vector!4 (x) => vector (x, x, x, x)) was routing to a "variadic constructor helper function" (vector (args) => vector!(args.length)(args)) that attempted to generate a 1-element vector and somewhere along the way - linker error.

There are the mangled names that the linker could not resolve references to:

`_D3evx7vectors16__T6VectorVm1TdZ6Vector6__initZ`

`_D3evx7vectors16__T6VectorVm1TdZ6Vector6__ctorMFNaNbNcNfdZS3evx7vectors16__T6VectorVm1TdZ6Vector`

the second of which demangles to this:

pure nothrow ref @safe evx.vectors.Vector!(1uL, double).Vector evx.vectors.Vector!(1uL, double).Vector.__ctor(double)

So, there's my one-element vector constructor, which is likely having a hard time with the following overloads:

	this (Elements...)(Elements elements)
	if (Elements.length == length)
	{
		foreach (i, element; elements)
			components[i] = element;
	}
	this (Element element)
	{
		components[] = element;
	}

So, while the mistake was mine, this should be an ambiguous overload error at compile-time, instead of a linker error.

I realize that everyone contributing to D has their hands more than full, and a bug this rare (assumption based on lack of search results) is gonna be low-priority, so I'm just making this post for posterity - maybe it'll help, and of course I'm happy to try anything and give additional information. If anyone has any suggestions on how I might go about making a useful bug report out of this, I'm all ears.

On Monday, 11 August 2014 at 03:12:45 UTC, Vlad Levenfeld wrote:
[snip]

> 	this (Elements...)(Elements elements)
> 	if (Elements.length == length)
> 	{
> 		foreach (i, element; elements)
> 			components[i] = element;
> 	}
> 	this (Element element)
> 	{
> 		components[] = element;
> 	}
[snip]

The following gives an error in 2066

struct S(F, size_t L)
{
    F[L] c;
    this(E...)(E el)
    if(E.length == L)
    {
        foreach(i, e; el) {
            c[i]= e;
        }
    }
    this(F e) {
        c[0] = e;
    }
}
void main()
{
    auto s = S!(double, 1)(1);
    auto s = S!(double, 3)(1,2,3); // <-- ERROR: declaration hacks.main.s is already defined
}


Cheers,
uri

On Monday, 11 August 2014 at 04:02:12 UTC, uri wrote:
> On Monday, 11 August 2014 at 03:12:45 UTC, Vlad Levenfeld wrote:
> [snip]
>
>> 	this (Elements...)(Elements elements)
>> 	if (Elements.length == length)
>> 	{
>> 		foreach (i, element; elements)
>> 			components[i] = element;
>> 	}
>> 	this (Element element)
>> 	{
>> 		components[] = element;
>> 	}
> [snip]
>
> The following gives an error in 2066
>
> struct S(F, size_t L)
> {
>     F[L] c;
>     this(E...)(E el)
>     if(E.length == L)
>     {
>         foreach(i, e; el) {
>             c[i]= e;
>         }
>     }
>     this(F e) {
>         c[0] = e;
>     }
> }
> void main()
> {
>     auto s = S!(double, 1)(1);
>     auto s = S!(double, 3)(1,2,3); // <-- ERROR: declaration hacks.main.s is already defined
> }
>
>
> Cheers,
> uri

Bah, never mind me I'm having a moment !

The above example works in 2066 when the second 's' is renamed to s1, as does this:


auto s = S!(float, 1)(1); // eq: S!(float, 1)(1)
auto s1 = S!(float, 2)(1); // eq: S!(float, 2)(1,nan)
auto s2 = S!(float, 2)(1, 2) // eq: S!(float,2)(1,2)


Cheers,
uri

On Mon, Aug 11, 2014 at 03:12:43AM +0000, Vlad Levenfeld via Digitalmars-d-learn wrote: [...]
> So, while the mistake was mine, this should be an ambiguous overload error at compile-time, instead of a linker error.
> 
> I realize that everyone contributing to D has their hands more than full, and a bug this rare (assumption based on lack of search results) is gonna be low-priority, so I'm just making this post for posterity - maybe it'll help, and of course I'm happy to try anything and give additional information. If anyone has any suggestions on how I might go about making a useful bug report out of this, I'm all ears.

While we generally prefer bug reports for which there is a small reproducible test case, I'd also say that filing a bug is better than not filing a bug, because chances are, *somebody* else out there might have encountered the same problem but haven't bothered to report it. If the problem isn't reported, then your helpful description will just get lost in the dusts of forum history, and it will never get fixed. If it's at least filed, then there's *some* hope somebody will figure out what the problem is and fix it.


T

-- 
In order to understand recursion you must first understand recursion.