glitches compiling Adobe DNG SDK (dng_validate)


  • Please bear with me as I am new to Visual Studio & am trying to navigate the steep learning curve.

    I am trying to validate the way I have configured the Adobe DNG SDK. This contains the dng_validate project, which I understand I need to be able to build/debug without errors before I can proceed.

    To do this, I have installed VS 2012 (together with VS 2017), because the DNG SDK uses the v120 platform toolset & it pulled numerous errors on my machine until VS 2012 was installed.

    The errors it now throws are "unresolved external symbol" for "gVerbose" and "gDumpLineLimit," seemingly in the following code:

    #if qDNGValidate
    /// When validation (qValidate) is turned on, this global enables verbose
    /// output about DNG tags and other properties.
    extern bool gVerbose;
    /// When validation (qValidate) is turned on, and verbose mode (gVerbose) is
    /// enabled, limits the number of lines of text that are dumped for each tag.
    extern uint32 gDumpLineLimit;

    So I guess my question is this: Is there a simple mistake that I could be making that would create this error? My assumption is that the DNG SDK doesn't contain the mistake, which means I must have made the error (?)

    Any suggestions/direction would be greatly appreciated,


    PS. If it helps, the other reference to qDNGvalidate is in the following code:

    /// \def qDNGValidateTarget 
    /// 1 if dng_validate command line tool is being built, 0 otherwise.
    #ifndef qDNGValidateTarget
    #define qDNGValidateTarget 0
    /// \def qDNGValidate 
    /// 1 if DNG validation code is enabled, 0 otherwise.
    #ifndef qDNGValidate
    #define qDNGValidate qDNGValidateTarget

    Saturday, November 18, 2017 10:53 PM

All replies

    Maybe there is some preprocessor-definition missing(?)/inconsistency(?).
    E.g. I'd try adding something like
    /D "qDNGValidate=1" 

    in project-property-pages (Project->Properties) 'Configuration Properties->C/C++->Command Line' 'Additional Options'
     - would also check, in case there are dependent libraries.

    No warranty

    With kind regards

    Sunday, November 19, 2017 1:26 PM
    Maybe there is some preprocessor-definition missing(?)/inconsistency(?).
    E.g. I'd try adding something like
    /D "qDNGValidate=1" 

    in project-property-pages (Project->Properties) 'Configuration Properties->C/C++->Command Line' 'Additional Options'
     - would also check, in case there are dependent libraries.

    Thanks so much for the reply!

    it looks like /D "qDNGValidate=1" is already defined in the project properties page...

    It would be likely that I've mis-managed dependent libraries... I'll post a query on the Adobe forum to see if I've screwed anything up there & post back once I know.

    much appreciated!

    Sunday, November 19, 2017 7:20 PM
  • Hi Madumi,

    Thanks for your posting.

    To fix external symbol error you may refer to this thread which lists all kinds of potential causes and corresponding solutions.

    and is you are using Adobe DNG, I also suggest you post your issue at Adobe forum where might be a better place to get a professional answer. I found a related case there.  


    Best regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Monday, November 20, 2017 7:51 AM
  • In the meantime downloaded 'Adobe DNG Software Development Kit (SDK) 1.4' zip.
    Skimming through solution (opened in VS2015) properties ...
    dng_sdk library project (DNG Validate target Debug as recommended):

    dng_validate applicaton (Validate Debug as recommended):

    Do you by any chance are building different configurations?
    Looks like there exist some configs, where e.g. for dng_sdk there is explicitely
    With kind regards
    Monday, November 20, 2017 10:27 AM
  • Besides, for you mentioned Visual Studio 2017.
    Just saw, dng_validate application links against libraries (xmp), which are 'precompiled' by a different toolset .
    If you eventually intend to switch to VS2017, would assume, you would need to get hold of the sources of these libraries and
    rebuild them using Visual C++ 2017. 

    Maybe of interest:

    Overview of potential upgrade issues (Visual C++)

    With kind regards
    Monday, November 20, 2017 11:13 AM
  • @MaybeCompletelyW

    Thanks so much for your reply & for taking the time to attempt to debug dng_validate. Were you successful?

    I checked through the different preprocessor definitions, both for dng_sdk & dng_validate & I have the same values as you do (qDNGValidate is defined as "0" in dng_dk, but as "1" in dng_validate). For my side, I am still not able to debug successfully. It still pulls the same errors "unresolved external symbol" for "gVerbose" and "gDumpLineLimit" within dng_validate.

    I posted on the Adobe forum here:

    sandy_mc (who replied) seems pretty knowledgeable, but I can't make out how his answer applies. When I search the VS solution explorer for dng_globals.cpp, it's part of the dng_sdk folder structure, but it's not part of the dng_validate folder structure. But that said, dng_validate references the entire dng_sdk, so wouldn't that link it all back to dng_globals.cpp anyway?

    I've checked all the other solutions on the adobe forums & can't one that helps. Those who have said they've been able to debug successfully simply said they used VS2013 & followed instructions (which I think I have also). At present, I'm not concerned that DNG SDK/XMP needs upgrading to compatibility with VS2017. I'll worry about that later. I'd just like to know that everything in the DNG SDK is in place correctly, even if it's under v120/VS2013

    Wednesday, November 22, 2017 4:46 PM
  • I have the same values as you do (qDNGValidate is defined as "0" in dng_dk, but as "1" in dng_validate).

    Sorry, probably some misunderstanding.

    qDNGValidate may not be defined as null in dng_sdk.

    In VS2015, intellisense shows in this case, as expected, grayed out lines in dng_global.cpp.

    That is, these lines will not get compiled. Linking an application, which declares these variables as 'extern' will fail. (

    Should look like:

    Are you really sure you build 'DNG Validate Target Debug' for this library.

    With kind regards

    Wednesday, November 22, 2017 7:27 PM
  • Also can you confirm, that dng_validate references the correct library?
    E.g. for Win32 would expect:

    With kind regards

    Thursday, November 23, 2017 6:44 AM
  • @MaybeCompletelyW

    Thank you so much for the additional input & sorry for the delay responding... I'm new to VS & was hoping to deal with the learning curve *after* having the dng_validate application compile correctly.

    To answer your questions, indeed, qDNGValidate is not defined in dng_globals.cpp

    With that said, I don't know how to fix this... My assumption, going into this, was that the Adobe DNG SDK would compile dng_validate without errors straight out of the box.

    Is there a simple solution? thanks again so much!

    Wednesday, November 29, 2017 8:22 PM
  • My assumption, going into this, was that the Adobe DNG SDK would compile dng_validate without errors straight out of the box.

    Would agree to your assumption.

    One possible reason, why not:

    After I unpacked the zip-file and loaded it into VS 2015), the settings in 'Solution Property Pages' appeared to be correct, but the 'References' of 'dng_sdk' project seem wrong to me - that is, refer to wrong library.
    So what I would try:
    Make sure having the correct solution configuration (right click on solution in Solution Explorer -> Properties). Should look like this:

    Then remove reference to 'dng_sdk' from 'References' of dng_validate:

    'Add Reference ...' 'dng_sdk' to dng_validate project again:

    'Rebuild Solution'.

    With kind regards

    Wednesday, November 29, 2017 9:51 PM
  • @MaybeCompletelyW

    Thanks so much again for your input. Are you able to build the "Solution" without errors?

    Reason I ask is that I checked the solution configuration, and it appears like your screenshot... And then I removed the dng_sdk reference from dng_validate (as above), and then added the reference back (the only one available for adding was dng_sdk).

    When I try to rebuild, I have the same errors as before... but if you're able to build it without errors, I must be doing something else wrong.

    I'd really value if you could give input again, thanks!

    Thursday, November 30, 2017 12:54 AM
  •  Are you able to build the "Solution" without errors?

    In the meantime yes, not having VS 2013 used VS2017 - Toolset v141/SDK 10.0.16299.0 - (x64) - had to acquire new version of cmake, discovered some 'readmes' about third-party, rebuilt xmp with VS2017, added 'qWinUniversal' to preprocessor, tweaked some Include- and Library-directory-paths, re-evaluated 'References' (see above) but I
    did not have to change anything regarding 'qDNGValidate' IIRC.

    As far as I can see, building the library
    'dng_sdk_x64_DNG Validate Target Debug.lib'
    with 'qDNGValidateTarget=1' implies definition of 'qDNGValidate'.

    Can you show the relevant part of (or the x64 equivalent)

    ...\dng_sdk_1_4\dng_sdk\projects\win\dng_sdk\Win32_DNG Validate Target Debug\obj\dng_sdk.tlog\CL.command.1.tlog

    starting with
    ending with

    With kind regards

    Thursday, November 30, 2017 10:28 AM
  • @MaybeCompletelyW

    Thanks so much again for your reply...

    I am sorry to say I don't quite know what you mean, though I am very willing to learn...

    I am using VS2017 (community edition) as I figured it would be easier to use the same version you're dealing with

    In my file explorer (if that's what you mean), I have E:\dng_sdk_1_4\dng_sdk\projects\win\dng_sdk but no Win32_DNG subfolder in that folder

    I have:




    Do you want me to execute a command to give the results in CL.command.1.tlog? If so, could you give me a hint how to do so. Presently the "Visual Studio 2017" folder in my user/documents folder doesn't have a CL.command.1.tlog file in it (yet)...

    sorry for the ignorance, any guidance would be deeply appreciated, thx!



    I think I found the CL.command.1.tlog file in a sub-folder of the dng_sdk project here:


    the relevant lines from dng_globals.cpp to dng_host.cpp are as follows:

    /c /I../../../../dng_sdk/source /I../../../../xmp/toolkit/public/include /I"../../../../xmp/toolkit/third-party/zlib" /Zi /nologo /W3 /WX- /Od /Oy- /D qDNGValidate=0 /D qDNGDebug=1 /D _DEBUG /D _CONSOLE /D _CRT_SECURE_NO_DEPRECATE /D WIN32 /D qWinOS=1 /D qMacOS=0 /D qVisualC=1 /D _WINDOWS=1 /D BIB_MULTI_THREAD=1 /D _VC80_UPGRADE=0x0710 /D _MBCS /Gm- /EHsc /RTC1 /MTd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"WIN32_DEBUG\OBJ\\" /Fd"WIN32_DEBUG\OBJ\VC120.PDB" /Gd /TP /analyze- E:\DNG_SDK_1_4\DNG_SDK\SOURCE\DNG_GLOBALS.CPP
    /c /I../../../../dng_sdk/source /I../../../../xmp/toolkit/public/include /I"../../../../xmp/toolkit/third-party/zlib" /Zi /nologo /W3 /WX- /Od /Oy- /D qDNGValidate=0 /D qDNGDebug=1 /D _DEBUG /D _CONSOLE /D _CRT_SECURE_NO_DEPRECATE /D WIN32 /D qWinOS=1 /D qMacOS=0 /D qVisualC=1 /D _WINDOWS=1 /D BIB_MULTI_THREAD=1 /D _VC80_UPGRADE=0x0710 /D _MBCS /Gm- /EHsc /RTC1 /MTd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"WIN32_DEBUG\OBJ\\" /Fd"WIN32_DEBUG\OBJ\VC120.PDB" /Gd /TP /analyze- E:\DNG_SDK_1_4\DNG_SDK\SOURCE\DNG_HOST.CPP

    • Edited by Madumi Monday, December 04, 2017 11:55 PM
    Monday, December 04, 2017 11:50 PM
  • Probably i am overlooking something ...

    So just to be sure, we are talking about the same thing:
    Are you using from the official download site of adobe, like I do?
    For neither object-output-path of build,

    nor compiler-switches in log-file matches the ones I get, when this Configuration is Active:

    Which should do a build with
     'Project Configuration' for dng_sdk library: 'DNG Validate Target Debug'
     'Project Configuration' for dng_validate application:'DNG Validate Debug'

    Understanding Build Configurations

    According to my experience with this solution, Visual Studio - in your case - is building 'Debug' Configuration of dng_sdk library, which compiles with 

    /D qDNGValidate=0
    /D (Preprocessor Definitions)

    leading to unresolved external symbols, when building dng_validate application subsequently.  

    So before Rebuild, please double check, that 'Solutions Configurations' in toolbar points to

    Else you have to change it!

    Probably you may want to resize respective text-field :

    With kind regards
    Tuesday, December 05, 2017 10:31 AM
  • @MaybeCompletelyW

    Yes, I'm using from the official Adobe download site...

    It's a bit embarrassing simply that I seem to have been using the wrong build configuration... I'm definitely only at the start of the learning curve with VS...

    If you don't mind me double-checking that I'm on the right path, when I build using the "DNG Validate Target Debug" solution configuration, the two builds succeed, but there are a bunch of warnings. the first one for dng_validate is

    TargetPath(E:\dng_sdk_1_4\dng_sdk\projects\win\dng_validate\Validate Debug\Win32\dng_validate.exe) does not match the Linker's OutputFile property value (E:\dng_sdk_1_4\dng_sdk\targets\win\debug32\dng_validate.exe)

    and then there are 23 LNK4204 warnings for XMPCoreStaticDebug.lib (missing debugging information for referencing module)

    followed by 100 LNK4204 warning for XMPFilesStaticDebug.lib (missing debugging information for referencing module)


    I'm assuming that the 123 LNK4204 warnings are fixable if I rebuilt XMP (?), but I don't know whether the first warning about the target path is a problem.

    Am I good to go (my next step will be actually to learn Visual Studio... :-) )

    Thanks so much for your help so far, it's much appreciated!

    Thursday, December 07, 2017 8:40 PM
  • ...

    It's a bit embarrassing simply that I seem to have been using the wrong build configuration... 


    Well, I would not quite expect issues for an existing configuration (combination). It's a little bit peculiar ...
    In respect to linker warnings:
    No linker warnings as for xmp libraries here, but remember I (had to) rebuilt these libraries with new toolset, so having symbols (up-to-date) available. Besides, xmp in ships without source, which may lead in any case to a somewhat unpleasant 'debugging' experience, when trying to step into the xmp-part ...
    For 'TargetPath', think, you should get along with

    in project 'dng_validate' project-properties 'Linker->General' 'Output File'.
    Having a (hopefully) runnable application, debugging may yield first impressions about sdk-usage. 

    With kind regards

    Friday, December 08, 2017 10:54 AM