Error starting c++ program linking to libstdc++-6.dll on Windows 9x without KernelEx
keith Reply To qiannangong
LIBSTDC++-6.DLL bundled in latest package requires an export named CreateHardLinkW in KERNEL32.DLL, which seems not to be available on vanilla Windows 9x platform...
That may very well be the case, but can you please provide more details of the exact manner in which it fails?
FWIW, we build libstdc++-6.dll from unmodified sources, maintained by the upstream GCC project; that project no longer considers Win9x to be a supported platform, so it becomes increasingly difficult — although not necessarily impossible — for us to continue to support it. At present, our kernel32.def specifies CreateHardLinkW@12 as a universally exported symbol, from kernel32.dll; if, as may well be the case, that isn't true of Win9x versions, then we may need to substitute an alternative implementation, to perform a GetProcAddress() probe, rather than assume universal availability. However, since I no longer use any version of Windows as a day-to-day OS, and I have virtualized support for only WinXP and Win7, I have no way to test such a solution, (but I may be able to offer advice on a suitable implementation).
However, A static linked program may work only if it does not use the APIs may refer to the CreateHardLinkW.
Can you provide a small, self contained, compilable example, to illustrate this technique, please?
keith Reply To keith
... but I may be able to offer advice on a suitable implementation ...
FWIW, this (compilable, but otherwise untested) implementation may suffice, as a replacement for the unconditionally exported CreateHardLinkW@12 export spec:
- #include "legacy.h"
- #include <winbase.h>
- #include <winerror.h>
- WINBASEAPI BOOL WINAPI CreateHardLinkW
- (LPCWSTR NewFile, LPCWSTR ToFile, LPSECURITY_ATTRIBUTES attrib)
- {
- typedef BOOL WINAPI (*api)( LPCWSTR, LPCWSTR, LPSECURITY_ATTRIBUTES );
- static void *call = API_UNCHECKED;
- return ((call = __kernel32_entry_point( call, __FUNCTION__ )) != NULL)
- ? ((api)(call))( NewFile, ToFile, attrib )
- : ERROR_OLD_WIN_VERSION;
- }
I'm sorry for late reply but I can't always connect to OSDN.net due to network restriction . I've attached a screenshot from a Windows 98 SE VM to reproduce this issue. And btw, LTO is not available on Windows 9x either.
keith Reply To qiannangong
I've attached a screenshot from a Windows 98 SE VM to reproduce this issue.
So, failure occurs before the dynamic linker (a.k.a. the Windows program loader) even attempts to pass control to the program entry point. Failure is the result of the dynamic linker's attempt to resolve a CreateHardLinkW() reference, while loading libstdc++-v6.dll; as you have noted, this symbol is not present in Win9x;s kernel32.dll (whence it is expected to be exported).
Technically, this is a gratuitous misuse of the CreateHardLink() API, within libstdc++-v6.dll, (which is maintained by the GCC project, not by us). However, the GCC project team are unlikely to view any related bug report sympathetically; they are more likely to dismiss it, on the premise that Win9x is no longer supported. Thus, we need to provide our own workaround, if we wish to preserve such legacy support.
A possible solution may be to remove the gratuitous declaration of CreateHardLinkW@12, as a libkernel32.dll export, from our kernel32.def source file, and add a pre-compiled variant of the stub code, which I suggested previously, to our libkernel32.a import library. I can make this modification, and post it here, but I will need your participation to test it, before I incorporate it formally into our w32api distribution.
And btw, LTO is not available on Windows 9x either.
That certainly appears to be the case. However, you have already demonstrated the solution; you may wish to add the -fno-lto option to your GCC specs file, on your Win9x platform, to ensure that it is always specified, when you compile on that platform.
keith keith keith Reply To keith, in former reply to qiannangong
A possible solution may be to remove the gratuitous declaration of CreateHardLinkW@12, as a libkernel32.dll export, from our kernel32.def source file, and add a pre-compiled variant of the stub code, which I suggested previously, to our libkernel32.a import library. I can make this modification, and post it here, ...
A modified version of libkernel32.a is now attached, here; the patch I used to implement the modification is here.
... but I will need your participation to test it, before I incorporate it formally into our w32api distribution.
Since I do not have any capability to test this myself, I must ask you to do so, on my behalf. Please replace your existing libkernel32.dll, (in a standard installation, you will find it at C:\MinGW\lib\libkernel32.dll), with the attached, modified version, and then rebuild your test program; hopefully you will then be able to run it successfully.
umm... May a precompiled libstdc++-6.dll be much useful...
I think I may be having the same issue. I keep getting "libstdc++-6.dll" failed to initialize, aborting when I try to install and launch my program within a wine bottle. Note, I did have this working but things broke when I updated mingw. Here is a link to my repo with steps to reproduce.
https://github.com/seanybaggins/qt-package-overalys
You can message me at seanybaggins1@gmail.com if you have questions reproducing.
Fork
LIBSTDC++-6.DLL bundled in latest package requires an export named CreateHardLinkW in KERNEL32.DLL, which seems not to be available on vanilla Windows 9x platform... However, A static linked program may work only if it does not use the APIs may refer to the CreateHardLinkW.