blocks|key|1342757|text|我设法解决了这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1342758|错误的来源是这一行代码，可以在SDLmain源代码中找到。|1342759|fprintf(stderr,+"%25s:+%25s\n",+title,+message);|code-block|syntax|javascript|1342760|因此，我所做的也是编辑该行的SDLmain源代码：|1342761|fprintf("%25s:+%25s\n",+title,+message);|1342762|然后，我构建了SDLmain，并用新构建和编辑的SDLmain.lib复制并替换了SDL2库目录中的旧SDLmain.lib。|1342763|然后，当我使用SDL2运行我的程序时，没有出现错误消息，代码运行也很顺利。|1342764|我不知道这以后会不会咬我，但是一切都很顺利。|1342765|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

I managed to fix the problem. 

The source of the error was this line of code, that can be found in the SDLmain source code.

<pre><code>fprintf(stderr, "%s: %s\n", title, message);
</code></pre>

So what I did was to edit the source code in SDLmain of that line too:

<pre><code>fprintf("%s: %s\n", title, message);
</code></pre>

And then I built the SDLmain and copied and replaced the old SDLmain.lib in my SDL2 library directory with the newly built and edited. 

Then when I ran my program with SDL2 no error messages came up and to code ran smoothly.

I don't know if this will bite me later, but so for everything is going great.

blocks|key|1343191|text|我终于弄明白了为什么会发生这种事！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1343192|在visual+studio+2015中，stdin、stderr、stdout的定义如下：|1343193|#define+stdin++(__acrt_iob_func(0))
#define+stdout+(__acrt_iob_func(1))
#define+stderr+(__acrt_iob_func(2))|code-block|syntax|javascript|1343194|但在此之前，它们被定义为：|1343195|#define+stdin++(&__iob_func()[0])
#define+stdout+(&__iob_func()[1])
#define+stderr+(&__iob_func()[2])|1343196|因此，现在不再定义__iob_func了，这将导致在使用使用以前版本的visual编译的.lib文件时出现链接错误。|1343197|为了解决这个问题，您可以自己定义__iob_func()，它应该返回一个包含{*stdin,*stdout,*stderr}的数组。|offset|length|style|CODE|1343198|关于stdio函数的其他链接错误(在我的例子中是sprintf())，您可以将legacy_stdio_definitions.lib添加到链接器选项中。|1343199|entityMap^0|0|0|0|0|0|0|G|C|12|O|0|O|9|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|12|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@$Q|15|R|16|S|T]|$Q|17|R|18|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|19|8|@$Q|1A|R|1B|S|T]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|X|$]]

I have finally figured out why this is happening !

In visual studio 2015, stdin, stderr, stdout are defined as follow :

<pre><code>#define stdin (__acrt_iob_func(0))
#define stdout (__acrt_iob_func(1))
#define stderr (__acrt_iob_func(2))
</code></pre>

But previously, they were defined as:

<pre><code>#define stdin (&amp;__iob_func()[0])
#define stdout (&amp;__iob_func()[1])
#define stderr (&amp;__iob_func()[2])
</code></pre>

So now __iob_func is not defined anymore which leads to a link error when using a .lib file compiled with previous versions of visual studio.

To solve the issue, you can try defining <code>__iob_func()</code> yourself which should return an array containing <code>{*stdin,*stdout,*stderr}</code>.

Regarding the other link errors about stdio functions (in my case it was <code>sprintf()</code>), you can add legacy_stdio_definitions.lib to your linker options.

blocks|key|722057|text|我在VS2015中也有同样的问题。我通过在SDL2中编译VS2015源代码来解决这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|722058|转到http://libsdl.org/download-2.0.php并下载SDL+2源代码。|ordered-list-item|offset|length|722059|打开SDL_VS2013.sln+in+VS2015。你将被要求转换项目。去做吧。|style|BOLD|722060|编译SDL2项目。|722061|编译SDL2main项目。|722062|在SDL2main.lib的SDL+2项目中使用新生成的输出文件VS2015、SDL2.lib和SDL2.dll。|722063|entityMap|0|LINK|mutability|MUTABLE|url|http://libsdl.org/download-2.0.php^0|0|2|Y|0|0|K|6|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@$E|10|F|11|1|12]]|A|$]]|$1|G|3|H|5|D|7|13|8|@$E|14|F|15|I|J]]|9|@]|A|$]]|$1|K|3|L|5|D|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|18|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

I had the same issue in VS2015. I have solved it by compiling the SDL2 sources in VS2015.

<ol>
<li>Go to <a href="http://libsdl.org/download-2.0.php" rel="noreferrer">http://libsdl.org/download-2.0.php</a> and download SDL 2 source code.</li>
<li>Open SDL_VS2013.sln in VS2015. You will be asked to convert the projects. Do it.</li>
<li>Compile SDL2 project.</li>
<li>Compile SDL2main project.</li>
<li>Use the new generated output files SDL2main.lib, SDL2.lib and SDL2.dll in your SDL 2 project in VS2015.</li>
</ol>

blocks|key|722089|text|这个问题的最新解决方案:使用最新的sdl库|type|unstyled|depth|inlineStyleRanges|entityRanges|data|722090|"https://buildbot.libsdl.org/sdl-builds/sdl-visualstudio/?C=M;O=D“|offset|length|722091|他们似乎已经解决了这个问题，尽管它只是32位的库(我想)。|722092|entityMap|0|LINK|mutability|MUTABLE|url|https://buildbot.libsdl.org/sdl-builds/sdl-visualstudio/?C=M;O=D^0|0|1|1S|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

A more recent solution to this problem: Use the more recent sdl libs on

"<a href="https://buildbot.libsdl.org/sdl-builds/sdl-visualstudio/?C=M;O=D">https://buildbot.libsdl.org/sdl-builds/sdl-visualstudio/?C=M;O=D</a>"

They seem to have fixed the problem, although it's only the 32 bit library (I think).

blocks|key|722106|text|对国际海事组织的米兰巴布š科夫来说，这正是替换函数应该看起来的样子:-)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|722107|FILE+_iob[]+=+{*stdin,+*stdout,+*stderr};

extern+"C"+FILE+*+__cdecl+__iob_func(void)
{
++++return+_iob;
}|code-block|syntax|javascript|722108|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

To Milan Babuškov, IMO, this is exactly what the replacement function should look like :-)

<pre><code>FILE _iob[] = {*stdin, *stdout, *stderr};

extern "C" FILE * __cdecl __iob_func(void)
{
 return _iob;
}
</code></pre>

blocks|key|1343272|text|当您链接到msvcrt.dll而不是msvcr10.dll+(或类似的)时可能会发生这种情况，这是一个很好的计划。因为它将释放您在最终软件包中重新分发Visual的运行时库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1343273|这个解决方案帮助我(在Visual+2008中)：|1343274|#if+_MSC_VER+>=+1400
#undef+stdin
#undef+stdout
#undef+stderr
extern+"C"+_CRTIMP+extern+FILE+_iob[];
#define+stdin+++_iob
#define+stdout++(_iob%2B1)
#define+stderr++(_iob%2B2)
#endif|code-block|syntax|javascript|1343275|Visual+6及其编译器不需要此片段。因此#ifdef.|1343276|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

This can happen when you link to msvcrt.dll instead of msvcr10.dll (or similar), which is a good plan. Because it will free you up to redistribute your Visual Studio's runtime library inside your final software package.

That workaround helps me (at Visual Studio 2008):

<pre><code>#if _MSC_VER &gt;= 1400
#undef stdin
#undef stdout
#undef stderr
extern "C" _CRTIMP extern FILE _iob[];
#define stdin _iob
#define stdout (_iob+1)
#define stderr (_iob+2)
#endif
</code></pre>

This snippet is not needed for Visual Studio 6 and its compiler. Therefore the #ifdef.

blocks|key|722153|text|将预编译的SDL2main.lib和SDL.lib用于VS2015项目的库：https://buildbot.libsdl.org/sdl-builds/sdl-visualstudio/sdl-visualstudio-2225.zip|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|722154|entityMap|0|LINK|mutability|MUTABLE|url|https://buildbot.libsdl.org/sdl-builds/sdl-visualstudio/sdl-visualstudio-2225.zip^0|12|29|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Use the pre-compiled SDL2main.lib and SDL.lib for your VS2015 project's library :
<a href="https://buildbot.libsdl.org/sdl-builds/sdl-visualstudio/sdl-visualstudio-2225.zip" rel="nofollow">https://buildbot.libsdl.org/sdl-builds/sdl-visualstudio/sdl-visualstudio-2225.zip</a>

blocks|key|722167|text|如前所述，正确的答案是使用VS2015编译所有内容，但为了感兴趣，下面是我对问题的分析。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|722168|这个符号似乎并没有在微软作为VS2015的一部分提供的任何静态库中定义，这是相当奇怪的，因为所有其他的都是。要了解原因，我们需要查看该函数的声明，更重要的是，它是如何使用的。|722169|下面是来自Visual+2008头的一个片段：|722170|_CRTIMP+FILE+*+__cdecl+__iob_func(void);
#define+stdin+(&__iob_func()[0])
#define+stdout+(&__iob_func()[1])
#define+stderr+(&__iob_func()[2])|code-block|syntax|javascript|722171|因此我们可以看到，函数的任务是返回文件对象数组的开始(不是句柄，"FILE+*“是句柄，文件是存储重要状态信息的底层不透明数据结构)。这个函数的用户是三个宏stdin、stdout和stderr，它们都用于各种fscanf、fprintf样式的调用。|722172|现在让我们看看Visual+2015是如何定义相同的东西的：|722173|_ACRTIMP_ALT+FILE*+__cdecl+__acrt_iob_func(unsigned);
#define+stdin+(__acrt_iob_func(0))
#define+stdout+(__acrt_iob_func(1))
#define+stderr+(__acrt_iob_func(2))|722174|因此，替换函数的方法已经更改为现在返回文件句柄，而不是文件对象数组的地址，并且宏已经更改为只调用传递标识号的函数。|722175|那么为什么他们/我们不能提供一个兼容的API呢？在微软最初通过__iob_func实现时，有两条关键规则是微软不能违背的：|722176|必须有一个由三个文件结构组成的数组，它们可以像以前一样以相同的方式进行索引。|ordered-list-item|722177|文件的结构布局不能更改。|722178|如果调用该API，上述任一项中的任何更改都将意味着现有的编译代码链接到该代码上将发生严重错误。|722179|让我们看看文件是如何定义的。|722180|首先，VS2008文件定义：|722181|struct+_iobuf+{
++++++++char+*_ptr;
++++++++int+++_cnt;
++++++++char+*_base;
++++++++int+++_flag;
++++++++int+++_file;
++++++++int+++_charbuf;
++++++++int+++_bufsiz;
++++++++char+*_tmpfname;
++++++++};
typedef+struct+_iobuf+FILE;|722182|现在是VS2015文件定义：|722183|typedef+struct+_iobuf
{
++++void*+_Placeholder;
}+FILE;|722184|因此，问题的症结在于:结构已经改变了。引用__iob_func的现有编译代码依赖于这样一个事实，即返回的数据既是可以索引的数组，也是该数组中的元素之间的距离相同的数组。|722185|以上答复中提到的可能的解决办法(如果要求的话)将因以下几个原因而无效：|722186|FILE+_iob[]+=+{*stdin,+*stdout,+*stderr};

extern+"C"+FILE+*+__cdecl+__iob_func(void)
{
++++return+_iob;
}|722187|文件数组_iob将使用VS2015编译，因此它将被布局为包含一个void*的结构块。假设32位对齐，这些元素将相隔4个字节.因此，_iob位于偏移量0，_iob1位于偏移量4，_iob2位于偏移量8。相反，调用代码将期望文件长得多，在我的系统上对齐为32字节，因此它将接受返回数组的地址，并添加0字节以获得零元素(其中一个是可以的)，但对于_iob1，它将推断它需要添加32个字节，而对于_iob2，它将推断需要添加64个字节(因为在VS2008头中是这样的)。实际上，VS2008的反汇编代码演示了这一点。|722188|上述解决方案的另一个问题是，它复制文件结构(*stdin)的内容，而不是文件*句柄。因此，任何VS2008代码都将查看与VS2015不同的底层结构。如果结构只包含指针，这可能有效，但这是一个很大的风险。无论如何，第一个问题使这一点变得无关紧要。|722189|我所能想到的唯一问题是，__iob_func遍历调用堆栈，找出他们正在寻找的实际文件句柄(基于添加到返回地址的偏移量)，并返回一个计算值，以便给出正确的答案。这听起来有点疯狂，但是下面列出的只是x86的原型(不是x64)，以供您娱乐。它可以在我的实验中工作，但你的里程可能会有所不同-不推荐生产使用！|722190|#include+<windows.h>
#include+<stdio.h>
#include+<dbghelp.h>

/*+#define+LOG+*/

#if+defined(_M_IX86)

#define+GET_CURRENT_CONTEXT(c,+contextFlags)+\
++do+{+\
++++c.ContextFlags+=+contextFlags;+\
++++__asm++++call+x+\
++++__asm+x:+pop+eax+\
++++__asm++++mov+c.Eip,+eax+\
++++__asm++++mov+c.Ebp,+ebp+\
++++__asm++++mov+c.Esp,+esp+\
++}+while(0);

#else

/*+This+should+work+for+64-bit+apps,+but+doesn't+*/
#define+GET_CURRENT_CONTEXT(c,+contextFlags)+\
++do+{+\
++++c.ContextFlags+=+contextFlags;+\
++++RtlCaptureContext(&c);+\
}+while(0);

#endif

FILE+*+__cdecl+__iob_func(void)
{
++++CONTEXT+c+=+{+0+};
++++STACKFRAME64+s+=+{+0+};
++++DWORD+imageType;
++++HANDLE+hThread+=+GetCurrentThread();
++++HANDLE+hProcess+=+GetCurrentProcess();

++++GET_CURRENT_CONTEXT(c,+CONTEXT_FULL);

#ifdef+_M_IX86
++++imageType+=+IMAGE_FILE_MACHINE_I386;
++++s.AddrPC.Offset+=+c.Eip;
++++s.AddrPC.Mode+=+AddrModeFlat;
++++s.AddrFrame.Offset+=+c.Ebp;
++++s.AddrFrame.Mode+=+AddrModeFlat;
++++s.AddrStack.Offset+=+c.Esp;
++++s.AddrStack.Mode+=+AddrModeFlat;
#elif+_M_X64
++++imageType+=+IMAGE_FILE_MACHINE_AMD64;
++++s.AddrPC.Offset+=+c.Rip;
++++s.AddrPC.Mode+=+AddrModeFlat;
++++s.AddrFrame.Offset+=+c.Rsp;
++++s.AddrFrame.Mode+=+AddrModeFlat;
++++s.AddrStack.Offset+=+c.Rsp;
++++s.AddrStack.Mode+=+AddrModeFlat;
#elif+_M_IA64
++++imageType+=+IMAGE_FILE_MACHINE_IA64;
++++s.AddrPC.Offset+=+c.StIIP;
++++s.AddrPC.Mode+=+AddrModeFlat;
++++s.AddrFrame.Offset+=+c.IntSp;
++++s.AddrFrame.Mode+=+AddrModeFlat;
++++s.AddrBStore.Offset+=+c.RsBSP;
++++s.AddrBStore.Mode+=+AddrModeFlat;
++++s.AddrStack.Offset+=+c.IntSp;
++++s.AddrStack.Mode+=+AddrModeFlat;
#else
#error+"Platform+not+supported!"
#endif

++++if+(!StackWalk64(imageType,+hProcess,+hThread,+&s,+&c,+NULL,+SymFunctionTableAccess64,+SymGetModuleBase64,+NULL))
++++{
#ifdef+LOG
++++++++printf("Error:+0x%2508X+(Address:+%25p)\n",+GetLastError(),+(LPVOID)s.AddrPC.Offset);
#endif
++++++++return+NULL;
++++}

++++if+(s.AddrReturn.Offset+==+0)
++++{
++++++++return+NULL;
++++}

++++{
++++++++unsigned+char+const+*+assembly+=+(unsigned+char+const+*)(s.AddrReturn.Offset);
#ifdef+LOG
++++++++printf("Code+bytes+proceeding+call+to+__iob_func:+%25p:+%2502X,%2502X,%2502X\n",+assembly,+*assembly,+*(assembly+%2B+1),+*(assembly+%2B+2));
#endif
++++++++if+(*assembly+==+0x83+&&+*(assembly+%2B+1)+==+0xC0+&&+(*(assembly+%2B+2)+==+0x20+%7C%7C+*(assembly+%2B+2)+==+0x40))
++++++++{
++++++++++++if+(*(assembly+%2B+2)+==+32)
++++++++++++{
++++++++++++++++return+(FILE*)((unsigned+char+*)stdout+-+32);
++++++++++++}
++++++++++++if+(*(assembly+%2B+2)+==+64)
++++++++++++{
++++++++++++++++return+(FILE*)((unsigned+char+*)stderr+-+64);
++++++++++++}

++++++++}
++++++++else
++++++++{
++++++++++++return+stdin;
++++++++}
++++}
++++return+NULL;
}|722191|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1T|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1U|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1V|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1W|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|1X|8|@]|9|@]|A|$I|J]]|$1|Q|3|R|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|U|3|V|5|W|7|20|8|@]|9|@]|A|$]]|$1|X|3|Y|5|W|7|21|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|22|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|23|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|24|8|@]|9|@]|A|$]]|$1|15|3|16|5|H|7|25|8|@]|9|@]|A|$I|J]]|$1|17|3|18|5|6|7|26|8|@]|9|@]|A|$]]|$1|19|3|1A|5|H|7|27|8|@]|9|@]|A|$I|J]]|$1|1B|3|1C|5|6|7|28|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|29|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|H|7|2A|8|@]|9|@]|A|$I|J]]|$1|1H|3|1I|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|2C|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|2D|8|@]|9|@]|A|$]]|$1|1N|3|1O|5|H|7|2E|8|@]|9|@]|A|$I|J]]|$1|1P|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]]|1Q|$]]

As answered above, the right answer is to compile everything with VS2015, but for interest the following is my analysis of the problem.

This symbol does not appear to be defined in any static library provided by Microsoft as part of VS2015, which is rather peculiar since all others are. To discover why, we need to look at the declaration of that function and, more importantly, how it's used.

Here's a snippet from the Visual Studio 2008 headers:

<pre><code>_CRTIMP FILE * __cdecl __iob_func(void);
#define stdin (&amp;__iob_func()[0])
#define stdout (&amp;__iob_func()[1])
#define stderr (&amp;__iob_func()[2])
</code></pre>

So we can see that the job of the function is to return the start of an array of FILE objects (not handles, the "FILE *" is the handle, FILE is the underlying opaque data structure storing the important state goodies). The users of this function are the three macros stdin, stdout and stderr which are used for various fscanf, fprintf style calls.

Now let's take a look at how Visual Studio 2015 defines the same things:

<pre><code>_ACRTIMP_ALT FILE* __cdecl __acrt_iob_func(unsigned);
#define stdin (__acrt_iob_func(0))
#define stdout (__acrt_iob_func(1))
#define stderr (__acrt_iob_func(2))
</code></pre>

So the approach has changed for the replacement function to now return the file handle rather than the address of the array of file objects, and the macros have changed to simply call the function passing in an identifying number.

So why can't they/we provide a compatible API?
There are two key rules which Microsoft can't contravene in terms of their original implementation via __iob_func:

<ol>
<li>There must be an array of three FILE structures which can be indexed in the same manner as before.</li>
<li>The structural layout of FILE cannot change.</li>
</ol>

Any change in either of the above would mean existing compiled code linked against that would go badly wrong if that API is called.

Let's take a look at how FILE was/is defined.

First the VS2008 FILE definition:

<pre><code>struct _iobuf {
 char *_ptr;
 int _cnt;
 char *_base;
 int _flag;
 int _file;
 int _charbuf;
 int _bufsiz;
 char *_tmpfname;
 };
typedef struct _iobuf FILE;
</code></pre>

And now the VS2015 FILE definition:

<pre><code>typedef struct _iobuf
{
 void* _Placeholder;
} FILE;
</code></pre>

So there is the crux of it: the structure has changed shape. Existing compiled code referring to __iob_func relies upon the fact that the data returned is both an array that can be indexed and that in that array the elements are the same distance apart.

The possible solutions mentioned in the answers above along these lines would not work (if called) for a few reasons:

<pre><code>FILE _iob[] = {*stdin, *stdout, *stderr};

extern "C" FILE * __cdecl __iob_func(void)
{
 return _iob;
}
</code></pre>

The FILE array _iob would be compiled with VS2015 and so it would be laid out as a block of structures containing a void*. Assuming 32-bit alignment, these elements would be 4 bytes apart. So _iob[0] is at offset 0, _iob[1] is at offset 4 and _iob[2] is at offset 8. The calling code will instead expect FILE to be much longer, aligned at 32 bytes on my system, and so it will take the address of the returned array and add 0 bytes to get to element zero (that one is okay), but for _iob[1] it will deduce that it needs to add 32 bytes and for _iob[2] it will deduce that it needs to add 64-bytes (because that's how it looked in the VS2008 headers). And indeed the disassembled code for VS2008 demonstrates this.

A secondary issue with the above solution is that it copies the content of the FILE structure (*stdin), not the FILE * handle. So any VS2008 code would be looking at a different underlying structure to VS2015. This might work if the structure only contained pointers, but that's a big risk. In any case the first issue renders this irrelevant.

The only hack I've been able to dream up is one in which __iob_func walks the call stack to work out which actual file handle they are looking for (based on the offset added to the returned address) and returns a computed value such that it gives the right answer. This is every bit as insane as it sounds, but the prototype for x86 only (not x64) is listed below for your amusement. It worked okay in my experiments, but your mileage may vary - not recommended for production use!

<pre><code>#include &lt;windows.h&gt;
#include &lt;stdio.h&gt;
#include &lt;dbghelp.h&gt;

/* #define LOG */

#if defined(_M_IX86)

#define GET_CURRENT_CONTEXT(c, contextFlags) \
 do { \
 c.ContextFlags = contextFlags; \
 __asm call x \
 __asm x: pop eax \
 __asm mov c.Eip, eax \
 __asm mov c.Ebp, ebp \
 __asm mov c.Esp, esp \
 } while(0);

#else

/* This should work for 64-bit apps, but doesn't */
#define GET_CURRENT_CONTEXT(c, contextFlags) \
 do { \
 c.ContextFlags = contextFlags; \
 RtlCaptureContext(&amp;c); \
} while(0);

#endif

FILE * __cdecl __iob_func(void)
{
 CONTEXT c = { 0 };
 STACKFRAME64 s = { 0 };
 DWORD imageType;
 HANDLE hThread = GetCurrentThread();
 HANDLE hProcess = GetCurrentProcess();

 GET_CURRENT_CONTEXT(c, CONTEXT_FULL);

#ifdef _M_IX86
 imageType = IMAGE_FILE_MACHINE_I386;
 s.AddrPC.Offset = c.Eip;
 s.AddrPC.Mode = AddrModeFlat;
 s.AddrFrame.Offset = c.Ebp;
 s.AddrFrame.Mode = AddrModeFlat;
 s.AddrStack.Offset = c.Esp;
 s.AddrStack.Mode = AddrModeFlat;
#elif _M_X64
 imageType = IMAGE_FILE_MACHINE_AMD64;
 s.AddrPC.Offset = c.Rip;
 s.AddrPC.Mode = AddrModeFlat;
 s.AddrFrame.Offset = c.Rsp;
 s.AddrFrame.Mode = AddrModeFlat;
 s.AddrStack.Offset = c.Rsp;
 s.AddrStack.Mode = AddrModeFlat;
#elif _M_IA64
 imageType = IMAGE_FILE_MACHINE_IA64;
 s.AddrPC.Offset = c.StIIP;
 s.AddrPC.Mode = AddrModeFlat;
 s.AddrFrame.Offset = c.IntSp;
 s.AddrFrame.Mode = AddrModeFlat;
 s.AddrBStore.Offset = c.RsBSP;
 s.AddrBStore.Mode = AddrModeFlat;
 s.AddrStack.Offset = c.IntSp;
 s.AddrStack.Mode = AddrModeFlat;
#else
#error "Platform not supported!"
#endif

 if (!StackWalk64(imageType, hProcess, hThread, &amp;s, &amp;c, NULL, SymFunctionTableAccess64, SymGetModuleBase64, NULL))
 {
#ifdef LOG
 printf("Error: 0x%08X (Address: %p)\n", GetLastError(), (LPVOID)s.AddrPC.Offset);
#endif
 return NULL;
 }

 if (s.AddrReturn.Offset == 0)
 {
 return NULL;
 }

 {
 unsigned char const * assembly = (unsigned char const *)(s.AddrReturn.Offset);
#ifdef LOG
 printf("Code bytes proceeding call to __iob_func: %p: %02X,%02X,%02X\n", assembly, *assembly, *(assembly + 1), *(assembly + 2));
#endif
 if (*assembly == 0x83 &amp;&amp; *(assembly + 1) == 0xC0 &amp;&amp; (*(assembly + 2) == 0x20 || *(assembly + 2) == 0x40))
 {
 if (*(assembly + 2) == 32)
 {
 return (FILE*)((unsigned char *)stdout - 32);
 }
 if (*(assembly + 2) == 64)
 {
 return (FILE*)((unsigned char *)stderr - 64);
 }

 }
 else
 {
 return stdin;
 }
 }
 return NULL;
}
</code></pre>

blocks|key|722219|text|链接意味着不能正常工作。深入研究VS2012和VS2015的stdio.h，以下内容对我很有帮助。唉，你必须决定它是否应该适用于{+stdin，stdout，stderr+}中的一个，而不是超过一个。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|722220|extern+"C"+FILE*+__cdecl+__iob_func()
{
++++struct+_iobuf_VS2012+{+//+...\Microsoft+Visual+Studio+11.0\VC\include\stdio.h+#56
++++++++char+*_ptr;
++++++++int+++_cnt;
++++++++char+*_base;
++++++++int+++_flag;
++++++++int+++_file;
++++++++int+++_charbuf;
++++++++int+++_bufsiz;
++++++++char+*_tmpfname;+};
++++//+VS2015+has+only+FILE+=+struct+{void*}

++++int+const+count+=+sizeof(_iobuf_VS2012)+/+sizeof(FILE);

++++////+stdout
++++//return+(FILE*)(&(__acrt_iob_func(1)->_Placeholder)+-+count);

++++//+stderr
++++return+(FILE*)(&(__acrt_iob_func(2)->_Placeholder)+-+2+*+count);
}|code-block|syntax|javascript|722221|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

To link means not to work properly. Digging into stdio.h of VS2012 and VS2015 the following worked for me. Alas, you have to decide if it should work for one of { stdin, stdout, stderr }, never more than one.

<pre><code>extern "C" FILE* __cdecl __iob_func()
{
 struct _iobuf_VS2012 { // ...\Microsoft Visual Studio 11.0\VC\include\stdio.h #56
 char *_ptr;
 int _cnt;
 char *_base;
 int _flag;
 int _file;
 int _charbuf;
 int _bufsiz;
 char *_tmpfname; };
 // VS2015 has only FILE = struct {void*}

 int const count = sizeof(_iobuf_VS2012) / sizeof(FILE);

 //// stdout
 //return (FILE*)(&amp;(__acrt_iob_func(1)-&gt;_Placeholder) - count);

 // stderr
 return (FILE*)(&amp;(__acrt_iob_func(2)-&gt;_Placeholder) - 2 * count);
}
</code></pre>

blocks|key|1343380|text|微软在这方面有一个特别的说明(CRT)：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1343381|--+printf和scanf函数族现在是内联定义的.。
所有printf和scanf函数的定义已经内联地移动到stdio.h、conio.h和其他CRT标头中。这是一个突破性的变化，它会导致链接器错误(LNK2019，未解析的外部符号)在本地声明这些函数而不包括适当的CRT的程序。如果可能，您应该更新代码以包含CRT头(即添加#include+)和内联函数，但是如果您不想修改代码以包含这些头文件，另一种解决方案是向链接器输入legacy_stdio_definitions.lib.添加一个额外的库。
若要将此库添加到IDE中的链接器输入，请打开项目节点的上下文菜单，选择“属性”，然后在“项目属性”对话框中选择“链接器”，然后编辑链接器输入以将legacy_stdio_definitions.lib添加到分号分隔的列表中。
如果您的项目链接到使用早于2015年的VisualC%2B%2B版本编译的静态库，则链接器可能会报告未解决的外部符号。这些错误可能引用_iob、_iob_func的内部stdio定义，或以__imp_*的形式引用特定stdio函数的相关导入。Microsoft建议您在升级项目时使用最新版本的VisualC%2B%2B编译器和库重新编译所有静态库。如果库是一个源不可用的第三方库，则应从第三方请求更新的二进制文件，或者将该库的使用封装到一个单独的DLL中，然后使用较早版本的Visual编译器和库进行编译。|blockquote|style|BOLD|1343382|entityMap|0|LINK|mutability|MUTABLE|url|https://msdn.microsoft.com/en-us/library/bb531344.aspx#BK_CRT^0|F|3|0|0|0|R|1K|7|1S|7|5Z|S|BY|4|C3|9|CP|7|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@$A|V|B|W|G|H]|$A|X|B|Y|G|H]|$A|Z|B|10|G|H]|$A|11|B|12|G|H]|$A|13|B|14|G|H]|$A|15|B|16|G|H]|$A|17|B|18|G|H]]|9|@]|C|$]]|$1|I|3|-4|5|6|7|19|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

Microsoft has a special note on this (<a href="https://msdn.microsoft.com/en-us/library/bb531344.aspx#BK_CRT" rel="noreferrer">https://msdn.microsoft.com/en-us/library/bb531344.aspx#BK_CRT</a>):

<blockquote>
 The printf and scanf family of functions are now defined inline.
 
 The definitions of all of the printf and scanf functions have been
 moved inline into stdio.h, conio.h, and other CRT headers.
 This is a breaking change that leads to a linker error (LNK2019,
 unresolved external symbol) for any programs that declared these
 functions locally without including the appropriate CRT headers. If
 possible, you should update the code to include the CRT headers (that
 is, add #include ) and the inline functions, but if you do
 not want to modify your code to include these header files, an
 alternative solution is to add an additional library to your linker
 input, legacy_stdio_definitions.lib.
 
 To add this library to your linker input in the IDE, open the context
 menu for the project node, choose Properties, then in the Project
 Properties dialog box, choose Linker, and edit the Linker Input to add
 legacy_stdio_definitions.lib to the semi-colon-separated list.
 
 If your project links with static libraries that were compiled with a
 release of Visual C++ earlier than 2015, the linker might report an
 unresolved external symbol. These errors might reference internal
 stdio definitions for _iob, _iob_func, or related imports for
 certain stdio functions in the form of __imp_*. Microsoft
 recommends that you recompile all static libraries with the latest
 version of the Visual C++ compiler and libraries when you upgrade a
 project. If the library is a third-party library for which source is
 not available, you should either request an updated binary from the
 third party or encapsulate your usage of that library into a separate
 DLL that you compile with the older version of the Visual C++ compiler
 and libraries.
</blockquote>

blocks|key|777465|text|我不知道为什么但是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|777466|#ifdef+main
#undef+main
#endif|code-block|syntax|javascript|777467|在包含之后，但在你的主体之前，应该根据我的经验来修正它。|777468|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I don't know why but:

<pre><code>#ifdef main
#undef main
#endif
</code></pre>

After the includes but before your main should fix it from my experience.

blocks|key|777505|text|我的建议是不要(尝试)实现__iob_func。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|777506|在修复这些错误时：|777507|libpngd.v110.lib(pngrutil.obj)+:+error+LNK2001:+unresolved+external+symbol+___iob_func+curllib.v110.lib(mprintf.obj)+:+error+LNK2001:+unresolved+external+symbol+___iob_func|offset|length|style|CODE|777508|我尝试了其他答案的解决方案，但最后，返回一个FILE*+C-数组与一个由Windows内部IOB结构组成的数组不匹配。@Volker是对的，它只适用于stdin、stdout或stderr中的一个。|777509|如果一个库实际使用(其中一个流)，则将使崩溃。只要您的程序不导致库使用它们，您就永远不会知道。例如，当CRC在PNG的元数据中不匹配时，png_default_error会写入stderr。(通常情况下，这不是一个值得讨论的问题)|BOLD|777510|结论:如果使用stdin、stdout和/或stderr，VS2012+(Platform+Toolset+V+110/V+110_xp)和VS2015%2B库是不可能混合的。|777511|解决方案:用当前版本的VS和匹配的平台工具集重新编译具有__iob_func未解析符号的库。|777512|entityMap^0|0|0|0|4S|0|M|5|23|5|29|6|2G|6|0|0|9|I|2|12|8|1W|H|2G|6|0|0|S|A|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@$F|X|G|Y|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|Z|8|@$F|10|G|11|H|I]|$F|12|G|13|H|I]|$F|14|G|15|H|I]|$F|16|G|17|H|I]]|9|@]|A|$]]|$1|L|3|M|5|6|7|18|8|@$F|19|G|1A|H|N]|$F|1B|G|1C|H|N]|$F|1D|G|1E|H|N]|$F|1F|G|1G|H|I]|$F|1H|G|1I|H|I]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1J|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1K|8|@$F|1L|G|1M|H|I]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|T|$]]

My advice is to not (try to) implement __iob_func.

While fixing these errors:

<code>libpngd.v110.lib(pngrutil.obj) : error LNK2001: unresolved external symbol ___iob_func
curllib.v110.lib(mprintf.obj) : error LNK2001: unresolved external symbol ___iob_func</code>

I tried the other answers' solutions, but in the end, returning a <code>FILE*</code> C-array doesn't match up with an array of Windows' internal IOB structs. @Volker is right that it'll never work for more than one of <code>stdin</code>, <code>stdout</code> or <code>stderr</code>.

If a library actually USES one of those streams, it will crash. As long as your program doesn't cause the lib to use them, you'll never know. For example, <code>png_default_error</code> writes to <code>stderr</code> when the CRC doesn't match in the PNG's metadata. (Normally not a crash-worthy issue)

Conclusion: It's not possible to mix VS2012 (Platform Toolset v110/v110_xp) and VS2015+ libraries, if they use stdin, stdout and/or stderr.

Solution: Recompile your libraries that have <code>__iob_func</code> unresolved symbols with your current version of VS and a matching Platform Toolset.

blocks|key|1342928|text|为了在这个已经丰富的线程中带来更多的混乱，我碰巧在fprintf上遇到了同一个未解决的外部线程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1342929|main.obj+:+error+LNK2019:+unresolved+external+symbol+__imp__fprintf+referenced+in+function+_GenerateInfoFile|code-block|syntax|javascript|1342930|即使在我的例子中，情况完全不同:在Visual+2005+(VisualStudio8.0)下，错误发生在我自己的代码中(与我编译的代码完全相同)，而不是第三方。|1342931|发生此错误是由编译器标志中的/MD选项触发的。切换到/MT解决了这个问题。这很奇怪，因为通常，静态链接(MT)比动态链接(MD)带来的问题更多。不过，我把它放在那里，以防万一。|1342932|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

To bring more confusion in this already rich thread, I happened to bump in the same unresolved external on fprintf

<pre><code>main.obj : error LNK2019: unresolved external symbol __imp__fprintf referenced in function _GenerateInfoFile
</code></pre>

Even if in my case it was in a rather different context : under Visual Studio 2005 (Visual Studio 8.0) and the error was happening in my own code (the very same I was compiling), not a third party.

It happened that this error was triggered by /MD option in my compiler flags. Switching to /MT removed the issue. This is weird because usually, linking statically (MT) raises more problem than dynamically (MD)... but just in case it serves other, I put it there.

blocks|key|1342938|text|在我的示例中，此错误来自于我尝试移除与MSVC版本相关的运行时库DLL+(msvcr10.dll+)和/或删除静态运行时库，以从可执行文件中删除多余的脂肪。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1342939|因此，我使用/NODEFAULTLIB链接器开关，我自制的"msvcrt-light.lib“(在需要时使用谷歌)，以及mainCRTStartup()+/+WinMainCRTStartup()条目。|offset|length|style|CODE|1342940|它是自Visual+2015以来的IMHO，所以我坚持使用旧的编译器。|1342941|然而，定义符号_NO_CRT_STDIO_INLINE可以消除所有麻烦，一个简单的"Hello“应用程序也是3KB小的，并且不依赖于不寻常的all。在2017中测试。|BOLD|1342942|entityMap^0|0|1O|G|27|J|0|0|7|K|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@$D|Q|E|R|F|G]|$D|S|E|T|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|V|8|@$D|W|E|X|F|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|N|$]]

In my case, this error comes from my trial to remove dependencies to MSVC-version dependent runtime library DLL (msvcr10.dll or so) and/or remove static runtime library too, to remove excess fat from my executables.

So I use /NODEFAULTLIB linker switch, my self-made "msvcrt-light.lib" (google for it when you need), and <code>mainCRTStartup()</code> / <code>WinMainCRTStartup()</code> entries.

It is IMHO since Visual Studio 2015, so I stuck to older compilers.

However, defining symbol _NO_CRT_STDIO_INLINE removes all hassle, and a simple "Hello World" application is again 3 KB small and doesn't depend to unusual DLLs.
Tested in Visual Studio 2017.

blocks|key|1343461|text|我用以下功能来解决这个问题。我使用2019。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1343462|FILE*+__cdecl+__iob_func(void)
{
++++FILE+_iob[]+=+{+*stdin,+*stdout,+*stderr+};
++++return+_iob;
}|code-block|syntax|javascript|1343463|因为stdin宏定义了函数调用，所以"*stdin“表达式不能使用全局数组初始化器。但是本地数组初始化是可能的。对不起，我的英语很差。|1343464|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I resolve this problem with following function. I use Visual Studio 2019.

<pre><code>FILE* __cdecl __iob_func(void)
{
 FILE _iob[] = { *stdin, *stdout, *stderr };
 return _iob;
}
</code></pre>

because stdin Macro defined function call, "*stdin" expression is cannot used global array initializer. But local array initialier is possible.
sorry, I am poor at english.

blocks|key|777612|text|对于那些仍然在寻找上述技巧不起作用的答案的人来说。静态链接是解决这一问题的途径。更改运行时库设置如下|type|unstyled|depth|inlineStyleRanges|entityRanges|data|777613|Project+properties+-->+C/C%2B%2B+-->+Code+generation+-->+Runtime+Library+-->+Multi-threaded+Debug+(/MTd)+instead+of+/MDd|offset|length|style|CODE|777614|下面是对这个解决方案的讨论：https://social.msdn.microsoft.com/Forums/vstudio/en-US/4a1c9610-fa41-45f6-ad39-c9f6795be6f2/msvcrt-iob-disappeared?forum=vclanguage|777615|entityMap|0|LINK|mutability|MUTABLE|url|https://social.msdn.microsoft.com/Forums/vstudio/en-US/4a1c9610-fa41-45f6-ad39-c9f6795be6f2/msvcrt-iob-disappeared?forum=vclanguage^0|0|0|38|0|E|3N|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@$D|T|E|U|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@$D|W|E|X|1|Y]]|A|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

For anyone who is still looking for an answer where the above tricks didn't work. Static linking is the way to solve this problem. Change your Runtime library settings as below
<code>Project properties --&gt; C/C++ --&gt; Code generation --&gt; Runtime Library --&gt; Multi-threaded Debug (/MTd) instead of /MDd</code>
Here is a discussion on this solution: <a href="https://social.msdn.microsoft.com/Forums/vstudio/en-US/4a1c9610-fa41-45f6-ad39-c9f6795be6f2/msvcrt-iob-disappeared?forum=vclanguage" rel="nofollow noreferrer">https://social.msdn.microsoft.com/Forums/vstudio/en-US/4a1c9610-fa41-45f6-ad39-c9f6795be6f2/msvcrt-iob-disappeared?forum=vclanguage</a>

blocks|key|722472|text|将此代码粘贴到任何源文件中并重新构建。为我工作！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|722473|+#include+<stdio.h>

FILE+_iob[3];

FILE*+__cdecl+__iob_func(void)
{

+++_iob[0]+=+*stdin;

+++_iob[0]+=+*stdout;

+++_iob[0]+=+*stderr;

+++return+_iob;

}|code-block|syntax|javascript|722474|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Paste this code in any of your source files and re-build.
Worked for me !
<pre><code> #include &lt;stdio.h&gt;

FILE _iob[3];

FILE* __cdecl __iob_func(void)
{

 _iob[0] = *stdin;

 _iob[0] = *stdout;

 _iob[0] = *stderr;

 return _iob;

}
</code></pre>

blocks|key|1343487|text|也许这个能帮到你。我将Shell32.lib添加到我的链接器-->+Input+-->附加依赖项中，它停止了这个错误。我是从这篇文章中发现的：https://discourse.libsdl.org/t/windows-build-fails-with-missing-symbol-imp-commandlinetoargvw/27256/3|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1343488|entityMap|0|LINK|mutability|MUTABLE|url|https://discourse.libsdl.org/t/windows-build-fails-with-missing-symbol-imp-commandlinetoargvw/27256/3^0|1Z|2T|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Maybe this might help you. I added Shell32.lib to my Linker --&gt; Input --&gt; Additional Dependencies and it stopped this error. I found out about it from this post: <a href="https://discourse.libsdl.org/t/windows-build-fails-with-missing-symbol-imp-commandlinetoargvw/27256/3" rel="nofollow noreferrer">https://discourse.libsdl.org/t/windows-build-fails-with-missing-symbol-imp-commandlinetoargvw/27256/3</a>

blocks|key|722499|text|在尝试将__impl_printf链接到.lib项目时，我也遇到了同样的问题(未解决的外部符号vs2015+)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|722500|唯一适用于我的解决方案是项目->属性->链接器->附加选项框中的命令行添加:+legacy_stdio_definitions.lib|722501|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I got same problem (unresolved external symbol __impl_printf)when trying to link .lib to my vs2015 project
the only solution worked for me was
project-&gt;properties-&gt;linker-&gt;Command Line in additional options box add:
legacy_stdio_definitions.lib

Could someone explain what the 

<blockquote>
 __imp__fprintf
</blockquote>

and

<blockquote>
 __imp____iob_func
</blockquote>

unresolved external means?

Because I get these errors when I'm trying to compile:

<pre><code>1&gt;SDL2main.lib(SDL_windows_main.obj) : error LNK2019: unresolved external symbol __imp__fprintf referenced in function _ShowError
1&gt;SDL2main.lib(SDL_windows_main.obj) : error LNK2019: unresolved external symbol __imp____iob_func referenced in function _ShowError
1&gt;E:\Documents\Visual Studio 2015\Projects\SDL2_Test\Debug\SDL2_Test.exe : fatal error LNK1120: 2 unresolved externals
</code></pre>

I can already say that the problem is not from linking wrong. I have linked everything up correctly, but for some reason it won't compile.

I'm trying to use SDL2.

I'm using Visual Studio 2015 as compiler.

I have linked to SDL2.lib and SDL2main.lib in Linker -> Input -> Additional Dependencies and I have made sure that the VC++ Directories are correct.

unresolved external symbol __imp__fprintf and __imp____iob_func, SDL2

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有人能解释一下__imp__fprintf和__imp____iob_func未解决的外部手段？因为当我试图编译时，我会得到这些错误：1>SDL2main.lib(SDL_windows_main.obj) : error LNK2019: unresolved external symbol __imp__fprin...

问未解析的外部符号impfprintf和imp__iob_func，SDL2
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问未解析的外部符号__imp__fprintf和__imp____iob_func，SDL2EN