Red Hat Bugzilla – Bug 844491
tests fail to run: The procedure entry point sprintf_s could not be located in msvcrt.dll
Last modified: 2012-09-07 10:37:31 EDT
Description of problem:
We use Fedora to cross compile an application targetting windows using mingw packages. We also use cppunit to run a number of tests. After upgrading to Fedora 17 the tests fail to run giving the error "The procedure entry point sprintf_s could not be located in the dynamic link library msvcrt.dll
This is using Windows XP with service pack 3
Version-Release number of selected component (if applicable):
Cross compile a test program linking to cppunit and try to run the resulting executable under Windows.
After a casual look into this issue it appears that Cppunit uses the sprintf_s function in TestAssert.h if __STDC_SECURE_LIB__ is defined, which it is in _mingw.h
It looks like the Suse mingw package has a patch for this issue:
Thx for your report.
Can you verify in which upstream version the patch was applied ?
(In reply to comment #1)
> Thx for your report.
> Can you verify in which upstream version the patch was applied ?
I don't believe the patch has been applied upstream. The sprintf_s function being used by cppunit was introduced in VS 2005(msvcrt80.dll) according to:
It may be exported in later versions of msvcrt.dll(vista,7) but at least on XP I get the above error.
I'll attach a patch(same as suse) which fixes the issue for me.
Created attachment 601428 [details]
Patch to fix runtime issue on windows XP
Ok I will reword.
Please forward this patch upstream for inclusion, I will backport once accepted
(In reply to comment #4)
> Ok I will reword.
> Please forward this patch upstream for inclusion, I will backport once
I don't believe the patch is appropriate for upstream inclusion.
Cppunit is using the "secure" version of the sprintf function because the mingw-64 headers make the secure API available. The problem is that the secure functions are only exported in versions of msvcrt.dll in Vista and above(or so the internet tells me) so if you use them you restrict what versions of Windows your executable will run on.
So the patch is really working around what seems to be a problem in mingw-64
There is a somewhat relevant thread on the mingw-64 mailing list:
(In reply to comment #6)
> (In reply to comment #4)
> > Ok I will reword.
> > Please forward this patch upstream for inclusion, I will backport once
> > accepted
> I don't believe the patch is appropriate for upstream inclusion.
So I cannot see how it would be appropriate for fedora either.
Vista and later x64 users should expect to use the secure version.
Anyway, I don't mean that this is to be discussed here, but upstream.