Wx3.3.x doesn't create ddls (Issue #26331)
FDMuir
FDMuir created an issue (wxWidgets/wxWidgets#26331)Using "mingw32-make.exe -f makefile.gcc CFG=64 -j4 BUILD=Release SHARED=1 MONOLITHIC=1 >out10 2>err10" won't produce ddl files with wx3.3.x releases but will produce ddl files using wx3.2.x releases.
Trying to build Codeblocks from source with wx3.2.x releases prior to wx3.2.10 works fine, but wx3.2.10 fails with not being able to find wxmsw32u. Is there a wxmsw32u.dll file?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)Are these known issues?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
oneeyeman1
oneeyeman1 left a comment (wxWidgets/wxWidgets#26331)@FDMuir ,
What error if any did you get? Please check the log file.
What exact version and flavor of MinGW do you use? Where did you get it from?
Did you ask on the C::B forum if it is a known issue/problem?
Thank you.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26331)We really need at least some information about the errors you're getting in order to help you. Please locate the first (few) error(s) in err10 file and post them.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)Thanks
________________________________
From: VZ ***@***.***>
Sent: Tuesday, March 31, 2026 1:22 PM
To: wxWidgets/wxWidgets ***@***.***>
Cc: FDMuir ***@***.***>; Mention ***@***.***>
Subject: Re: [wxWidgets/wxWidgets] Wx3.3.x doesn't create ddls (Issue #26331)
[https://avatars.githubusercontent.com/u/146917?s=20&v=4]vadz left a comment (wxWidgets/wxWidgets#26331)<https://github.com/wxWidgets/wxWidgets/issues/26331#issuecomment-4165268580>
We really need at least some information about the errors you're getting in order to help you. Please locate the first (few) error(s) in err10 file and post them.
—
You are receiving this because you were mentioned.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)@oneeyeman1 :
Which log should I check or include (wx3.2.10 or wx3.3.x) ? C::B isn't aware of this issue that I can tell ? The compiler (15.2.0) is from winlib.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26331)This is becoming more confusing. You said that you had this problem with 3.2.10, where did 3.3.x come from?
Please don't try to reply quickly, collect all the necessary information (obviously including the version of wx you use) and provide it when you have it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)@vadz:
Sorry about confusion! Trying to build C::B using wx3.2.10, I received a failure notice saying that wxmsw32 was not found. A build log selection is attached.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
MaartenBent left a comment (wxWidgets/wxWidgets#26331)When you compile wxWidgets with CFG=64 it installs the libraries and setup headers in wxWidgets\lib\gcc_dll64.
Your include and library paths are -IC:\wxWidgets-3.2.10\lib\gcc_dll\mswu and -LC:\wxWidgets-3.2.10\lib\gcc_dll. So they are not the same as the install path.
So either don't add CFG=64 when building wxWidgets, or update your C::B project with the correct paths. (or rename the folder).
Also note that CFG=64 does not mean you are building 64bit libraries (at least as far as I know). It only determines the install folder. Actual 64bit libraries depends on the compiler and/or compile flags.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26331)Maarten is completely correct, of course, but there is still something strange here: why/how did it work with 3.2.9?
@FDMuir Are you use you used CFG before?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)I've used CFG for years. I downgraded to winlib's gnu/gcc 15.1.0 compiler and then built the wx3.2.8 library successfully.
Codeblocks forum responded that they built wx3.3.2 successfully with cmake. They used the compiler from MSYS2.
Months ago, I was able to build codeblocks successfully. Now, when I try building codeblocks, I'm getting failures because wxmsw32u cannot be found. Was wxmsw32u.dll ever included in any wxWidgets release? Could codeblocks have changed?
i
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26331)The DLL was never included in wx release, but it was always built.
Anyhow, your problem should be solved by Maarten's comment above, so this is mostly academic by now.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#26331)You still did not provide the wxWidgets build log, building Code::Blocks has no relevance to the success of failure of building wxWidgets.
No wxWidgets DLL is involved in building Code::Blocks; DLLs are needed when running an application, not building it (import libraries are used).
You are building the non-default monolithic build, AFAIK this was never officially distributed by wxWidgets at least since wxWidgets 3.0.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)@MaartenBent @oneeyeman1 @vadz Thanks for your comments. Sorry about confusing the issue!
@PBfordev Here are the error logs. After building the library for wx3.3.2, still without dll files, I had to invoke setup_h multiple times to make sure the make command completed. Do you still want the build log?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)@PBfordev Here are the error log[s]. Had to change them to text documents. Problem with setup_h.
err10.log
err20.log
err30.log
err40.log
err50.log
err60.log
err70.log
err80.log
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#26331)@PBfordev Here are the error log[s]. Had to change them to text documents. Problem with setup_h.
The logs indicate this was wxWidgets 3.3 build.
../../src/msw/dirdlg.cpp: In function 'HRESULT wxMSWImpl::InitShellItemFromPath(wxCOMPtr&, const wxString&)':
../../src/msw/dirdlg.cpp:406:12: error: '::SHCreateItemFromParsingName' has not been declared
406 | hr = ::SHCreateItemFromParsingName
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
AFAICT, in wxWidgets 3.2, SHCreateItemFromParsingName() is loaded dynamically; but in 3.3 it is taken from windows headers, where it seems to be missing in your compiler (odd, must be very outdated headers?).
BTW, you should not build with -jN when wanting an error log, the overlapping messages from parallel builds make the log messy. There may be some other errors (webp-related?) but due to your logs, it is hard to tell.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)________________________________
From: PB ***@***.***>
Sent: Wednesday, April 1, 2026 10:23 PM
Cc: FDMuir ***@***.***>; Mention ***@***.***>
Subject: Re: [wxWidgets/wxWidgets] Wx3.3.x doesn't create ddls (Issue #26331)
@PBfordev<https://github.com/PBfordev> Here are the error log[s]. Had to change them to text documents. Problem with setup_h.
The logs indicate this was wxWidgets 3.3 build.
../../src/msw/dirdlg.cpp: In function 'HRESULT wxMSWImpl::InitShellItemFromPath(wxCOMPtr&, const wxString&)':
../../src/msw/dirdlg.cpp:406:12: error: '::SHCreateItemFromParsingName' has not been declared
406 | hr = ::SHCreateItemFromParsingName
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
AFAICT, in wxWidgets 3.2, SHCreateItemFromParsingName() is loaded dynamically; but in 3.3 it is taken from windows headers, where it seems to be missing in your compiler (odd, must be very outdated headers?).
BTW, you should not build with -jN when wanting an error log, the overlapping messages from parallel builds make the log messy. There may be some other errors (webp-related?) but due to your logs, it is hard to tell.
—
You are receiving this because you were mentioned.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)I'll rerun it again tomorrow. without the -jn.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
MaartenBent left a comment (wxWidgets/wxWidgets#26331)I checked the contents of GCC 15.2.0 (with POSIX threads) + MinGW-w64 14.0.0 (UCRT) - release 7 (LATEST) Win64 from winlibs, and in shobjidl.h it does have SHCreateItemFromParsingName. Inside a minimum version check _WIN32_IE_IE70 (0x0700).
wxWidgets sets WINVER, _WIN32_WINNT and _WIN32_IE all to 0x0A00. And I don't think the default makefile.gcc build is overriding this.
src/msw/dirdlg.cpp is including wx/msw/private/filedialog.h, which includes wx/msw/wrapshl.h, which includes <shlobj.h> so the header should also be available.
So I don't know what could cause this build error.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)@MaartenBent Thanks for looking at the latest version of winlib's compiler. I'm pretty sure that that compiler isn't causing the problem.
@PBfordev Here are the build and error logs created without -jn. The dll files are still missing.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#26331)The log has has
g++ -c -o gcc_mswudll\monodll_msw_dialog.o -I....\src\tiff\libtiff -I....\src\jpeg -I....\src\png -I....\3rdparty\libwebp\src -I....\src\zlib -I....\3rdparty\pcre\src\wx -I....\src\expat\expat\lib -mthreads -D__WXMSW__ -I....\lib\gcc_dll\mswu -I....\include -W -Wall -DWXBUILDING -I....\src\stc\scintilla\include -I....\src\stc\scintilla\src -D__WX__ -I....\src\stc\lexilla\access -I....\src\stc\lexilla\include -I....\src\stc\lexilla\lexlib -I....\src\stc\lexilla\include -I....\src\stc\scintilla\include -I....\src\stc\scintilla\src -I....\include\wx\msw\wrl -I....\3rdparty\webview2\build\native\include -DwxUSE_BASE=1 -DWXMAKINGDLL -Wno-ctor-dtor-privacy -Wno-unknown-pragmas -fno-keep-inline-dllexport -D_WIN32_IE=0x0603 -Wno-unused-local-typedefs -Wno-deprecated-declarations -MTgcc_mswudll\monodll_msw_dialog.o -MFgcc_mswudll\monodll_msw_dialog.o.d -MD -MP ../../src/msw/dialog.cpp
Considering what MaartenBent wrote above, this would explain why SHCreateItemFromParsingName() is not declared.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26331)@FDMuir Once again, this is very confusing, your compilation command line doesn't correspond to the command you're showing because there should definitely be no -D_WIN32_IE in it otherwise. Please make sure that you
- Compile unmodified wx sources (of specified version).
- Using unmodified wx makefiles.
- Give excerpt of the log, use
--output-syncoption if you use-jN.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)@vadz The only change that I made was to config.gcc. I added the following to the compiler flags because of instructions from codeblocks wiki page: -fno-keep-inline-dllexport -D_WIN32_IE=0x0603 -Wno-unused-local-typedefs -Wno-deprecated-declarations. I also removed CFG=64 and -ijN from the command line. Do you still want me to re-run it again? I haven't used --output synch option before.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26331)@vadz The only change that I made was to config.gcc. I added the following to the compiler flags because of instructions from codeblocks wiki page: -fno-keep-inline-dllexport -D_WIN32_IE=0x0603 -Wno-unused-local-typedefs -Wno-deprecated-declarations.
OK, but you didn't mention it, so we had no way of knowing about it and this is the change which broke the build.
Anyhow, for me there is no problem here, it should build fine without this definition and -fno-keep-inline-dllexport shouldn't be necessary either (you can keep the warning suppression options although I think they shouldn't actually be useful).
I also removed CFG=64 and -ijN from the command line. Do you still want me to re-run it again? I haven't used --output synch option before.
No, the --output-sync option just makes the output readable even in presence of -j, it doesn't change anything.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
FDMuir
FDMuir left a comment (wxWidgets/wxWidgets#26331)@vadz @PBfordev @MaartenBent Thanks for your patience and efforts. Sorry that I didn't mention having made those changes. I'll run the build again!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.