Dlib: imglab only builds in debug after using vcpkg

[Andyjk1406]

This may be an issue with vcpkg but....

I installed dlib (VS 2017 x64) using vcpkg (painlessly, and all dependencies built too)

I could not get imglab to build via cmake:
Cannot find source file: external/libpng/png.c
(This is probably because with vcpkg, libpng just gets built elsewhere - I have no 'external' folder in my dlib folders)

BUT given the magic of vcpkg I can build imglab in DEBUG as follows (without using CMAKE):
1) Create an empty project in VS2017, add all the files from the imglab src folder
2) Manually add the dlib/all/source.cpp file
3) Set /bigobj in the command line build rules

However, if I try and switch to RELEASE mode and do exactly the same, I get:
cluster.obj : error LNK2001: unresolved external symbol USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_use_of_DEBUG_or_ENABLE_ASSERTS_preprocessor_directives
1>c:UsersandresourcereposimgToolx64Releaseimglab.exe : fatal error LNK1120: 1 unresolved externals

I'm lost as to what is wrong since DEBUG and RELEASE libs should have been built with vcpkg install.
Are there some hard-coded ASSERTS that mean imglab is DEBUG only ?

Thanks

[davisking]

No, there is no hard coding of anything like that anywhere in dlib's code.

Why don't you just build imglab with cmake? If you got a copy of dlib (from an official source) and just ran cmake on the imglab folder it would build without error. What's the point of using vcpkg?

Also, I don't have anything to do with vcpkg and I don't think you should use it. If you are getting these errors they have obviously repackaged dlib's code in some idiotic way. Does vcpkg download precompiled binaries? It sounds like they compiled dlib in debug mode and then distributed that one binary for all versions.

In visual studio you aren't allowed to mix debug and release mode object files. There are also non-visual studio reasons to not do this like violations of C++'s one definition rule. None of this has anything do with dlib. So the vcpkg maintainers should know better than to do what they apparently did. I should also emphasize that the error you are getting is something I put in dlib's code specifically to detect when people, generally new to C++, cause violations of the one definition rule by compiling object files in inconsistent ways. What would normally happen if that bit of code wasn't there was your program would compile and run. Maybe it would work, maybe it wouldn't, maybe it would run for days and then mysteriously crash. Who knows, because violations of the one definition rule mean the resulting program has undefined behavior.

[davisking]

Sorry if I sound mad. But I'm just irritated that vcpkg has apparently repackaged dlib and broke it. I'm now going to get a bunch of people asking questions about it over and over. I just installed vcpkg myself (for the first time) and did vcpkg install dlib and it ran for a while and eventually generated an error about how I'm not running it in x64 mode. So I couldn't even get as far as you did with it.

Anyway, don't use vcpkg. I spend the last 20 minutes reading their docs and it's kinda appalling. You should really use cmake instead. CMake works, doesn't involve a bunch of hidden magic like automatically linking all your visual studio projects behind the scenes (and apparently messing it up), and it works on platforms other than those provided by Microsoft.

[Andyjk1406]

Thanks Davis - no problem sounding mad!
I am happy to use CMake but happened to be trying vcpkg to simplify Ceres building on Windows and I noticed Dlib was on their list too.
I'll switch back to the standard way and hope this thread gets some hits to avoid too many questions for you.

[ras0219-msft]

Sorry for the trouble to both of you!

I've reproduced and fixed the issue with dlib in Vcpkg -- we were previously using the macro NDEBUG to define DLIB_DISABLE_ASSERTS, but this turned out to be unreliable. I've changed it to rely on _DEBUG, which is automatically defined. git pull && vcpkg upgrade will fix it.

@davisking I completely understand the frustration and I'd really appreciate any more details you'd be willing to share about what didn't work!

[davisking]

When I tried to install I got an error something to the effect of "openblas is only usable in x64". I would expect vspkg install dlib to do the right thing and install openblas in 64bit mode if that's the case. Right, like install only a 64bit of dlib. That's fine. But it just errored out and did nothing in the end.

Also, the dlib asserts already automatically toggle based on the presence of _DEBUG. That is, unless you define DLIB_DISABLE_ASSERTS or DLIB_ENABLE_ASSERTS which just disables/enables it regardless of any other concerns. For visual studio you shouldn't need to do anything to get the right behavior since it already sets _DEBUG in debug mode and not in release mode.

I should also point out that when you build dlib with cmake and install it it creates a config.h file that sets things like DLIB_DISABLE_ASSERTS permanently to avoid this kind of confusion. I don't know what you are doing, using cmake to build dlib at all or not. It sounds like not, but it's something to be aware of.

[ras0219-msft]

Thanks for the explanation! Improving our handling of those situations is definitely on the list, so thanks for contributing a +1 here.

We do actually build dlib with cmake -- unfortunately, to save space for the vast majority of libraries, vcpkg doesn't support different headers across debug/release (we do for different architectures though). Therefore, we are trying to collapse the two config.hs into one that switches based on the configuration -- it's possible that we're actually trying to do too much here and would get the same effect by default if we just deleted the cmake-produced config!

Concretely, we're doing this after the install:

file(READ ${CURRENT_PACKAGES_DIR}/include/dlib/config.h _contents)
string(REPLACE "/* #undef ENABLE_ASSERTS */" "#if defined(_DEBUG)\n#define ENABLE_ASSERTS\n#endif" _contents ${_contents})
string(REPLACE "#define DLIB_DISABLE_ASSERTS" "#if !defined(_DEBUG)\n#define DLIB_DISABLE_ASSERTS\n#endif" _contents ${_contents})
file(WRITE ${CURRENT_PACKAGES_DIR}/include/dlib/config.h ${_contents})

this should have the effect of producing

#if defined(_DEBUG)
#define ENABLE_ASSERTS
#endif
#if !defined(_DEBUG)
#define DLIB_DISABLE_ASSERTS
#endif

(Additionally, if you have the inclination to try again in the future, the current way to handle the x64 issue is vcpkg install dlib:x64-windows or vcpkg install dlib --triplet x64-windows.)

[davisking]

Ok, it sounds like you are doing the sensible thing given the circumstances.

Yeah, I'll let you know if I run into more trouble.