www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Unresolved Symbols in a nanovg Library

reply Jason C. Wells <example example.com> writes:
I've gone about building static libraries for nanovg and arsd. 
(I'm feeling pretty good about what I've learned in the last 
couple days, so I gave it a whirl.)

arsd has ttf.d and stb_truetype.d. Comments in stb_truetype.d say 
use ttf.d instead.

nanovg has a ttf.d also.

There are three ttf.d's to choose from.

nanovg has linker errors:
..\..\..\lib\libnanovg.lib(nanovg)
  Error 42: Symbol Undefined 
_D2iv3stb3ttf25stbtt_ScaleForPixelHeightFPxS2iv3stb3ttf14stbtt_fontinfofZf

I'm not sure I fully understand name mangling, but it looks like 
nanovg wants to use iv\stb\ttf.d from it's own source tree. But 
Ketmar said "p.s. you will also need stb_ttf port, arsd repo has 
it under the name "ttf.d"."

So which ttf.d should I use? Does it matter?

I've gained enough confidence in the last couple days to go ahead 
and use trial and error to sort this out. I thought I'd let you 
guys chime in.

Perhaps Ketmar intended to remove his copy of ttf.d from his repo?

Regards,
Jason C. Wells
Oct 26 2016
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 27 October 2016 at 01:48:54 UTC, Jason C. Wells 
wrote:
 I'm not sure I fully understand name mangling, but it looks 
 like nanovg wants to use iv\stb\ttf.d from it's own source 
 tree. But Ketmar said "p.s. you will also need stb_ttf port, 
 arsd repo has it under the name "ttf.d"."

 So which ttf.d should I use? Does it matter?
it really doesn't, but you should have only one. ;-) the idea is that nanovg tries to import several stb_truetype ports (including iv.freetype bindings) and will use the first one that imported successfully. it is, again, works nice with rdmd and full IV repo, but may fail if you'll pass Adam's ttf.d in command line, while there is iv.ttf accessible on the disk. in this case importing of iv.ttf will succeed, but the code will be generated for arsd.ttf. oops.
 Perhaps Ketmar intended to remove his copy of ttf.d from his 
 repo?
quite the contrary. ;-) if anything resides in IV, then it is preferred thing to use with any IV modules. i strongly suggest you to move to rdmd, it can do most of such things for you. ;-) as for nanovg, the preferred is iv.freetype, actually. then iv.ttf, then arsd.ttf. btw, you can find me on IRC channel (and Adam too), and ask your questions in real-time (well, if we are online ;-).
Oct 26 2016
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 27 October 2016 at 01:48:54 UTC, Jason C. Wells 
wrote:
 arsd has ttf.d and stb_truetype.d. Comments in stb_truetype.d 
 say use ttf.d instead.
My ttf.d is just version 1.2 of stb_truetype.d basically... the two files are very similar and should be generally compatible. ketmar's ttf.d I think is about 95% the same (we both ported the same C library), but slightly different, including a different module name... so you should be able to compile in both my ttf.d and his ttf.d at the same time. Though I betcha his alone will be fine, or mine alone might be fine if you change the import statement (use `import arsd.ttf;` rather than `import iv.stb.ttf;`, the rest are probably compatible.)
Oct 26 2016
prev sibling parent reply Jason C. Wells <example example.com> writes:
Adding iv\stb\ttf.d cleared up most of the remaining linker 
errors.

While compiling iv\nanovg_demo\example.d I am left with:

bin\example.obj(example)
  Error 42: Symbol Undefined _D2iv6nanovg3oui12__ModuleInfoZ

bin\example.obj(example)
  Error 42: Symbol Undefined _D2iv6nanovg12__ModuleInfoZ

..\..\..\lib\libarsd.lib(jpeg)
  Error 42: Symbol Undefined _D2iv3vfs12__ModuleInfoZ

I have no idea where this ModuleInfoZ thing is coming from. I 
searched the sources for the string "ModuleInfoZ" but that string 
appears only in obj/def files. I suppose that the compile/linker 
adds this symbol to object files.

How do I fix the missing ModuleInfoZ symbol?

I am quite surprised that arsd is looking for iv\vfs\_something_.

I should mention that I have been "picky" about which files I 
included on the dmd command line.
Oct 26 2016
next sibling parent reply Jason C. Wells <example example.com> writes:
BTW, I am not ignoring you guys when I haven't used rdmd ( I 
tried briefly but got stuck) or specifying all *.d files on the 
command line (did that with some success). My learning process is 
very organic and trial and error.

I appreciate what you are doing for me. Thanks for the invite to 
chat on irc. I don't have an urgent need so I'll post here. Maybe 
other noobs will make use of this.
Oct 26 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 27 October 2016 at 02:18:26 UTC, Jason C. Wells 
wrote:
 My learning process is very organic and trial and error.
yeah, that's us too :) With time, knowing all the details is better - you'll learn a lot though the start can be slower. I usually keep my code simple, but there's a few fancy tricks mixed in too (like lazy imports or speculative modules...) so sometimes it is harder than you'd expect. Also, my "package" is more just a collection of independent modules you can add to your project and hack on than something intended to be compiled separately. So you're kinda going against the grain... but it is educational and you can make it work!
Oct 26 2016
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 27 October 2016 at 02:12:34 UTC, Jason C. Wells 
wrote:
  Error 42: Symbol Undefined _D2iv6nanovg3oui12__ModuleInfoZ
That means some module was imported but not compiled. You can run the `ddemangle` program that comes with dmd to translate it (or you'll get used to just reading it by eyeball - the pattern is _Dxyyy, repeated. The x is a number saying how long the next name is, and the yyy is the next part of the name. So 2iv6nanovg becomes iv.nanovg). That means the iv.nanovg.oui was imported somewhere but not compiled in. The example surely uses it. ModuleInfo is auto-generated by the compiler for each module.
 I am quite surprised that arsd is looking for 
 iv\vfs\_something_.
ketmar and I semi-collaborate... our stuff is independent, but we know a number of more advanced tricks to selectively import if a file is available on the system. So my jpeg.d (which was actually primarily authored by ketmar, well, he ported a C library and put an interface on top, then merged with my old jpg.d) will see if iv.vfs is available on the file system, and if it is, it will import it. That works well if you just download a few files at a time (which is how I generally distribute my libs, I say "download file.d and other.d"), but if you downloaded *everything*, it will see it is there and try to show additional features. But since you aren't compiling everything you have available, it sees it is there...but it isn't all built.
Oct 26 2016
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 27 October 2016 at 02:12:34 UTC, Jason C. Wells 
wrote:
 I have no idea where this ModuleInfoZ thing is coming from.
as Adam said, it means that it imports some module, and you didn't passed it to dmd. in this case, it is iv.nanovg.oui package (this is Blender-like GUI controls -- not a full GUI package, just GUI controls and some simple things). example is using that to draw OUI window to impress the end user. ;-)
 How do I fix the missing ModuleInfoZ symbol?
just add everything from iv/nanovg/oui to dmd invocation.
 BTW, I am not ignoring you guys when I haven't used rdmd ( I 
 tried briefly but got stuck) or specifying all *.d files on the 
 command line (did that with some success). My learning process 
 is very organic and trial and error.
there is nothing wrong in that, of course. i keep telling about rdmd only 'cause it is easier to get at least *something* with it. but you'll eventually get it working with dmd too, and this is harder, but better way if you want to really grok the things. ;-)
Oct 26 2016
parent Jason C. Wells <example example.com> writes:
I have a nice screen shot of the nanovg demo running. The old 
xeyes is a nice touch. I was excited to post the photo here but 
it looks like I cannot. I can tell by the animations that this 
will be precisely what I need to animate svg based 
instrumentation.

I ended up making one more static library for iv\vfs. I also 
ended up editing iv\vfs\package.d to comment out the reference to 
arcs. I was getting tired of following the missing symbols down 
the rabbit hole.

The ModuleInfoZ missing symbols were due to the package.d files 
in every case. I'll have to read up on those a bit more.

Oh and, as the end user, that demo has me all impressed. :)

Regards,
Jason C. Wells
Oct 26 2016