www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - undefined references

reply "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
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.
Aug 10 2014
parent reply "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
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.
Aug 10 2014
next sibling parent reply "uri" <uri gmail.com> writes:
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
Aug 10 2014
parent "uri" <uri gmail.com> writes:
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
Aug 10 2014
prev sibling parent "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
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.
Aug 10 2014