I recently moved from a Windows 10 computer to a Windows 11 computer; I had previously been using Version 10 of Pelles C, but it wouldn't work in Windows 11, so I "jumped" all the way up to Pelles C Version 14.5.
Two programs I "test" compiled under version 14.5 compiled and linked just fine, no problems.
But a third program, that compiled just fine under version 10, is now getting the following error message under Version 14.5:
POLINK: error: Unresolved external symbol '__stod' - referenced from 'C:\Users\steco\Documents\Pelles C Projects\LotteryScratchOffs\output\LotteryScratchOffs.obj'.
I have searched this forum for information about this, but found only one refernce to it from 12 years ago.
I have also search the Internet and can find no information about this '__stod' symbol.
Can somebody help me, please?
Just search it from a your code.
A macro atof use it in version 10.
/* internal stuff */
...
/* macro overrides */
#define atof(s) __stod(s,0,0)
[155]extern _CRTIMP double __cdecl __stod(const char *, char **, long);
[172]#define atof(s) __stod(s,0,0)
[177]#define strtod(s,endptr) __stod(s,endptr,0)
One of the first things I did was search my code for a reference to 'stod'; there are none. Next, I checked the help files for information about it...there is none.
You mentioned a macro reference to the atof() function; I looked it up in the help files to see what include file is required: "stdlib.h". It's always been included in the original code from the begining.
What has changed from version 10 to version 14 that this error is now occuring?
And how do I fix it?
I have found a simple solution to the current problem and the problem of Version 10 not working in Windows 11.
I uninstalled version 14.5, and installed version 11. Years ago, I had downloaded the setup.exe for version 11 and never installed it (ditto for version 12); I was perfectly happy with version 10.
Version 10 was latest version, that have __stod in stdlib.h and version 13 in crt.lib
So a your source code have a problem with it, not following standard C.
Some an old user libs might refer to it.
Hint, remove Pelles C reg settings while testing different versions.
REGEDIT4
[-HKEY_CURRENT_USER\Software\Pelle Orinius]
Hi Steven:
Did you clean the Project of the old .obj files before rebuilding ?
If the source of LotteryScratchOffs.obj has not been changed, the source for LotteryScratchOffs.obj will not be recompiled and the old .obj will be used.
Quote from: Robert on Yesterday at 12:47:15 AMHi Steven:
Did you clean the Project of the old .obj files before rebuilding ?
If the source of LotteryScratchOffs.obj has not been changed, the source for LotteryScratchOffs.obj will not be recompiled and the old .obj will be used.
I've always forced a complete rebuild by saving the main include file, even if I changed nothing in it; this causes the compiler to rebuild everything in the project that includes that include file.
Hi Steven,
You should not have to recompile everything if some files are not modified.
Quote from: StevenCooper on July 19, 2026, 08:15:51 AMPOLINK: error: Unresolved external symbol '__stod' - referenced from 'C:\Users\steco\Documents\Pelles C Projects\LotteryScratchOffs\output\LotteryScratchOffs.obj'.
__stod() was an internal helper function, no longer needed, and (obviously) never documented.
This symbol can't pop out of thin air, so the most likely reasons are:
1) you are somehow pulling in (old) #include files from the wrong directory
2) the file
LotteryScratchOffs.obj is not (re)built properly, or the associated source file (
LotteryScratchOffs.c ?!) contains some private reference to __stod.
Quote from: Pelle on Yesterday at 02:55:21 PMQuote from: StevenCooper on July 19, 2026, 08:15:51 AMPOLINK: error: Unresolved external symbol '__stod' - referenced from 'C:\Users\steco\Documents\Pelles C Projects\LotteryScratchOffs\output\LotteryScratchOffs.obj'.
__stod() was an internal helper function, no longer needed, and (obviously) never documented.
This symbol can't pop out of thin air, so the most likely reasons are:
1) you are somehow pulling in (old) #include files from the wrong directory
2) the file LotteryScratchOffs.obj is not (re)built properly, or the associated source file (LotteryScratchOffs.c ?!) contains some private reference to __stod.
If I'm remembering correctly, when I jumped to version 14.5, I did NOT first uninstall version 10; so, maybe the Setup program did not overwrite some of the old files; it was a pretty big jump.
As it turns out, I really didn't need to abandon version 10 after all; the problem I had when I installed it on Windows 11 Pro was I would get this error message when trying to build a project:
Error Code: 1073741819
The .obj files would get built, then the above error message would appear, and the build would stop. I have since discovered that all I need to do when I get that message is click on the "Build" button again, and the build process will finish correctly.
I have found that Version 11 of Pelles C has the same problem, intermittently, and again, I just click on the "Build" button a second time and the process finishes and I have an executable program.
Before I left Windows 10, I saved the Registry keys for Pelles configuration, so I could restore my configuration in the new version. I installed those keys in the Windows 11 registry
before I installed Pelles C Version 10.
Any chance those old registry keys are causing problems?
I do have a precompiled library called Srclib from Version 10; perhaps I need to re-compile it in Version 14.5 before I recompile programs that use that library (almost all my programs use it).
I may, if I decide to move to Version 14, try completely uninstalling Pelles c, and manually delete registry keys and residual files and folders before doing a "clean" install of version 14. However, for now, I'm perfectly happy with Version 11, more or less.