www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - undefined reference to `_D16TypeInfo_HAyayAa6__initZ'

reply "Jeroen Bollen" <jbinero gmail.com> writes:
I am getting this weird linker error when compiling my code; what 
does it mean?
Nov 23 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jeroen Bollen:


 I am getting this weird linker error when compiling my code; 
 what does it mean?


If your code used to work, and you have just tried dmd 2.064 then 
as try to compile with -allinst.

Bye,
bearophile
Nov 23 2013
parent "Jeroen Bollen" <jbinero gmail.com> writes:
On Saturday, 23 November 2013 at 21:32:13 UTC, bearophile wrote:

 Jeroen Bollen:


 I am getting this weird linker error when compiling my code; 
 what does it mean?


 If your code used to work, and you have just tried dmd 2.064 
 then as try to compile with -allinst.

 Bye,
 bearophile


No luck with that flag.
Nov 23 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jeroen Bollen:


 I am getting this weird linker error when compiling my code; 
 what does it mean?


Is your code not compiling since switching to a newer compiler? 
What system and compilers are you using? How many modules are in 
your program, and what build strategy/software are you using?

Bye,
bearophile
Nov 23 2013
parent reply "Jeroen Bollen" <jbinero gmail.com> writes:
On Saturday, 23 November 2013 at 22:34:54 UTC, bearophile wrote:

 Jeroen Bollen:


 I am getting this weird linker error when compiling my code; 
 what does it mean?


 Is your code not compiling since switching to a newer compiler? 
 What system and compilers are you using? How many modules are 
 in your program, and what build strategy/software are you using?

 Bye,
 bearophile


It's the first time I compiled it. I am using a regular compile 
command


 dmd -m64 -of"../Build/main" (lots of files here)


Linux 64 bits
Nov 23 2013
parent reply "Jeroen Bollen" <jbinero gmail.com> writes:
I added the code to my GitHub repo; there don't seem to be any 
uncommon associative arrays: 
https://github.com/SanePumpkins/FastCGI.D
Nov 23 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 23 November 2013 at 23:30:09 UTC, Jeroen Bollen 
wrote:

 I added the code to my GitHub repo; there don't seem to be any 
 uncommon associative arrays:


Yea, it is the immutable string[string], I used the same pattern 
in my cgi.d and saw that too (sometimes, like I said, it is 
randomly there or not. it seems to be the outer immutable that 
triggers the problem.

BTW, my cgi.d has fastcgi support too
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/cgi.d

compile with -version=fastcgi. It uses the C libfcgi in that 
mode. Feel free to copy any of my code you want if it is helpful 
to you.
Nov 23 2013
next sibling parent reply "Jeroen Bollen" <jbinero gmail.com> writes:
On Saturday, 23 November 2013 at 23:47:11 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 23 November 2013 at 23:30:09 UTC, Jeroen Bollen 
 wrote:

 I added the code to my GitHub repo; there don't seem to be any 
 uncommon associative arrays:


 Yea, it is the immutable string[string], I used the same 
 pattern in my cgi.d and saw that too (sometimes, like I said, 
 it is randomly there or not. it seems to be the outer immutable 
 that triggers the problem.

 BTW, my cgi.d has fastcgi support too
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/cgi.d

 compile with -version=fastcgi. It uses the C libfcgi in that 
 mode. Feel free to copy any of my code you want if it is 
 helpful to you.


Your work actually inspired mine. I saw it used some external 
code so I am basically writing it without those. Somewhere in 
progress of that I managed to completely throw over the structure 
of the code, and well yeah, now I ended up with that. :P
Nov 23 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 24 November 2013 at 00:01:32 UTC, Jeroen Bollen wrote:

 Your work actually inspired mine. I saw it used some external 
 code so I am basically writing it without those.


Oh cool!
Nov 23 2013
prev sibling next sibling parent reply "Jeroen Bollen" <jbinero gmail.com> writes:
On Saturday, 23 November 2013 at 23:47:11 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 23 November 2013 at 23:30:09 UTC, Jeroen Bollen 
 wrote:

 I added the code to my GitHub repo; there don't seem to be any 
 uncommon associative arrays:


 Yea, it is the immutable string[string], I used the same 
 pattern in my cgi.d and saw that too (sometimes, like I said, 
 it is randomly there or not. it seems to be the outer immutable 
 that triggers the problem.

 BTW, my cgi.d has fastcgi support too
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/cgi.d

 compile with -version=fastcgi. It uses the C libfcgi in that 
 mode. Feel free to copy any of my code you want if it is 
 helpful to you.


Does yHAyaAa mean:


 immutable (immutable char)[char[]]


Itt seems pretty odd. :s
Nov 23 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 24 November 2013 at 00:14:22 UTC, Jeroen Bollen wrote:

 Does yHAyaAa mean:


 immutable (immutable char)[char[]]




Looks like you got the key and value backwards there and missed 
an 'A' too (I was just writing about this on SO too, but the 
comment limit meant I cut a bit short there).

You're right about the outer immutable, the first 'y'. Then 'H' 
is assoc array. Then you read the next type as the key: 'Aya', 
which is array of immutable char, or immutable(char)[]. ('Aya' is 
one you'll see a lot in mangles, since it means string. recall 
that string is just an alias for immutable(char)[].)

Then, you read the value type, 'Aa', which is indeed array of 
char, aka char[].


Putting it together:

we have an immutable associative array ('yH')
key type: immutable(char)[] (or string) ('Aya')
value type: char[] ('Aa')

most likely written in the code as:
immutable char[][string]




There really shouldn't be a reason to do this by hand, though it 
can be useful to recognize the patterns by eyeball, when 
debugging and such. core.demangle, or the ddemangle included in 
the dmd distribution, generally do a good job with these, so when 
in doubt, you can just paste the mangled name into them. There's 
just a few cases it doesn't handle:


There's some mangled names that cannot be demangled. dmd can 
generate some *really* long names, including some that optlink 
can't. The solution to that dilemma is if a name is too long (128 
chars), it first tries to do a simple compression on it. This 
replaces long subsequences with a length-offset pair. Potentially 
readable by a computer, but would be a pain to do by hand. You'd 
recognize these if the name has non-ascii characters.

Then, if it is still too long, the end gets chopped off and 
replaced with a partial MD5 sum instead. Since md5 sums are a 
one-way hash, not even a bug-free demangle program would reliably 
be able to understand these.


I think the reason that "_D16TypeInfo_HAyayAa6__initZ" couldn't 
get automatically demangled is because it is a special name that 
doesn't actually follow the ABI spec. It's compiler generated 
info whose mangle looks kinda like a function, but it lacks the 
calling convention or return value that core.demangle requires to 
be there to consider a valid name.

http://dlang.org/abi.html

Let's go ahead and add that info though. A fully mangled name 
starts with "_D", then has the name with all scope info. The way 
this is encoded is simply length of piece, string name, repeat 
for all pieces. So "foo.bar" becomes "3foo3bar".

Then, the type is encoded, as we discussed above. The typeinfo 
name is closest to a function: 'Z' near the end terminates the 
argument list... but the spec says a function type mangle should 
first have given a calling convention, and at the end, given a 
return type of the function.

'F' means function with D calling convention. We'll put that at 
the end of the name, right before the 'Z':

"_D16TypeInfo_HAyayAa6__initFZ"

then the spec says return value goes at the very end. Let's use 
'v' for void:

"_D16TypeInfo_HAyayAa6__initFZv"


Does ddemangle accept it?

$ echo "_D16TypeInfo_HAyayAa6__initFZv" | ./ddemangle
void TypeInfo_HAyayAa.__init()


Yes, it did! Why, then is there still 'HAyayAa' in there? The 
reason is that's actually the internal name of the TypeInfo 
class, so strictly speaking, it is correct to demangle it to this.

Pop open dmd2/src/druntime/src/rt/typeinfo/ty_int.d for example. 
In that file, you'll see:

"class TypeInfo_i : TypeInfo"

Try ti_void.d in the same file, and you'll see:

"class TypeInfo_v : TypeInfo"

all the names in those files follow the same pattern: create a 
subclass of Typeinfo with the name "Typeinfo_mangle".

(BTW, I'm pretty sure that whole group of files could be 
auto-generated with __traits in modern D, but they had to be 
hand-written in old D to provide some foundation.)


So that crazy name "TypeInfo_HAyayAa" actually follows the very 
same pattern. This might be the one time outside eyeball 
debugging when knowing your mangles by hand is actually useful!

On the other hand, perhaps it'd be a good idea to add recognition 
of this pattern to core.demangle, so it can print out the much 
prettier

typeid(immutable char[][immutable(char)[]])

cuz that's how you'd likely refer to it in code anyway (and 
that's close to what i wrote for the hack fix too). I'll do an 
enhancement request in bugzilla after I submit this and maybe 
write it myself later too, but it is bed time now.
Nov 23 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 24 November 2013 at 03:41:20 UTC, Adam D. Ruppe wrote:

 enhancement request in bugzilla


https://d.puremagic.com/issues/show_bug.cgi?id=11586
Nov 23 2013
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Saturday, 23 November 2013 at 23:47:11 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 23 November 2013 at 23:30:09 UTC, Jeroen Bollen 
 wrote:

 I added the code to my GitHub repo; there don't seem to be any 
 uncommon associative arrays:


 Yea, it is the immutable string[string], I used the same 
 pattern in my cgi.d and saw that too (sometimes, like I said, 
 it is randomly there or not. it seems to be the outer immutable 
 that triggers the problem.

 BTW, my cgi.d has fastcgi support too
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/cgi.d

 compile with -version=fastcgi. It uses the C libfcgi in that 
 mode. Feel free to copy any of my code you want if it is 
 helpful to you.


Adam, does it support multiplexing? Looks like people do not care 
much about that FastCGI feature... :(
Nov 24 2013
next sibling parent "Jeroen Bollen" <jbinero gmail.com> writes:
On Sunday, 24 November 2013 at 12:07:18 UTC, Dejan Lekic wrote:

 On Saturday, 23 November 2013 at 23:47:11 UTC, Adam D. Ruppe 
 wrote:

 On Saturday, 23 November 2013 at 23:30:09 UTC, Jeroen Bollen 
 wrote:

 I added the code to my GitHub repo; there don't seem to be 
 any uncommon associative arrays:


 Yea, it is the immutable string[string], I used the same 
 pattern in my cgi.d and saw that too (sometimes, like I said, 
 it is randomly there or not. it seems to be the outer 
 immutable that triggers the problem.

 BTW, my cgi.d has fastcgi support too
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/cgi.d

 compile with -version=fastcgi. It uses the C libfcgi in that 
 mode. Feel free to copy any of my code you want if it is 
 helpful to you.


 Adam, does it support multiplexing? Looks like people do not 
 care much about that FastCGI feature... :(


My library does but it doesn't have an interface for requests yet 
so you'll have to manually 'build' them using the records.
Nov 24 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 24 November 2013 at 12:07:18 UTC, Dejan Lekic wrote:

 Adam, does it support multiplexing? Looks like people do not 
 care much about that FastCGI feature... :(


I don't really know, I just wrote the loop similar to the libfcgi 
example and left it at that. So probably not, unless the c lib 
does something under the hood.

The other modes for scgi and httpd can do multiple requests per 
connection though.
Nov 24 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 23 November 2013 at 21:05:59 UTC, Jeroen Bollen 
wrote:

 I am getting this weird linker error when compiling my code; 
 what does it mean?


I saw this on stackoverflow first and answered there, let me link 
it:



I've been seeing this problem on and off for years now, but can 
never get it minimized to a good test case. I think the order of 
files on the compile command line matter along with other hard to 
track down factors. So I just hack around it and move on.

Not sure if the type in there is right, I demangled it by eyeball 
(why wouldn't the core.demangle work on that? it isn't even that 
complex of a type, if I'm right...)
Nov 23 2013
parent "Jeroen Bollen" <jbinero gmail.com> writes:
On Saturday, 23 November 2013 at 22:49:54 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 23 November 2013 at 21:05:59 UTC, Jeroen Bollen 
 wrote:

 I am getting this weird linker error when compiling my code; 
 what does it mean?


 I saw this on stackoverflow first and answered there, let me 
 link it:



 I've been seeing this problem on and off for years now, but can 
 never get it minimized to a good test case. I think the order 
 of files on the compile command line matter along with other 
 hard to track down factors. So I just hack around it and move 
 on.

 Not sure if the type in there is right, I demangled it by 
 eyeball (why wouldn't the core.demangle work on that? it isn't 
 even that complex of a type, if I'm right...)


Flagged as Answer
Nov 23 2013