Can't get bindbc packages to play nice together. bindbc-freetype undefined identifier

[WhatMeWorry]

// dub.sdl
// All of the following "bindbc-projects" use "bindbc-loader" version="~>0.1.0"
// except "bindbc-freeimage" which uses "bindbc-loader" version="~>0.2.1"

dependency "bindbc-freeimage" version="~>0.1.1" 
versions "FI_317"
dependency "bindbc-sdl"       version="~>0.7.0"
versions "SDL_202"
versions "BindSDL_Mixer" 
dependency "bindbc-freetype"  version="~>0.3.0"
versions "FT_210"
dependency "bindbc-opengl"    version="~>0.7.1"
versions "GL_41"
dependency "bindbc-glfw"      version="~>0.3.0"
versions "GLFW_32"

duball build --arch=x86_64 --compiler=ldc2 --verbose

returns:

......\AppData\Local\dub\packages\bindbc-freetype-0.3.0\bindbc-freetype\source\bindbc\freetype\dynload.d(65,15): Error: undefined identifier loadFreetype, did you mean function loadFreeType?

I do see the following output before the compilation error:

Selected package bindbc-loader 0.2.1 does not match the dependency specification ~>0.1.0 in package bindbc-sdl. Need to "dub upgrade"?
Selected package bindbc-loader 0.2.1 does not match the dependency specification ~>0.1.0 in package bindbc-sdl. Need to "dub upgrade"?
Selected package bindbc-loader 0.2.1 does not match the dependency specification ~>0.1.0 in package bindbc-freetype. Need to "dub upgrade"?
Selected package bindbc-loader 0.2.1 does not match the dependency specification ~>0.1.0 in package bindbc-freetype. Need to "dub upgrade"?
Selected package bindbc-loader 0.2.1 does not match the dependency specification ~>0.1.0 in package bindbc-opengl. Need to "dub upgrade"?
Selected package bindbc-loader 0.2.1 does not match the dependency specification ~>0.1.0 in package bindbc-glfw. Need to "dub upgrade"?
Selected package bindbc-loader 0.2.1 does not match the dependency specification ~>0.1.0 in package bindbc-glfw. Need to "dub upgrade"?
Generating using build
Configuring dependent 06_03_04_levels, deps:"bindbc-freeimage", "bindbc-freetype", "bindbc-glfw", "bindbc-opengl", "bindbc-sdl"
  Configuring dependent bindbc-freeimage, deps:"bindbc-loader"
    Configuring dependent bindbc-loader, deps:
  Configuring dependent bindbc-freetype, deps:"bindbc-loader"
  Configuring dependent bindbc-glfw, deps:"bindbc-loader"
  Configuring dependent bindbc-opengl, deps:"bindbc-loader"
  Configuring dependent bindbc-sdl, deps:"bindbc-loader"

However, when I try a dub upgrades, I get this general pattern:

C:\Users\kheaser\Delivery\apps\06_03_04_levels>dub upgrade bindbc-glfw
Upgrading project in C:\Users\kheaser\Delivery\apps\06_03_04_levels
Unresolvable dependencies to package bindbc-loader:
  bindbc-freeimage 0.1.1 depends on bindbc-loader ~>0.2.1
  bindbc-freeimage 0.1.1 depends on bindbc-loader ~>0.2.1
  bindbc-sdl 0.7.0 depends on bindbc-loader ~>0.1.0
  bindbc-sdl 0.7.0 depends on bindbc-loader ~>0.1.0

[mdparker]

Yes, my mistake. I should have updated everything to the 0.2.1 loader. It's done now, so upgrading should work.

[WhatMeWorry]

I've updated all the projects to the latest version. So my dub.sdl looks like:

dependency "bindbc-freeimage" version="~>0.1.1" 
versions "FI_317"
dependency "bindbc-sdl"       version="~>0.8.0"
versions "SDL_202"
versions "BindSDL_Mixer" 
dependency "bindbc-freetype"  version="~>0.4.1"
versions "FT_210"
dependency "bindbc-opengl"    version="~>0.8.0"
versions "GL_41"
dependency "bindbc-glfw"      version="~>0.4.0"
versions "GLFW_32"

I did a >dub upgrade bindbc-xxx on all five of the packages being used.

The good news is that all the "bindbc-loader 0.2.1 does not match the dependency specification ~>0.1.0" messages went away.

However, there is this minor compile error:

C:\Users\kheaser\Delivery\apps\06_03_04_levels>.\..\duball build --arch=x86_64 --compiler=ldc2 --verbose
Target 'C:\Users\kheaser\AppData\Local\dub\packages\bindbc-freetype-0.4.1\bindbc-freetype\.dub\build\dynamic-debug-windows-x86_64-ldc_2084-98EFDEFAB389223C22355F3FFA78A145\BindBC_FT.lib' doesn't exist, need rebuild.
bindbc-freetype 0.4.1: building configuration "dynamic"...
ldc2 -march=x86-64 -lib -of..\..\..\AppData\Local\dub\packages\bindbc-freetype-0.4.1\bindbc-freetype\.dub\build
           (tons of paths deleted for brevity)
..\..\..\AppData\Local\dub\packages\bindbc-freetype-0.4.1\bindbc-freetype\source\bindbc\freetype\package.d -vcolumns
..\..\..\AppData\Local\dub\packages\bindbc-freetype-0.4.1\bindbc-freetype\source\bindbc\freetype\dynload.d(65,15): Error: undefined identifier loadFreetype, did you mean function loadFreeType?
FAIL ..\..\..\AppData\Local\dub\packages\bindbc-freetype-0.4.1\bindbc-freetype\.dub\build\dynamic-debug-windows-x86_64-ldc_2084-98EFDEFAB389223C22355F3FFA78A145\ BindBC_FT staticLibrary
ldc2 failed with exit code 1.
.\..\duball exited with code 2      

The good news is that by simply editing the token to loadFreeType as suggested, the build worked!

However, I might not be using DUB correctly, so it may be my mistake.

[mdparker]

I originally was using the lower-case "t" everywhere ("Freetype"), but that's not really correct. So I changed everything to the upper-case "T" ("FreeType") including the examples in the README. So everything's working now?

[WhatMeWorry]

Yes, thanks. I discovered that dub was ignoring my newer versions in my dub.sdl file. The new versions would only take after I deleted the dubs.selections.json file. After deletion, a new .json file would be created with the correct dub versions. Not sure why .json files are created when I've got a 100% SDLang environment.

So in short, it was a dub issue after all. Now I can get back to what I enjoy programming. Derelict has be very good over the years, but I'm now all in with bindbc. Well, until ASSIMP3 is bindified :)

[mdparker]

DUB always uses the .json format for dub.seclections. It is not dependent on the format of your package file.

dub.selections.json can be a bit of an annoyance. There are good intentions behind it, but in somoe circumstance, it needs to be regenerated and dub doesn't do so. It's been a while since I've had to do it, else I would have remembered and let you know.

However, instead of deleting it, you can IIRC use the --force (or -f) flag when you run dub.