none
Windows Server 2019 - issue with elfapi.lib while building

    Question

  • When using Windows SDK 1809 elfapi.lib 
    we are getting below external symbol errors in windows server 2019 while building

    Unresolved external symbol ElfrReportEventA

    But in server 2016, there is no issues , it is building successfully.

    Is ElfReportEventA API function deprecated? or any signature of the function got changed? if yes, what is the alternative api for these two.

    but when I am using "dumpbin.exe /linkermember elfapi.lib", I can see the symbol ElfReportEventA in the result there along with other 159 symbols, Any change made particularly for the new Windows SDK 1809?

    Monday, February 11, 2019 10:06 AM

All replies

  • If possible, show the definition of ElfrReportEventA (select it and press <F12>).

    Monday, February 11, 2019 11:33 AM
  • This is the link for ElfrReportEventA, which will be located in elfapi.lib of Windows SDKs

    https://msdn.microsoft.com/en-us/library/cc231430.aspx

    but in my case i am looking for ElfReportEventA, the definition of which I cannot find in msdn forums, Even I used ElfrReportEventA in my code, but still throwing the unresolved external symbol error.

    the latest elfapi.lib library is present in Windows SDK 1809 which is compatible with Windows Server 2019 in this location

    C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17763.0\um\x86\elfapi.lib

    Monday, February 11, 2019 12:22 PM
  • but in my case i am looking for ElfReportEventA, the definition of which I cannot find in msdn forums

    This is called using an undocumented function. The only hit that I got on this name also states that this is an undocumented function. This means that there is no support for this function, you are discouraged from using this function and if anything goes wrong while using this function then it is up to you to deal with it.

    I am in the process of trying out the Elfr functions, but so far, initial tests are showing that I am able to link against these functions, and the same definitions will work using the 1803 and 1809 SDK.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Edited by Darran Rowe Monday, February 11, 2019 3:00 PM
    Monday, February 11, 2019 2:08 PM
  • As a follow up, the sample that I was building was:

    #include "defs.h"
    
    #pragma comment(lib, "elfapi.lib")
    #pragma comment(lib, "rpcutil.lib")
    #pragma comment(lib, "rpcrt4.lib")
    #pragma comment(lib, "ntdll.lib")
    
    int wmain()
    {
    	ElfrReportEventA(nullptr, 0, 0, 0, 0, 0, 0, nullptr, nullptr, nullptr, nullptr, 0, nullptr, nullptr);
    
    	return 0;
    }

    and sure this won't run successfully, but I was getting the build output of:

    1>------ Rebuild All started: Project: meh, Configuration: Debug Win32 ------
    1>main.cpp
    1>c:\users\archa\source\repos\meh\meh\defs.h(34): warning C4200: nonstandard extension used: zero-sized array in struct/union
    1>c:\users\archa\source\repos\meh\meh\defs.h(34): note: This member will be ignored by a defaulted constructor or copy/move assignment operator
    1>c:\users\archa\source\repos\meh\meh\defs.h(45): warning C4200: nonstandard extension used: zero-sized array in struct/union
    1>c:\users\archa\source\repos\meh\meh\defs.h(45): note: This member will be ignored by a defaulted constructor or copy/move assignment operator
    1>meh.vcxproj -> C:\Users\archa\source\repos\meh\Debug\meh.exe
    1>Done building project "meh.vcxproj".
    ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

    where the warnings are from the IELF_HANDLE structure and the RPC_SID structure. This was built using the 10.0.17763 SDK and I also tested this using the 10.0.17134 SDK. I did try a few tests to make the build fail, but if it failed in 17763, it would also fail in 17134.

    So to put it simply, if it builds using the 1803 SDK then it will build with the 1809 SDK too. That was my experience though.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Monday, February 11, 2019 2:59 PM
  • Oh, should also mention it too, there is something that I asked in the other thread that asked about this exact library and function. Did you install the 1809 Windows SDK onto the system which was successfully building and retarget the project that was using the 1803 Windows SDK to use the 1809 version?

    You are not limited to just one version of the Windows SDK on a system. Also building an application targeting a newer version of Windows from an older version doesn't make the application suddenly not work on the newer version of Windows. This is fully supported inside Visual Studio. I see people target Windows 10 desktop applications using Visual Studio 2017 and the Windows 10 SDK installed on Windows 7.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.


    • Edited by Darran Rowe Monday, February 11, 2019 11:15 PM
    Monday, February 11, 2019 11:14 PM