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: http://stackoverflow.com/questions/20168136/linker-error-cannot-link-d16typeinfo-hayayaa6-initz/20168874#20168874 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: http://stackoverflow.com/questions/20168136/linker-error-cannot-link-d16typeinfo-hayayaa6-initz/20168874#20168874 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