i686-codeblocks-builds (https://github.com/zxunge/i686-codeblocks-builds)
This project looks nice, I see it use github action to build the codeblocks 32 bit version.
I'm asking the author could tried 64bit version also, see here: Hi, this project is nice, can you create a windows 64 bit codeblocks builds? Issue #1 zxunge/i686-codeblocks-builds (https://github.com/zxunge/i686-codeblocks-builds/issues/1)
The github user is not likely to change to 64 bit because MSys2 already has two 64 bit packages UCRT64 and CLANG64 environments https://www.msys2.org/docs/environments/ (https://www.msys2.org/docs/environments/) and their package builds for the MINGW64 environment.
I would suggest forking the repo; I am doing that right now to see if it is easy to change to what I want which is building MINGW64 and maybe MINGW32.
Edit: You do realize the built code is for use under MSys2 MINGW32, correct?
Tim S.
Hi, Tim, thanks for the reply and your work.
i686-codeblocks-builds/.github/workflows/main.yml at main zxunge/i686-codeblocks-builds (https://github.com/zxunge/i686-codeblocks-builds/blob/main/.github/workflows/main.yml)
When I looked at this file, I see this uses msys2 environment, and also it use the 32 bit gcc compiler. So, I think this project support MSys2 MINGW32, am I correct?
But there's still one problem. Using a build script in msys2 can't really build a complete codeblocks. wxSmith related plugins, which are considered the best plugins in CB, always give us errors:
wxsarraystringeditordlg.cpp: In member function 'virtual const wxEventTable* wxsArrayStringEditorDlg::GetEventTable() const':
wxsarraystringeditordlg.cpp:39:19: error: definition of static data member 'wxsArrayStringEditorDlg::sm_eventTable' of dllimport'd class
39 | BEGIN_EVENT_TABLE(wxsArrayStringEditorDlg,wxScrollingDialog)
| ^~~~~~~~~~~~~~~~~~~~~~~
D:/msys64/mingw32/include/wx-3.2/wx/event.h:4371:24: note: in definition of macro 'wxBEGIN_EVENT_TABLE'
4371 | const wxEventTable theClass::sm_eventTable = \
| ^~~~~~~~
wxsarraystringeditordlg.cpp:39:1: note: in expansion of macro 'BEGIN_EVENT_TABLE'
39 | BEGIN_EVENT_TABLE(wxsArrayStringEditorDlg,wxScrollingDialog)
| ^~~~~~~~~~~~~~~~~
wxsarraystringeditordlg.cpp: In member function 'virtual wxEventHashTable& wxsArrayStringEditorDlg::GetEventHashTable() const':
wxsarraystringeditordlg.cpp:39:19: error: definition of static data member 'wxsArrayStringEditorDlg::sm_eventHashTable' of dllimport'd class
39 | BEGIN_EVENT_TABLE(wxsArrayStringEditorDlg,wxScrollingDialog)
| ^~~~~~~~~~~~~~~~~~~~~~~
D:/msys64/mingw32/include/wx-3.2/wx/event.h:4375:22: note: in definition of macro 'wxBEGIN_EVENT_TABLE'
4375 | wxEventHashTable theClass::sm_eventHashTable(theClass::sm_eventTable); \
| ^~~~~~~~
wxsarraystringeditordlg.cpp:39:1: note: in expansion of macro 'BEGIN_EVENT_TABLE'
39 | BEGIN_EVENT_TABLE(wxsArrayStringEditorDlg,wxScrollingDialog)
| ^~~~~~~~~~~~~~~~~
wxsarraystringeditordlg.cpp: In constructor 'wxsArrayStringEditorDlg::wxsArrayStringEditorDlg(wxWindow*, wxArrayString&, wxWindowID)':
wxsarraystringeditordlg.cpp:34:12: error: definition of static data member 'wxsArrayStringEditorDlg::ID_TEXTCTRL1' of dllimport'd class
34 | const long wxsArrayStringEditorDlg::ID_TEXTCTRL1 = wxNewId();
| ^~~~~~~~~~~~~~~~~~~~~~~
Hi, thanks.
That's why you disable the wxSmith related option for building C::B
./configure --disable-pch --with-contrib-plugins=all,-wxsmith,-wxsmithaui,-wxsmithcontrib,-Valgrind --prefix=/opt/codeblocks
I see it in:
https://github.com/zxunge/i686-codeblocks-builds/blob/main/.ci/build.sh
The build error message looks like there are some wx related headers are missing when building the translation unit. I don't have much experience on the "configure/make" build system, hope some guys can help.
I see in the wxWidgets Forums a similar error: CodeBlocks compilation (it uses wxWidgets) (https://forums.wxwidgets.org/viewtopic.php?f=19&t=38247), but It's old and didn't have any reply.
This one is old, too: wxPDFDocument - Which files to add to a project (https://forums.wxwidgets.org/viewtopic.php?p=126389#p126389).
Maybe this post is related:
patch for the autotools build to work with Msys2/MinGW32 (https://forums.next.codeblocks.org/index.php/topic,25794.msg175636.html#msg175636)
I know that one dev in github/msys2 who supports builds C::B for the clang or ucrt ports, but he is not interested in supporting the MinGW64 port. :(
Quote from: Grit Clef on August 17, 2024, 06:59:56 AM
But there's still one problem. Using a build script in msys2 can't really build a complete codeblocks. wxSmith related plugins, which are considered the best plugins in CB, always give us errors:
wxsarraystringeditordlg.cpp: In member function 'virtual const wxEventTable* wxsArrayStringEditorDlg::GetEventTable() const':
wxsarraystringeditordlg.cpp:39:19: error: definition of static data member 'wxsArrayStringEditorDlg::sm_eventTable' of dllimport'd class
39 | BEGIN_EVENT_TABLE(wxsArrayStringEditorDlg,wxScrollingDialog)
| ^~~~~~~~~~~~~~~~~~~~~~~
D:/msys64/mingw32/include/wx-3.2/wx/event.h:4371:24: note: in definition of macro 'wxBEGIN_EVENT_TABLE'
4371 | const wxEventTable theClass::sm_eventTable = \
| ^~~~~~~~
wxsarraystringeditordlg.cpp:39:1: note: in expansion of macro 'BEGIN_EVENT_TABLE'
39 | BEGIN_EVENT_TABLE(wxsArrayStringEditorDlg,wxScrollingDialog)
| ^~~~~~~~~~~~~~~~~
wxsarraystringeditordlg.cpp: In member function 'virtual wxEventHashTable& wxsArrayStringEditorDlg::GetEventHashTable() const':
wxsarraystringeditordlg.cpp:39:19: error: definition of static data member 'wxsArrayStringEditorDlg::sm_eventHashTable' of dllimport'd class
39 | BEGIN_EVENT_TABLE(wxsArrayStringEditorDlg,wxScrollingDialog)
| ^~~~~~~~~~~~~~~~~~~~~~~
D:/msys64/mingw32/include/wx-3.2/wx/event.h:4375:22: note: in definition of macro 'wxBEGIN_EVENT_TABLE'
4375 | wxEventHashTable theClass::sm_eventHashTable(theClass::sm_eventTable); \
| ^~~~~~~~
wxsarraystringeditordlg.cpp:39:1: note: in expansion of macro 'BEGIN_EVENT_TABLE'
39 | BEGIN_EVENT_TABLE(wxsArrayStringEditorDlg,wxScrollingDialog)
| ^~~~~~~~~~~~~~~~~
wxsarraystringeditordlg.cpp: In constructor 'wxsArrayStringEditorDlg::wxsArrayStringEditorDlg(wxWindow*, wxArrayString&, wxWindowID)':
wxsarraystringeditordlg.cpp:34:12: error: definition of static data member 'wxsArrayStringEditorDlg::ID_TEXTCTRL1' of dllimport'd class
34 | const long wxsArrayStringEditorDlg::ID_TEXTCTRL1 = wxNewId();
| ^~~~~~~~~~~~~~~~~~~~~~~
There is an MSys2 Mingw PR that fixes the building wxSmith; they fixed it in a way I do not like; but, it appears to compile with the Msys2 MINGW CI server.
Tim S.
Release updated: with a complete codeblocks of both 32bit and 64bit version.
Quote from: Grit Clef on August 18, 2024, 05:50:48 AM
Release updated: with a complete codeblocks of both 32bit and 64bit version.
Nice work!!!
Now, the new site is:
https://github.com/zxunge/x86-codeblocks-builds
I have forked the project, and enabled the github action, and I manually start a build action runner for the 64bit C::B.
See here:
https://github.com/asmwarrior/x86-codeblocks-builds/actions/runs/10446493022
It looks like the build is successful. When I download the result file, in github, it is called Artifacts, named "codeblocks64.zip"
I download the zip file, and extract it in my computer, it looks like the structure is like "Linux file system", here is the structure:
# tree
.
├── bin
│ ├── cb_console_runner.exe
│ ├── cb_share_config.exe
│ ├── codeblocks.exe
│ ├── libcodeblocks-0.dll
│ ├── libwxchartctrl-0.dll
│ ├── libwxcustombutton-0.dll
│ ├── libwxflatnotebook-0.dll
│ ├── libwximagepanel-0.dll
│ ├── libwxkwic-0.dll
│ ├── libwxled-0.dll
│ ├── libwxmathplot-0.dll
│ ├── libwxsmithlib.dll
│ └── libwxspeedbutton-0.dll
├── include
│ ├── codeblocks
│ │ ├── annoyingdialog.h
│ │ ├── autodetectcompilers.h
│ │ ├── backgroundthread.h
│ │ ├── base64.h
│ │ ├── blockallocated.h
│ │ ├── cbart_provider.h
│ │ ├── cbauibook.h
│ │ ├── cbcolourmanager.h
│ │ ├── cbdebugger_interfaces.h
...
I think we need a tool named "copy dependency", I mean we need a tool to copy all the dependency dlls to the bin folder.
This tool could be used: brechtsanders/pedeps: Cross-platform C library to read data from PE/PE+ files (the format of Windows .exe and .dll files) (https://github.com/brechtsanders/pedeps)
Another issue is that we don't need the "include" folders.
Also, I think the file structure could be like "Windows" system? I mean there is a share folder in the same folder of the codeblocks.exe.
[History for mingw-w64-codeblocks - msys2/MINGW-packages](https://github.com/msys2/MINGW-packages/commits/master/mingw-w64-codeblocks)
I just looked at the change log for the msys2's codeblocks code changes, they have just enabled the wxSmith 3 days ago.
Also, they have another commit to move the dll files.
I'm working on making a Windows-style build; i.e. build cb using cb through cmdline
It may be not needed to copy those dependencies; users can install those packages through pacman.
Quote from: Grit Clef on August 19, 2024, 12:10:36 PM
I'm working on making a Windows-style build; i.e. build cb using cb through cmdline.
I'm not sure whether the codeblocks.exe could run in pure "command line mode". Hopefully it could.
Not in that way. I just came up with an idea, that is, using cbp2make to generate Makefiles, and make using that. I am trying. See http://github.com/zxunge/winstyle-codeblocks-bins (http://github.com/zxunge/winstyle-codeblocks-bins)
Quote from: Grit Clef on August 19, 2024, 12:55:46 PM
Not in that way. I just came up with an idea, that is, using cbp2make to generate Makefiles, and make using that. I am trying. See http://github.com/zxunge/winstyle-codeblocks-bins (http://github.com/zxunge/winstyle-codeblocks-bins)
Well, I haven't used that cbp2make plugin before. Hope you will make success. :)
But why a lot of undefined errors?
g++.exe -shared -LD:/msys64/opt/wxwidgets3.2/lib\gcc_dll -Ldevel32 .objs32\\sdk\\scripting\\bindings\\sc_plugin.o .objs32\\sdk\\scripting\\bindings\\scriptbindings.o .objs32\\sdk\\scripting\\bindings\\sc_wxtypes.o .objs32\\sdk\\scripting\\bindings\\sc_utils.o .objs32\\sdk\\scripting\\bindings\\sc_util_dialogs.o .objs32\\sdk\\scripting\\bindings\\sc_tinyxml.o .objs32\\sdk\\scripting\\bindings\\sc_progress.o .objs32\\sdk\\scripting\\bindings\\sc_io.o .objs32\\sdk\\scripting\\bindings\\sc_globals.o .objs32\\sdk\\scripting\\bindings\\sc_consts.o .objs32\\sdk\\workspaceloader.o .objs32\\sdk\\uservarmanager.o .objs32\\sdk\\toolsmanager.o .objs32\\sdk\\tinywxuni.o .objs32\\sdk\\templatemanager.o .objs32\\sdk\\selecttargetdlg.o .objs32\\sdk\\searchresultslog.o .objs32\\sdk\\sdk_events.o .objs32\\sdk\\scrollingdialog.o .objs32\\sdk\\scriptsecuritywarningdlg.o .objs32\\sdk\\scriptingmanager.o .objs32\\sdk\\mozilla_chardet\\src\\nsEUCJPProber.o .objs32\\sdk\\mozilla_chardet\\src\\nsMBCSSM.o .objs32\\sdk\\mozilla_chardet\\src\\nsMBCSGroupProber.o .objs32\\sdk\\mozilla_chardet\\src\\nsLatin1Prober.o .objs32\\sdk\\mozilla_chardet\\src\\nsHebrewProber.o .objs32\\sdk\\mozilla_chardet\\src\\nsGB2312Prober.o .objs32\\sdk\\mozilla_chardet\\src\\nsEscSM.o .objs32\\sdk\\mozilla_chardet\\src\\nsEscCharsetProber.o .objs32\\sdk\\mozilla_chardet\\src\\nsEUCTWProber.o .objs32\\sdk\\mozilla_chardet\\src\\nsEUCKRProber.o .objs32\\sdk\\mozilla_chardet\\src\\nsSBCSGroupProber.o .objs32\\sdk\\mozilla_chardet\\src\\nsCharSetProber.o .objs32\\sdk\\mozilla_chardet\\src\\nsBig5Prober.o .objs32\\sdk\\mozilla_chardet\\src\\LangThaiModel.o .objs32\\sdk\\mozilla_chardet\\src\\LangHungarianModel.o .objs32\\sdk\\mozilla_chardet\\src\\LangHebrewModel.o .objs32\\sdk\\mozilla_chardet\\src\\LangGreekModel.o .objs32\\sdk\\mozilla_chardet\\src\\LangCyrillicModel.o .objs32\\sdk\\mozilla_chardet\\src\\LangBulgarianModel.o .objs32\\sdk\\mozilla_chardet\\src\\JpCntx.o .objs32\\sdk\\pipedprocess.o .objs32\\sdk\\projectloader_hooks.o .objs32\\sdk\\projectloader.o .objs32\\sdk\\projectlayoutloader.o .objs32\\sdk\\projectfileoptionsdlg.o .objs32\\sdk\\projectfile.o .objs32\\sdk\\projectbuildtarget.o .objs32\\sdk\\printing_types.o .objs32\\sdk\\pluginsconfigurationdlg.o .objs32\\sdk\\pluginmanager.o .objs32\\sdk\\personalitymanager.o .objs32\\sdk\\newfromtemplatedlg.o .objs32\\sdk\\multiselectdlg.o .objs32\\sdk\\mozilla_chardet\\src\\nsUniversalDetector.o .objs32\\sdk\\mozilla_chardet\\src\\nsUTF8Prober.o .objs32\\sdk\\mozilla_chardet\\src\\nsSJISProber.o .objs32\\sdk\\mozilla_chardet\\src\\nsSBCharSetProber.o .objs32\\sdk\\mozilla_chardet\\src\\CharDistribution.o .objs32\\sdk\\projectmanager.o .objs32\\sdk\\projecttemplateloader.o .objs32\\sdk\\projectsfilemasksdlg.o .objs32\\sdk\\xtra_res.o .objs32\\sdk\\editorlexerloader.o .objs32\\sdk\\filemanager.o .objs32\\sdk\\filegroupsandmasks.o .objs32\\sdk\\filefilters.o .objs32\\sdk\\externaldepsdlg.o .objs32\\sdk\\encodingdetector.o .objs32\\sdk\\edittooldlg.o .objs32\\sdk\\editpathdlg.o .objs32\\sdk\\editpairdlg.o .objs32\\sdk\\editormanager.o .objs32\\sdk\\findreplacedlg.o .objs32\\sdk\\editorcolourset.o .objs32\\sdk\\editorbase.o .objs32\\sdk\\editor_utils.o .objs32\\sdk\\editor_hooks.o .objs32\\sdk\\editarraystringdlg.o .objs32\\sdk\\editarrayorderdlg.o .objs32\\sdk\\editarrayfiledlg.o .objs32\\sdk\\debuggermanager.o .objs32\\sdk\\manager.o .objs32\\sdk\\menuitemsmanager.o .objs32\\sdk\\cygwin.o .objs32\\sdk\\macrosmanager.o .objs32\\sdk\\logmanager.o .objs32\\sdk\\loggers.o .objs32\\sdk\\infowindow.o .objs32\\sdk\\incremental_select_helper.o .objs32\\sdk\\importers_globals.o .objs32\\sdk\\globals.o .objs32\\sdk\\genericmultilinenotesdlg.o .objs32\\sdk\\autodetectcompilers.o .objs32\\sdk\\cbexception.o .objs32\\sdk\\cbeditorprintout.o .objs32\\sdk\\cbeditor.o .objs32\\sdk\\cbdebugger_interfaces.o .objs32\\sdk\\cbcolourmanager.o .objs32\\sdk\\cbauibook.o .objs32\\sdk\\cbart_provider.o .objs32\\sdk\\blockallocated.o .objs32\\sdk\\base64.o .objs32\\sdk\\cbplugin.o .objs32\\sdk\\annoyingdialog.o .objs32\\sdk\\compiler.o .objs32\\sdk\\crc32.o .objs32\\sdk\\confirmreplacedlg.o .objs32\\sdk\\configuretoolsdlg.o .objs32\\sdk\\configurationpanel.o .objs32\\sdk\\configmanager.o .objs32\\sdk\\compiletargetbase.o .objs32\\sdk\\compileroptions.o .objs32\\sdk\\compilerfactory.o .objs32\\sdk\\compilercommandgenerator.o .objs32\\sdk\\compileoptionsbase.o .objs32\\sdk\\ccmanager.o .objs32\\sdk\\cbworkspace.o .objs32\\sdk\\cbtreectrl.o .objs32\\sdk\\cbthreadpool.o .objs32\\sdk\\cbstyledtextctrl.o .objs32\\sdk\\cbstatusbar.o .objs32\\sdk\\cbproject.o .objs32\\sdk\\configmanager-revision.o -o devel32\\codeblocks.dll -Wl,--enable-auto-image-base -Wl,--add-stdcall-alias -Wl,--enable-auto-import -Wl,--no-undefined -lwxmsw32u -lshfolder -ltxml -lwxscintilla_cb -lsquirrel -lgdi32
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0x3ff): undefined reference to `_imp___ZN9wxControl6CreateEP8wxWindowiRK7wxPointRK6wxSizelRK11wxValidatorRK8wxString'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0x4a8): undefined reference to `_imp___ZN12wxWindowBase14SetInitialSizeERK6wxSize'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xad84): undefined reference to `_imp___ZN17wxStringTokenizerC1ERK8wxStringS2_21wxStringTokenizerMode'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xadae): undefined reference to `_imp___ZN17wxStringTokenizer12GetNextTokenEv'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xb0a6): undefined reference to `_imp___ZNK17wxStringTokenizer13HasMoreTokensEv'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xb1a7): undefined reference to `_imp___ZN6wxFont11SetFaceNameERK8wxString'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xb583): undefined reference to `_imp___ZN7wxFFileC1ERK8wxStringS2_'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xb5aa): undefined reference to `_imp__wxConvCurrent'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xb5d8): undefined reference to `_imp___ZN7wxFFile5WriteERK8wxStringRK8wxMBConv'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xb6a8): undefined reference to `_imp___ZN7wxFFileC1ERK8wxStringS2_'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xb704): undefined reference to `_imp___ZN7wxFFile7ReadAllEP8wxStringRK8wxMBConv'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xc0a4): undefined reference to `_imp___ZN9wxPaintDCC1EP8wxWindow'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xc1cb): undefined reference to `_imp___ZN11wxScrollBar12ms_classInfoE'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xdb33): undefined reference to `_imp__wxEVT_PAINT'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xdb42): undefined reference to `_imp__wxEVT_PAINT'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xdbb4): undefined reference to `_imp__wxEVT_SCROLLWIN_TOP'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xdbc3): undefined reference to `_imp__wxEVT_SCROLLWIN_TOP'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xdc32): undefined reference to `_imp__wxEVT_SCROLLWIN_BOTTOM'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xdc41): undefined reference to `_imp__wxEVT_SCROLLWIN_BOTTOM'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xdcb0): undefined reference to `_imp__wxEVT_SCROLLWIN_LINEUP'
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: devel32/libwxscintilla_cb.a(wxscintilla.o):wxscintilla.cp:(.text+0xdcbf): undefined reference to `_imp__wxEVT_SCROLLWIN_LINEUP'
My guess:
-Wl,--enable-auto-import -Wl,--no-undefined -lwxmsw32u -lshfolder -ltxml -lwxscintilla_cb -lsquirrel -lgdi32
is that the
-lwxmsw32u
should be put "after" the
-lwxscintilla_cb
Quote from: ollydbg on August 19, 2024, 12:23:09 PM
Quote from: Grit Clef on August 19, 2024, 12:10:36 PM
I'm working on making a Windows-style build; i.e. build cb using cb through cmdline.
I'm not sure whether the codeblocks.exe could run in pure "command line mode". Hopefully it could.
Another idea is that we may try some virtual desktop in windows runner?
such as this discussion:
Github action virtual display resolution for windows server 2019 community Discussion #49112 (https://github.com/orgs/community/discussions/49112)
That's exactly the answer! But I don't know why it was successful when using CB projects, while unsuccessful when using cbp2make.
Another error occurred:
zip -jq9 devel32\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
zip error: Nothing to do! (devel32/share/CodeBlocks/manager_resources.zip)
mingw32-make: *** [Makefile_core:958: after_sdk] Error 12
Quote from: Grit Clef on August 19, 2024, 03:45:55 PM
Another error occurred:
zip -jq9 devel32\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
zip error: Nothing to do! (devel32/share/CodeBlocks/manager_resources.zip)
mingw32-make: *** [Makefile_core:958: after_sdk] Error 12
That is the error I get when I use an non windows compatible zip command. I think it is the "\*" that is the main cause of the issue.
Tim S.
Quote from: stahta01 on August 19, 2024, 04:06:20 PM
Quote from: Grit Clef on August 19, 2024, 03:45:55 PM
Another error occurred:
zip -jq9 devel32\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
zip error: Nothing to do! (devel32/share/CodeBlocks/manager_resources.zip)
mingw32-make: *** [Makefile_core:958: after_sdk] Error 12
That is the error I get when I use an non windows compatible zip command. I think it is the "\*" that is the main cause of the issue.
Tim S.
The suggested zip command is from our wiki page:
[4.3 ZIP](https://wiki.codeblocks.org/index.php/MinGW_installation#ZIP)
And I think you are using the zip command from 7zip?
Because from this file:
https://github.com/zxunge/winstyle-codeblocks-bins/blob/main/.github/workflows/main.yml
I don't find you install a zip tool.EDIT: zip
unzip
p7zipI think you are using the zip command from msys2's mingw32 port? I haven't used that zip tool before.
That zip would not work; I have tried several other distributions, but none of them worked.
Quote from: Grit Clef on August 22, 2024, 04:28:17 AM
That zip would not work; I have tried several other distributions, but none of them worked.
Zip file path separator - Stack Overflow (https://stackoverflow.com/questions/60276764/zip-file-path-separator)
or
windows - Zip files expand with backslashes on Linux, no subdirectories - Super User (https://superuser.com/questions/1382839/zip-files-expand-with-backslashes-on-linux-no-subdirectories)
You can see that the zip file format should always use "/".
Can we hack the cb2make plugin?
I just looked at the source code of cb2make project, I see this line:
https://github.com/mirai-computing/cbp2make/blob/d40e6de50a5142f57576d0f2e8e433b7f510270a/src/platforms.cpp#L89
void CPlatform::Assign(const CPlatform& Platform)
{
m_OS_Type = Platform.m_OS_Type;
m_Active = Platform.m_Active;
m_Cmd_Null = Platform.m_Cmd_Null;
m_Cmd_Copy = Platform.m_Cmd_Copy;
m_Cmd_Move = Platform.m_Cmd_Move;
m_Cmd_Make = Platform.m_Cmd_Make;
m_Tool_Make = Platform.m_Tool_Make;
//m_Cmd_TestFile = Platform.m_Cmd_TestFile;
m_Cmd_RemoveFile = Platform.m_Cmd_RemoveFile;
m_Cmd_ForceRemoveFile = Platform.m_Cmd_ForceRemoveFile;
//m_Cmd_TestDir = Platform.m_Cmd_TestDir;
m_Cmd_MakeDir = Platform.m_Cmd_MakeDir;
m_Cmd_TestMakeDir = Platform.m_Cmd_TestMakeDir;
m_Cmd_ForceMakeDir = Platform.m_Cmd_ForceMakeDir;
m_Cmd_RemoveDir = Platform.m_Cmd_RemoveDir;
m_Cmd_PrintWorkDir = Platform.m_Cmd_PrintWorkDir;
m_Cmd_EvalWorkDir = Platform.m_Cmd_EvalWorkDir;
m_Cmd_ChangeDir = Platform.m_Cmd_ChangeDir;
m_PathDelimiter = Platform.m_PathDelimiter;
m_LibraryPrefix = Platform.m_LibraryPrefix;
m_StaticLibraryExtensions = Platform.m_StaticLibraryExtensions;
m_DynamicLibraryExtensions = Platform.m_DynamicLibraryExtensions;
}
So, we can hack the "m_PathDelimiter" variable? for Windows system?
Quote from: ollydbg on August 24, 2024, 02:57:46 PM
I just looked at the source code of cb2make project, I see this line:
https://github.com/mirai-computing/cbp2make/blob/d40e6de50a5142f57576d0f2e8e433b7f510270a/src/platforms.cpp#L89
void CPlatform::Assign(const CPlatform& Platform)
{
m_OS_Type = Platform.m_OS_Type;
m_Active = Platform.m_Active;
m_Cmd_Null = Platform.m_Cmd_Null;
m_Cmd_Copy = Platform.m_Cmd_Copy;
m_Cmd_Move = Platform.m_Cmd_Move;
m_Cmd_Make = Platform.m_Cmd_Make;
m_Tool_Make = Platform.m_Tool_Make;
//m_Cmd_TestFile = Platform.m_Cmd_TestFile;
m_Cmd_RemoveFile = Platform.m_Cmd_RemoveFile;
m_Cmd_ForceRemoveFile = Platform.m_Cmd_ForceRemoveFile;
//m_Cmd_TestDir = Platform.m_Cmd_TestDir;
m_Cmd_MakeDir = Platform.m_Cmd_MakeDir;
m_Cmd_TestMakeDir = Platform.m_Cmd_TestMakeDir;
m_Cmd_ForceMakeDir = Platform.m_Cmd_ForceMakeDir;
m_Cmd_RemoveDir = Platform.m_Cmd_RemoveDir;
m_Cmd_PrintWorkDir = Platform.m_Cmd_PrintWorkDir;
m_Cmd_EvalWorkDir = Platform.m_Cmd_EvalWorkDir;
m_Cmd_ChangeDir = Platform.m_Cmd_ChangeDir;
m_PathDelimiter = Platform.m_PathDelimiter;
m_LibraryPrefix = Platform.m_LibraryPrefix;
m_StaticLibraryExtensions = Platform.m_StaticLibraryExtensions;
m_DynamicLibraryExtensions = Platform.m_DynamicLibraryExtensions;
}
So, we can hack the "m_PathDelimiter" variable? for Windows system?
There is an option for msys that should fix the issue under msys2 and may fix it for the poster.
I was planning to test it; but, the issue I had was fixed by an Msys2 packager.
Manage platforms:
cbp2make --config platform [-msys|-unix|-windows|-mac] [-pwd <print_dir_command>]
[-cd <change_dir_command>] [-rm <remove_file_command>]
[-rmf <remove_file_forced>] [-rmd <remove_dir_command>]
[-cp <copy_file_command>] [-mv <move_file_command>]
[-md <make_dir_command>] [-mdf <make_dir_forced>]
[-make <default_make_tool>]
Tim S.
Quote from: stahta01 on August 24, 2024, 04:07:19 PM
There is an option for msys that should fix the issue under msys2 and may fix it for the poster.
I was planning to test it; but, the issue I had was fixed by an Msys2 packager.
Manage platforms:
cbp2make --config platform [-msys|-unix|-windows|-mac] [-pwd <print_dir_command>]
[-cd <change_dir_command>] [-rm <remove_file_command>]
[-rmf <remove_file_forced>] [-rmd <remove_dir_command>]
[-cp <copy_file_command>] [-mv <move_file_command>]
[-md <make_dir_command>] [-mdf <make_dir_forced>]
[-make <default_make_tool>]
Tim S.
Hi, Tim, thanks!
I think the OP should use the option "-msys" for generating the makefile for used by mingw32-make.exe. :)
OK, I will have a try.
Still the same...
I think those commands are from the project files.
The only way I have fixed this issue in the past was to either edit the CBP files or place a good zip command in the path.
To place a good zip command in the path; I first removed or rename the bad zip command and then via trial and error added the path to the good zip command to the PATH using the export command.
Those both worked for me over the past few years; but, neither was easy to automate.
Maybe finding the correct location in cbp2make to edit will be a better solution.
Tim S.
Have you looked at previous forum posts on github actions as per the following thread to see if it has anything useful?
https://forums.next.codeblocks.org/index.php?topic=24972.0
Quote from: Grit Clef on August 25, 2024, 04:05:13 AM
OK, I will have a try.
Still the same...
I think those commands are from the project files.
Correct, those zip command are defined in the cbp files, see the image show below.
But when those command were run from the windows command line (CMD), it works OK.
So, I'm not sure why it works badly under mingw32-make.exe, did you run mingw32-make.exe inside a msys2's mingw64 shell? or a pure CMD shell?
As Tim(stahta01) suggested, I think you have to check which zip executable the mingw32-make.exe was actually calling.
I think I found the reason why the zip command works badly.
I create a very simple makefile:
# Define variables
ZIP = xyz\abc.zip
FILES = xyz\a1.txt
ZIP_CMD = zip -jq9 $(ZIP) $(FILES)
# Default target
all: zip
# Zip target
zip:
$(ZIP_CMD)
# Clean target
clean:
del $(ZIP)
# Phony targets to avoid conflicts with files
.PHONY: all zip clean
Please note that I can run the command "mingw32-make" under the mingw64 shell under msys2, and it works fine.
But if I change the "xyz\a1.txt" to "xyz\*.txt".
It will failed. my guess is that the mingw64 shell will "escape" the "\*" as a special character.
If I change to "FILES = xyz/*.txt", it works OK.
I have tried the zip command inside the mingw64 shell, or I just use the zip command (I mentioned the zip command's link before), all failed if I use the "xyz\*.txt".
Now, I see that "xyz\*.txt" works OK under Windows native command line shell.
So, the solution is: can we call the "mingw32-make.exe" inside the "Windows native CMD"?
Quote from: ollydbg on August 27, 2024, 03:04:56 PM
I think I found the reason why the zip command works badly.
I create a very simple makefile:
# Define variables
ZIP = xyz\abc.zip
FILES = xyz\a1.txt
ZIP_CMD = zip -jq9 $(ZIP) $(FILES)
# Default target
all: zip
# Zip target
zip:
$(ZIP_CMD)
# Clean target
clean:
del $(ZIP)
# Phony targets to avoid conflicts with files
.PHONY: all zip clean
Please note that I can run the command "mingw32-make" under the mingw64 shell under msys2, and it works fine.
But if I change the "xyz\a1.txt" to "xyz\*.txt".
It will failed. my guess is that the mingw64 shell will "escape" the "\*" as a special character.
If I change to "FILES = xyz/*.txt", it works OK.
I have tried the zip command inside the mingw64 shell, or I just use the zip command (I mentioned the zip command's link before), all failed if I use the "xyz\*.txt".
Now, I see that "xyz\*.txt" works OK under Windows native command line shell.
So, the solution is: can we call the "mingw32-make.exe" inside the "Windows native CMD"?
You might try the normal make like this.
MSYS2_ARG_CONV_EXCL=* makeNOTE: The "*" star might need double or single quotes around it. This option is supposed to turn off file handling magic.
See https://www.msys2.org/docs/filesystem-paths/ (https://www.msys2.org/docs/filesystem-paths/)
Tim S.
Quote from: stahta01 on August 27, 2024, 05:49:40 PM
You might try the normal make like this.
MSYS2_ARG_CONV_EXCL=* make
NOTE: The "*" star might need double or single quotes around it. This option is supposed to turn off file handling magic.
See https://www.msys2.org/docs/filesystem-paths/ (https://www.msys2.org/docs/filesystem-paths/)
Tim S.
Hi, Tim, nice finding!
But why do you think "normal make" is needed. I think mingw32-make can still be used if we "disable the file path handling magic".
Quote from: ollydbg on August 28, 2024, 04:32:13 AM
Quote from: stahta01 on August 27, 2024, 05:49:40 PM
You might try the normal make like this.
MSYS2_ARG_CONV_EXCL=* make
NOTE: The "*" star might need double or single quotes around it. This option is supposed to turn off file handling magic.
See https://www.msys2.org/docs/filesystem-paths/ (https://www.msys2.org/docs/filesystem-paths/)
Tim S.
Hi, Tim, nice finding!
But why do you think "normal make" is needed. I think mingw32-make can still be used if we "disable the file path handling magic".
It depends, some things build better with one or the other of make commands and some build okay with both. Till it is tried I see no pattern [useful to predict which will happen].
Tim S.
It was not successful when I tried MSYS2_ARG_CONV_EXCL=* mingw32-make. We can't use normal make, for certain reason(because those lines calling cmd /c will fail.) I always get failed using Windows' pure command line. Maybe we can only use the configure/make structure.
Edit: I'm seeing that cmd /c executed successfully when using normal make. It's hoped that the current action will be successful.
Still failed...
Quote from: Grit Clef on August 31, 2024, 01:23:44 PM
It was not successful when I tried MSYS2_ARG_CONV_EXCL=* mingw32-make. We can't use normal make, for certain reason(because those lines calling cmd /c will fail.) I always get failed using Windows' pure command line. Maybe we can only use the configure/make structure.
Edit: I'm seeing that cmd /c executed successfully when using normal make. It's hoped that the current action will be successful.
Maybe, you should try something like:
MSYS2_ARG_CONV_EXCL='*' mingw32-make
I haven't tried it, because I know nothing about how to debug a github action script.
No, it didn't work.
Quote from: Grit Clef on September 01, 2024, 05:54:08 AM
No, it didn't work.
Sadly to see.
Can you use some dependency tool(such as this one: brechtsanders/pedeps: Cross-platform C library to read data from PE/PE+ files (the format of Windows .exe and .dll files) (https://github.com/brechtsanders/pedeps)) to copy all the dll/exe files to a single folder(for example to a common bin folder) when using the configure/make steps.
I think this is the easiest way to achieve a working github working binary package release.
Thanks.
Some improvements about the github build bot.
1, I think we need to build a "CbLauncher.exe" in the "bin" folder(the codeblocks.exe is in the the same bin folder), currently the configure-make method in the build bot does not generate this file. I mean by running this exe file, C::B is running in portable mode, all the configure settings were created in "bin/AppData" folder, so it won't pollute other C::B settings. For my test, I just copy a "CbLauncher.exe" from other windows build packages, and it works.
2, when I download the "Artifacts" file from the github action (for example, in my own github action here: https://github.com/asmwarrior/x86-codeblocks-builds/actions/runs/10538520726), I need to set the PATH variable to adding my local msys2/mingw64/bin path
set PATH=<your_local_msys2_mingw64_bin_path>;%PATH%
by setting this, when code::blocks runs, it will find the gcc's dlls, wx's dlls, and exchnl's dlls. (suppose you install them by the pacman command)
Here is the list of dlls of the codeblocks.exe by using brechtsanders/pedeps: Cross-platform C library to read data from PE/PE+ files (the format of Windows .exe and .dll files) (https://github.com/brechtsanders/pedeps)'s listpedeps commands:
listpedeps.exe -s codeblocks.exe
[codeblocks.exe]
architecture: x86_64
machine name: AMD AMD64 (x64)
subsystem: Windows GUI
DLL: no
stripped: no
file version: 0.0
minimum Windows version: 5.2
IMPORTS
libcodeblocks-0.dll
COMCTL32.dll
exchndl.dll
libgcc_s_seh-1.dll
KERNEL32.dll
msvcrt.dll
SHELL32.dll
libstdc++-6.dll
USER32.dll
wxbase32u_gcc_custom.dll
wxmsw32u_aui_gcc_custom.dll
wxmsw32u_core_gcc_custom.dll
wxmsw32u_html_gcc_custom.dll
wxmsw32u_propgrid_gcc_custom.dll
wxmsw32u_xrc_gcc_custom.dll
So, you can see that you need to copy those dlls from the msys2 mingw64's bin folder, so that you can distribute a full package:
exchndl.dll
libgcc_s_seh-1.dll
libstdc++-6.dll
wxbase32u_gcc_custom.dll
wxmsw32u_aui_gcc_custom.dll
wxmsw32u_core_gcc_custom.dll
wxmsw32u_html_gcc_custom.dll
wxmsw32u_propgrid_gcc_custom.dll
wxmsw32u_xrc_gcc_custom.dl
To copy those dlls from the msys2's bin folder, you have to use another tool named "copypedeps.exe" from "brechtsanders/pedeps".
The commands are something like below:
copypedeps.exe -r -n -v ./codeblocks.exe ./
The options can be explained by the "-h" help command.
copypedeps.exe -h
Usage: copypedeps [-h|-?] [-r] srcfile [...] dstfolder
Parameters:
-h -? display command line help
-r recursively copy dependancies
-n don't overwrite existing files
-d dry run: don't actually copy, just display copy actions
-q quiet mode, only show errors
-v verbose mode (display copy actions)
Description:
Copies .exe and .dll files and all their dependancies to the destination folder.
Version: 0.1.14 (library version: 0.1.14)
So, can you add the extra steps like below:
1, build the CBLauncher.exe
2, use pacman to install the drmingw for the exchndl.dll and related dlls. See here: mingw-w64-x86_64-drmingw (https://packages.msys2.org/package/mingw-w64-x86_64-drmingw?repo=mingw64)
3, use the pedeps to copy all the necessary dlls to the bin folder.
Any ideas?
EDIT:
mingw-w64-x86_64-drmingw is already installed in the current github action code.
EDIT2:
The spell checker plugin is not loaded correctly, so maybe my local msys2 does not have hunspell package installed.
For you information:
I have create a github test project to use pedeps to copy the dlls of a hello.exe file, see here: asmwarrior/test-github-action0 (https://github.com/asmwarrior/test-github-action0)
I haven't used the github action script before, so it takes one hour to tweak the script.
Finally, a artifact zip file is created with several dependency dlls.
$ ls
hello.exe* libgcc_s_seh-1.dll* libstdc++-6.dll* libwinpthread-1.dll*
The exe file is built from the compiler gcc, and the dlls are copied from the msys2's PATH by using the latest pedeps tool.
I have added one commit to my fork, I try to enable the pedeps tool to copy the necessary dlls.
try to use the pedeps tool to copy the dlls to the output folder (https://github.com/asmwarrior/x86-codeblocks-builds/commit/50a43d6b918aa90bf3a54a84d7d5a0d5e57c0f2b)
And I'm starting the github action now, let's see whether it works or not one hour later. :)
Some good news:
It looks the built artifact (zip file) has many dlls which are the dependencies of codeblocks.exe.
When I run the C::B, I see some warnings(see image shot below), it looks like only the dlls for the codeblocks.exe get copied, but some dlls for plugins are missing.
So, I need to loop all the plugin dll files?
Where should I copy those dependency dlls for the plugins. Because for plugin dlls, they are located in the folder:
codeblocks64-zip-folder\lib\codeblocks\plugins\
While the codeblocks.exe is located in
codeblocks64-zip-folder\bin\codeblocks\
One issue still remains, how to build the "CBLauncher.exe"?
EDIT:
The plugin dll's dependency dll issue is solved, see this result:
main64 asmwarrior/x86-codeblocks-builds@691cc2b (https://github.com/asmwarrior/x86-codeblocks-builds/actions/runs/10869247080)
with my commit:
copy the plugin dll's dependency dll to the bin folder (https://github.com/asmwarrior/x86-codeblocks-builds/commit/691cc2b57a72de33d79179b75d6038da3217a258)
Hi, it's been several weeks since my last visit to CB Forums! Glad to see that you have successfully made those dependencies copied! Now, we can use the automatically built CB packages in time on Windows machines.
Maybe there's another idea. If 'arnholm' can set up a webhook that sends a message to our repository each time a commit is given, we can just achieve full automation! Just my guess...
Quote from: Grit Clef on September 21, 2024, 01:00:34 PM
Hi, it's been several weeks since my last visit to CB Forums! Glad to see that you have successfully made those dependencies copied! Now, we can use the automatically built CB packages in time on Windows machines.
Maybe there's another idea. If 'arnholm' can set up a webhook that sends a message to our repository each time a commit is given, we can just achieve full automation! Just my guess...
There are still some problem remains:
1, the cblauncher.exe is not built, I need that file.
2, I need to find a way to make the github action generated file (artifact file) to the release page, so it could be: "release 2024-09-21" for a release, maybe some file rename or other option is needed.
About the webhook, I have many own patches in my git repo, so when a webhook happens, I have to still need "git rebase". It is a bit complex. :(
When I looked at the build log file of the github action:
https://github.com/asmwarrior/x86-codeblocks-builds/actions/runs/10955598063/job/30419828477
You can download that log file.
I see that
2024-09-20T09:18:04.7820971Z make[4]: Entering directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/cb_share_config'
2024-09-20T09:18:04.8036409Z /usr/bin/mkdir -p '/opt/codeblocks/bin'
2024-09-20T09:18:04.8174063Z /usr/bin/mkdir -p '/opt/codeblocks/share/man/man1'
2024-09-20T09:18:04.8805600Z /bin/sh ../../../libtool --mode=install /usr/bin/install -c cb_share_config.exe '/opt/codeblocks/bin'
2024-09-20T09:18:04.9105299Z /usr/bin/install -c -m 644 cb_share_config.1 '/opt/codeblocks/share/man/man1'
2024-09-20T09:18:05.2304536Z libtool: install: /usr/bin/install -c .libs/cb_share_config.exe /opt/codeblocks/bin/cb_share_config.exe
2024-09-20T09:18:05.2454246Z make[4]: Leaving directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/cb_share_config'
2024-09-20T09:18:05.2461699Z make[3]: Leaving directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/cb_share_config'
2024-09-20T09:18:05.2469742Z Making install in ConsoleRunner
2024-09-20T09:18:05.2646492Z make[3]: Entering directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/ConsoleRunner'
2024-09-20T09:18:05.2647480Z depbase=`echo main.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
2024-09-20T09:18:05.2648537Z g++ -DHAVE_CONFIG_H -I. -I../../../src/include -D__WXMSW__ -DCB_AUTOCONF -DPIC -O2 -ffast-math -fPIC -fexceptions -MT main.o -MD -MP -MF $depbase.Tpo -c -o main.o main.cpp &&\
2024-09-20T09:18:05.2649417Z mv -f $depbase.Tpo $depbase.Po
2024-09-20T09:18:06.4095587Z /bin/sh ../../../libtool --tag=CXX --mode=link g++ -O2 -ffast-math -fPIC -fexceptions -Wl,--no-undefined -o cb_console_runner.exe main.o -lpthread
2024-09-20T09:18:06.9737518Z libtool: link: g++ -O2 -ffast-math -fPIC -fexceptions -Wl,--no-undefined -o .libs/cb_console_runner.exe main.o -lpthread
2024-09-20T09:18:07.7308153Z make[4]: Entering directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/ConsoleRunner'
2024-09-20T09:18:07.7514147Z /usr/bin/mkdir -p '/opt/codeblocks/bin'
2024-09-20T09:18:07.7644088Z /usr/bin/mkdir -p '/opt/codeblocks/share/man/man1'
2024-09-20T09:18:07.8263028Z /bin/sh ../../../libtool --mode=install /usr/bin/install -c cb_console_runner.exe '/opt/codeblocks/bin'
2024-09-20T09:18:07.8584054Z /usr/bin/install -c -m 644 cb_console_runner.1 '/opt/codeblocks/share/man/man1'
2024-09-20T09:18:08.1826953Z libtool: install: /usr/bin/install -c .libs/cb_console_runner.exe /opt/codeblocks/bin/cb_console_runner.exe
2024-09-20T09:18:08.1973674Z make[4]: Leaving directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/ConsoleRunner'
2024-09-20T09:18:08.1982839Z make[3]: Leaving directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/ConsoleRunner'
2024-09-20T09:18:08.1990374Z Making install in CBLauncher
2024-09-20T09:18:08.2155613Z make[3]: Entering directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/CBLauncher'
2024-09-20T09:18:08.2299718Z make[4]: Entering directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/CBLauncher'
2024-09-20T09:18:08.2301338Z make[4]: Nothing to be done for 'install-exec-am'.
2024-09-20T09:18:08.2302245Z make[4]: Nothing to be done for 'install-data-am'.
2024-09-20T09:18:08.2303972Z make[4]: Leaving directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/CBLauncher'
2024-09-20T09:18:08.2306123Z make[3]: Leaving directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools/CBLauncher'
2024-09-20T09:18:08.2470671Z make[3]: Entering directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools'
2024-09-20T09:18:08.2612747Z make[4]: Entering directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools'
2024-09-20T09:18:08.2614203Z make[4]: Nothing to be done for 'install-exec-am'.
2024-09-20T09:18:08.2615091Z make[4]: Nothing to be done for 'install-data-am'.
2024-09-20T09:18:08.2616395Z make[4]: Leaving directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools'
2024-09-20T09:18:08.2618080Z make[3]: Leaving directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools'
2024-09-20T09:18:08.2632490Z make[2]: Leaving directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/tools'
2024-09-20T09:18:08.2639951Z Making install in templates
2024-09-20T09:18:08.2799861Z make[2]: Entering directory '/d/a/x86-codeblocks-builds/x86-codeblocks-builds/codeblocks_sfmirror/src/templates'
It looks like the tools/CBLauncher is not built. But I'm not sure why, since the cb_console_runner.exe and cb_share_config.exe are built correctly.
OK, I think I found some reason:
src/tools/cb_share_config/Makefile.am
bin_PROGRAMS = cb_share_config
AM_CPPFLAGS = $(WX_CXXFLAGS) \
$(CB_GLIB2_CFLAGS) \
-I$(top_srcdir)/src/include
cb_share_config_LDFLAGS =
cb_share_config_LDADD = $(WX_LIBS) \
$(CB_GLIB2_LIBS) \
$(CB_TINYXML_LIBS)
cb_share_config_SOURCES = app.cpp \
mainframe.cpp
noinst_HEADERS = app.h \
mainframe.h
man_MANS = cb_share_config.1
EXTRA_DIST = $(srcdir)/*.cbp \
$(srcdir)/wxsmith/*.wxs \
$(man_MANS)
When I looked at this file: src/tools/CBLauncher/Makefile.am
EXTRA_DIST = $(srcdir)/doc/* \
$(srcdir)/icons/* \
$(srcdir)/*.cbp \
icon.rc \
mainpage.h \
launcher.cpp
So, need to modify the later file?
I have already solved the RELEASE problem.
Quote from: Grit Clef on September 21, 2024, 04:41:46 PM
I have already solved the RELEASE problem.
Good work! I'm not sure how the release file will make, but sometimes, I will manually start the github action several times a day, so I would like the release name like: 2024-09-21-22-55? I mean the 22 and 55 are the hour and minus time stamp, maybe the svn revision can also be included.
https://github.com/marketplace/actions/get-timestamp-action
FYI:
The github action can build the CbLauncher.exe now, see:
https://github.com/asmwarrior/x86-codeblocks-builds/actions/runs/10977271271
and
https://github.com/asmwarrior/codeblocks_sfmirror/commits/master
for the latest commits.
Quote from: Grit Clef on September 21, 2024, 05:07:58 PM
https://github.com/marketplace/actions/get-timestamp-action
Thanks. Tweak the github action script is a bit complex for me, I will take some time later. Especially I have to tweak/commit/run action/fail/re-tweak many times. >:(
Quote from: ollydbg on September 22, 2024, 05:17:16 AM
Quote from: Grit Clef on September 21, 2024, 05:07:58 PM
https://github.com/marketplace/actions/get-timestamp-action
Thanks. Tweak the github action script is a bit complex for me, I will take some time later. Especially I have to tweak/commit/run action/fail/re-tweak many times. >:(
Good news, I can make a first release of the github action generated zip file now, see here:
Releases asmwarrior/x86-codeblocks-builds (https://github.com/asmwarrior/x86-codeblocks-builds/releases)
EDIT:It looks like the time string release-2024-09-22-04-01-20 is not correct at least from the UTC+8 local time area. I have already set that time area in the my commit (https://github.com/asmwarrior/x86-codeblocks-builds/commit/f14413bd2eb338ca99744745cfcb774ff04ee5da#diff-14e95509571754787d7eff41889fb367de134851c91fd55d3612a4c620b2aebcR134)
And in my repository, the svn revision and the wxWidgets version now can be Automatically detected.
Quote from: Grit Clef on September 23, 2024, 05:48:09 AM
And in my repository, the svn revision and the wxWidgets version now can be Automatically detected.
Thanks for the info. My github action code for created the release package is mainly created by chatGPT, and has some flaws. I got some warning message like below:
QuoteThe following actions uses node12 which is deprecated and will be forced to run on node16: actions/create-release@v1, actions/upload-release-asset@v1. For more info: https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/
I think I will use your method, and by adding some time stamp for the release.
Question: why do you add a cron section?
schedule:
- cron: '0 0 7,14,21,28 * *'You want to run the github action every week? (chatGPT gives me the answer: the cron expression '0 0 7,14,21,28 * *' means that the job will run at midnight on the 7th, 14th, 21st, and 28th day of every month.)
Quote from: Grit Clef on September 23, 2024, 05:48:09 AM
And in my repository, the svn revision and the wxWidgets version now can be Automatically detected.
You need to check this code for get the svn value string.
https://github.com/arnholm/codeblocks_sfmirror/blob/master/update_revision.sh
because if the git has some customized commits which does not contain the git-svn-id string, it will got empty result in your github action.
EDIT:I think you could use:
git log --graph | grep 'git-svn-id' | head -n 1 | grep -o -e "@\([0-9]*\)" | tr -d '@ '
I want to remove the hack of the dll export hack in building wxsmith plugin.
# Workaround from msys2: error: definition of static data member 'wxsArrayStringEditorDlg::sm_eventTable' of dllimport'd class
# grep -rl "PLUGIN_EXPORT " src/plugins/contrib/wxSmith | xargs -i sed -i "s/PLUGIN_EXPORT //g" {}
So, I remove the hack above.
Now, I see the build error.
It looks like the dll export declaration is not defined.
But when I checked the build log, I see that:
2024-09-24T11:34:32.2601440Z checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
2024-09-24T11:34:32.4010899Z checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
...
...
...
2024-09-24T12:32:02.1013349Z libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../../../src/include -ID:/msys64/mingw64/lib/wx/include/msw-unicode-3.2 -ID:/msys64/mingw64/include/wx-3.2 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMSW__ -I../../../../../src/include -I../../../../../src/sdk/wxscintilla/include -DCB_AUTOCONF -DPIC -O2 -ffast-math -fPIC -fexceptions -MT wxsfloatproperty.lo -MD -MP -MF .deps/wxsfloatproperty.Tpo -c wxsfloatproperty.cpp -DDLL_EXPORT -DPIC -o .libs/wxsfloatproperty.o
...
...
build failed!!!
You see, when building every plugin, the "-DDLL_EXPORT -DPIC" is defined.
But my question is: Where is the "DLL_EXPORT" get defined? I search all the C::B code git repo, and I can't find one.
When I check the cbp files, I see there is no "DLL_EXPORT" defined, instead, in the cbp file, another macro named "BUILDING_PLUGIN", this is core point, because in the
include\cbplugin.h, note this file is included in every cpp file when you need to build a plugin.
#ifdef __WXMSW__
#ifndef PLUGIN_EXPORT
#ifdef EXPORT_LIB
#define PLUGIN_EXPORT __declspec (dllexport)
#else // !EXPORT_LIB
#ifdef BUILDING_PLUGIN
#define PLUGIN_EXPORT __declspec (dllexport)
#else // !BUILDING_PLUGIN
#define PLUGIN_EXPORT __declspec (dllimport)
#endif // BUILDING_PLUGIN
#endif // EXPORT_LIB
#endif // PLUGIN_EXPORT
#else
#define PLUGIN_EXPORT
#endif
So, I think we need to solve this issue.
I even checked the configure.ac file or Makefile.am file, I don't find the DLL_EXPORT definition.
Is this value a predefined string?
When I looked at the link
[MinGW] make check problem Issue #9115 protocolbuffers/protobuf (https://github.com/protocolbuffers/protobuf/issues/9115)
or
Make commands not working on Windows 10 at setting check up Issue #297 libcheck/check (https://github.com/libcheck/check/issues/297)
It looks like the "DLL_EXPORT" is predefined in the auto configure tool?
EDIT:
I will try this patch below in the github action.
diff --git a/src/include/cbplugin.h b/src/include/cbplugin.h
index 10258e5..a3ce67b 100644
--- a/src/include/cbplugin.h
+++ b/src/include/cbplugin.h
@@ -23,11 +23,11 @@
#ifdef EXPORT_LIB
#define PLUGIN_EXPORT __declspec (dllexport)
#else // !EXPORT_LIB
- #ifdef BUILDING_PLUGIN
+ #if defined(BUILDING_PLUGIN) || defined(DLL_EXPORT)
#define PLUGIN_EXPORT __declspec (dllexport)
- #else // !BUILDING_PLUGIN
+ #else // !BUILDING_PLUGIN && !DLL_EXPORT
#define PLUGIN_EXPORT __declspec (dllimport)
- #endif // BUILDING_PLUGIN
+ #endif // BUILDING_PLUGIN || DLL_EXPORT
#endif // EXPORT_LIB
#endif // PLUGIN_EXPORT
#else
Quote from: ollydbg on September 23, 2024, 08:07:48 AM
Quote from: Grit Clef on September 23, 2024, 05:48:09 AM
And in my repository, the svn revision and the wxWidgets version now can be Automatically detected.
Thanks for the info. My github action code for created the release package is mainly created by chatGPT, and has some flaws. I got some warning message like below:
QuoteThe following actions uses node12 which is deprecated and will be forced to run on node16: actions/create-release@v1, actions/upload-release-asset@v1. For more info: https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/
I think I will use your method, and by adding some time stamp for the release.
Question: why do you add a cron section?
schedule:
- cron: '0 0 7,14,21,28 * *'
You want to run the github action every week? (chatGPT gives me the answer: the cron expression '0 0 7,14,21,28 * *' means that the job will run at midnight on the 7th, 14th, 21st, and 28th day of every month.)
Yes. Because then I won't need to run the Actions manually;
And your commands are accepted, thanks.
Oh, when I tried your command:
The result is, first 13571 came out and then an error:
Error: Process completed with exit code 141.
Quote from: Grit Clef on September 24, 2024, 04:39:28 PM
Oh, when I tried your command:
The result is, first 13571 came out and then an error:
Error: Process completed with exit code 141.
The method already works in my fork, see here:
my fork's main branch (https://github.com/asmwarrior/x86-codeblocks-builds/tree/main)
Quote from: ollydbg on September 24, 2024, 03:56:25 PM
When I looked at the link
[MinGW] make check problem Issue #9115 protocolbuffers/protobuf (https://github.com/protocolbuffers/protobuf/issues/9115)
or
Make commands not working on Windows 10 at setting check up Issue #297 libcheck/check (https://github.com/libcheck/check/issues/297)
It looks like the "DLL_EXPORT" is predefined in the auto configure tool?
EDIT:
I will try this patch below in the github action.
diff --git a/src/include/cbplugin.h b/src/include/cbplugin.h
index 10258e5..a3ce67b 100644
--- a/src/include/cbplugin.h
+++ b/src/include/cbplugin.h
@@ -23,11 +23,11 @@
#ifdef EXPORT_LIB
#define PLUGIN_EXPORT __declspec (dllexport)
#else // !EXPORT_LIB
- #ifdef BUILDING_PLUGIN
+ #if defined(BUILDING_PLUGIN) || defined(DLL_EXPORT)
#define PLUGIN_EXPORT __declspec (dllexport)
- #else // !BUILDING_PLUGIN
+ #else // !BUILDING_PLUGIN && !DLL_EXPORT
#define PLUGIN_EXPORT __declspec (dllimport)
- #endif // BUILDING_PLUGIN
+ #endif // BUILDING_PLUGIN || DLL_EXPORT
#endif // EXPORT_LIB
#endif // PLUGIN_EXPORT
#else
Some good news, the above mentioned change works. :)
Another issue/question is that why you need such patch:
https://github.com/asmwarrior/x86-codeblocks-builds/blob/main/0001-fix-32-bit-build-and-wxSmith.patch
?
I looked at this link:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-codeblocks
I don't see they need such patch as yours.
Well, I see your patch's content is too large, and I apply it locally, and I see only two line changes:
see below:
diff --git a/src/plugins/contrib/wxSmith/Makefile.am b/src/plugins/contrib/wxSmith/Makefile.am
index 38262bf..dfe9df2 100644
--- a/src/plugins/contrib/wxSmith/Makefile.am
+++ b/src/plugins/contrib/wxSmith/Makefile.am
@@ -7,7 +7,7 @@ AM_CPPFLAGS = $(WX_CXXFLAGS) \
lib_LTLIBRARIES = libwxsmithlib.la
-libwxsmithlib_la_LDFLAGS = -version-info 0:1:0 -shared
+libwxsmithlib_la_LDFLAGS = @MODULE_SHARED_LDFLAGS@ -version-info 0:1:0 -no-undefined -avoid-version
libwxsmithlib_la_LIBADD = ../../../sdk/libcodeblocks.la \
properties/libwxsmith_properties.la \
I think this is exactly the patch file in msys2 here:
https://github.com/msys2/MINGW-packages/blob/f47229e160e1f31f24fdc6142be7b4df99b1a4c3/mingw-w64-codeblocks/001-makefile-wxsmith-add-no-undefined.patch
Another change line is here:
diff --git a/src/src/Makefile.am b/src/src/Makefile.am
index 49d5dd9..d59889b 100644
--- a/src/src/Makefile.am
+++ b/src/src/Makefile.am
@@ -75,7 +75,7 @@ codeblocks_LDADD += resources.$(OBJEXT) -lexchndl -lcomctl32
codeblocks_DEPENDENCIES = resources.$(OBJEXT)
codeblocks_SOURCES += associations.cpp
resources.$(OBJEXT): resources/resources.rc resources/amd64_dpi_aware_on.manifest
- $(WINDRES) $(WX_CXXFLAGS) -DcbDPI_AWARE_ON --include-dir $(top_srcdir)/src $< $@
+ $(WINDRES) $(WX_CPPFLAGS) -DcbDPI_AWARE_ON --include-dir $(top_srcdir)/src $< $@
endif
noinst_HEADERS = app.h \
This is the command line option you changed for compiling the resource rc file. I don't see a similar patch in msys2's codeblocks folder:
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-codeblocks
Another patch I see is here:
https://github.com/msys2/MINGW-packages/blob/f47229e160e1f31f24fdc6142be7b4df99b1a4c3/mingw-w64-codeblocks/005-codeblocks-plugin-fix.patch
--- a/src/sdk/configmanager.cpp (revision 13538)
+++ b/src/sdk/configmanager.cpp (working copy)
@@ -1497,7 +1497,7 @@
if (plugin_path_global.IsEmpty())
{
if (platform::windows)
- ConfigManager::plugin_path_global = app_path + _T("/../lib/codeblocks/plugins");
+ ConfigManager::plugin_path_global = app_path + _T("\\..\\lib\\codeblocks\\plugins");
else if (platform::macosx)
ConfigManager::plugin_path_global = data_path_global + _T("/plugins");
else
@Tim, can you say something about this code change? If we don't change this, what will happen? I don't see this code change in my github action's code.
Thanks.
See https://sourceforge.net/p/codeblocks/tickets/1497/ (https://sourceforge.net/p/codeblocks/tickets/1497/)
It is a run-time false warning fix when installing cbplugin files.
See also https://sourceforge.net/p/codeblocks/tickets/1498/ (https://sourceforge.net/p/codeblocks/tickets/1498/)
This is an 32 bit build fix and it is also needed for 64 bit wxWidgets 3.3.x building of code::blocks.
Tim S.
Quote from: stahta01 on September 25, 2024, 11:03:04 AM
See https://sourceforge.net/p/codeblocks/tickets/1497/ (https://sourceforge.net/p/codeblocks/tickets/1497/)
It is a run-time false warning fix when installing cbplugin files.
See also https://sourceforge.net/p/codeblocks/tickets/1498/ (https://sourceforge.net/p/codeblocks/tickets/1498/)
This is an 32 bit build fix and it is also needed for 64 bit wxWidgets 3.3.x building of code::blocks.
Tim S.
Thanks, I will try this patch later.
BTW: I'm going to commit the changes in src/include/cbplugin.h mentioned in my previous posts, is that what you suggested way to handle the wxSmith build issue?
Quote from: ollydbg on September 25, 2024, 11:47:12 AM
Quote from: stahta01 on September 25, 2024, 11:03:04 AM
See https://sourceforge.net/p/codeblocks/tickets/1497/ (https://sourceforge.net/p/codeblocks/tickets/1497/)
It is a run-time false warning fix when installing cbplugin files.
See also https://sourceforge.net/p/codeblocks/tickets/1498/ (https://sourceforge.net/p/codeblocks/tickets/1498/)
This is an 32 bit build fix and it is also needed for 64 bit wxWidgets 3.3.x building of code::blocks.
Tim S.
Thanks, I will try this patch later.
BTW: I'm going to commit the changes in src/include/cbplugin.h mentioned in my previous posts, is that what you suggested way to handle the wxSmith build issue?
I have not suggested any wxSmith build fixes; because for some reason I can not test any of them locally on my msys2 mingw enviroments.
I have no idea if it is a software or hardware bug on my PC, I get a false cannot find file message.
Edit: Found the cause of my wxSmith build error; the path to "MINGW-packages" was too long or it had too many sub-folders in it.
Tim S.
Found what I consider the proper fix for building wxSmith under Msys2 MinGW using configure/make.
You need to update the file "ax_cxx_compile_stdcxx.m4" using https://github.com/autoconf-archive/autoconf-archive/blob/master/m4/ax_cxx_compile_stdcxx.m4 (https://github.com/autoconf-archive/autoconf-archive/blob/master/m4/ax_cxx_compile_stdcxx.m4)
Edit2: With the old ax_cxx_compile_stdcxx.m4 the wxsmith plugin was compiled using c++17 instead of c++11 which is what it should have used.
Edit5: Testing implies c++14 works; but, c++17 fails and GCC 14.x defaults to c++17.
Edit: I have not yet finished testing the building and yet to run the plugin.
Edit3: It built and the wxsmith plugin loaded without any message seen by me.
Edit4: I created an git package when I thought svn might have been the cause of the file not found bug. See https://github.com/stahta01/MINGW-packages/tree/codeblocks-git/mingw-w64-codeblocks-git (https://github.com/stahta01/MINGW-packages/tree/codeblocks-git/mingw-w64-codeblocks-git)
And, apply this patch.
--- a/src/plugins/contrib/wxSmith/Makefile.am
+++ b/src/plugins/contrib/wxSmith/Makefile.am
@@ -7,7 +7,11 @@
+if CODEBLOCKS_NT
+AM_CPPFLAGS += -DEXPORT_LIB
+endif
+
lib_LTLIBRARIES = libwxsmithlib.la
-libwxsmithlib_la_LDFLAGS = -version-info 0:1:0 -shared
+libwxsmithlib_la_LDFLAGS = -version-info 0:1:0 -shared -no-undefined
libwxsmithlib_la_LIBADD = ../../../sdk/libcodeblocks.la \
properties/libwxsmith_properties.la \
--- a/src/plugins/contrib/wxSmith/properties/Makefile.am
+++ b/src/plugins/contrib/wxSmith/properties/Makefile.am
@@ -2,6 +2,10 @@ AM_CPPFLAGS = $(WX_CXXFLAGS) \
-I$(top_srcdir)/src/include \
-I$(top_srcdir)/src/sdk/wxscintilla/include
+if CODEBLOCKS_NT
+AM_CPPFLAGS += -DEXPORT_LIB
+endif
+
noinst_LTLIBRARIES = libwxsmith_properties.la
libwxsmith_properties_la_LDFLAGS = @MODULE_SHARED_LDFLAGS@ -version-info 0:1:0 -no-undefined -avoid-version
--- a/src/plugins/contrib/wxSmith/wxwidgets/defitems/Makefile.am
+++ b/src/plugins/contrib/wxSmith/wxwidgets/defitems/Makefile.am
@@ -2,6 +2,10 @@ AM_CPPFLAGS = $(WX_CXXFLAGS) \
-I$(top_srcdir)/src/include \
-I$(top_srcdir)/src/sdk/wxscintilla/include
+if CODEBLOCKS_NT
+AM_CPPFLAGS += -DEXPORT_LIB
+endif
+
noinst_LTLIBRARIES = libwxsmith_wxwidgets_defitems.la
libwxsmith_wxwidgets_defitems_la_LDFLAGS = @MODULE_SHARED_LDFLAGS@ -version-info 0:1:0 -no-undefined -avoid-version
--- a/src/plugins/contrib/wxSmith/wxwidgets/Makefile.am
+++ b/src/plugins/contrib/wxSmith/wxwidgets/Makefile.am
@@ -5,6 +5,10 @@ AM_CPPFLAGS = $(WX_CXXFLAGS) \
-I$(top_srcdir)/src/include \
-I$(top_srcdir)/src/sdk/wxscintilla/include
+if CODEBLOCKS_NT
+AM_CPPFLAGS += -DEXPORT_LIB
+endif
+
noinst_LTLIBRARIES = libwxsmith_wxwidgets.la
libwxsmith_wxwidgets_la_LDFLAGS = @MODULE_SHARED_LDFLAGS@ -version-info 0:1:0 -no-undefined -avoid-version
--- a/src/plugins/contrib/wxSmith/wxwidgets/properties/Makefile.am
+++ b/src/plugins/contrib/wxSmith/wxwidgets/properties/Makefile.am
@@ -2,6 +2,10 @@ AM_CPPFLAGS = $(WX_CXXFLAGS) \
-I$(top_srcdir)/src/include \
-I$(top_srcdir)/src/sdk/wxscintilla/include
+if CODEBLOCKS_NT
+AM_CPPFLAGS += -DEXPORT_LIB
+endif
+
noinst_LTLIBRARIES = libwxsmith_wxwidgets_properties.la
libwxsmith_wxwidgets_properties_la_LDFLAGS = @MODULE_SHARED_LDFLAGS@ -version-info 0:1:0 -no-undefined -avoid-version
--
Hi, Tim, thanks.
I looked at your patches here: https://github.com/stahta01/MINGW-packages/tree/codeblocks-git/mingw-w64-codeblocks-git
Especially this one: https://github.com/stahta01/MINGW-packages/blob/codeblocks-git/mingw-w64-codeblocks-git/007-makefile-wxsmith-plugin-export-fix.patch
I see that you have added the "EXPORT_LIB" macro definition in the Makefile.am file in the compiler option.
I think defining this has the same effect as my change of the:
diff --git a/src/include/cbplugin.h b/src/include/cbplugin.h
index 10258e5..a3ce67b 100644
--- a/src/include/cbplugin.h
+++ b/src/include/cbplugin.h
@@ -23,11 +23,11 @@
#ifdef EXPORT_LIB
#define PLUGIN_EXPORT __declspec (dllexport)
#else // !EXPORT_LIB
- #ifdef BUILDING_PLUGIN
+ #if defined(BUILDING_PLUGIN) || defined(DLL_EXPORT)
#define PLUGIN_EXPORT __declspec (dllexport)
- #else // !BUILDING_PLUGIN
+ #else // !BUILDING_PLUGIN && !DLL_EXPORT
#define PLUGIN_EXPORT __declspec (dllimport)
- #endif // BUILDING_PLUGIN
+ #endif // BUILDING_PLUGIN || DLL_EXPORT
#endif // EXPORT_LIB
#endif // PLUGIN_EXPORT
#else
Because defining such macro will make the "#define PLUGIN_EXPORT __declspec (dllexport)" take effect.
But, when I search the build log(the build log I have days ago) of the configure/make result. I see that when we build plugins, we don't have such "EXPORT_LIB" defined in many plugins, for example, when build the codecompletion plugin or compiler plugin, I see the log code looks like below:
2024-09-24T11:47:33.4430652Z libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../src/include -ID:/msys64/mingw64/lib/wx/include/msw-unicode-3.2 -ID:/msys64/mingw64/include/wx-3.2 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMSW__ -I../../../src/include/scripting/include -I../../../src/include -I../../../src/sdk/wxscintilla/include -I../../../src/plugins/compilergcc/depslib/src -DDEPSLIB_WINDOWS -DCB_AUTOCONF -DPIC -O2 -ffast-math -fPIC -fexceptions -MT compilermessages.lo -MD -MP -MF .deps/compilermessages.Tpo -c compilermessages.cpp -DDLL_EXPORT -DPIC -o .libs/compilermessages.o
or
2024-09-24T12:28:29.7971808Z libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../../src/include -ID:/msys64/mingw64/lib/wx/include/msw-unicode-3.2 -ID:/msys64/mingw64/include/wx-3.2 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMSW__ -I../../../../src/include -I../../../../src/sdk/wxscintilla/include -I../../../../src/include/tinyxml -I./src -I./src/LSPclient -I./src/codecompletion -I./src/winprocess -I./src/winprocess/asyncprocess -I./src/winprocess/misc -DCB_AUTOCONF -DPIC -O2 -ffast-math -fPIC -fexceptions -MT src/codecompletion/parser/parser.lo -MD -MP -MF src/codecompletion/parser/.deps/parser.Tpo -c src/codecompletion/parser/parser.cpp -DDLL_EXPORT -DPIC -o src/codecompletion/parser/.libs/parser.o
You see, the "-DDLL_EXPORT -DPIC" is always defined. When I looked at the Makefile.am for those plugins, I don't see they defined the EXPORT_LIB.
So, I'm not sure why those plugins can be built with out issue.
But when I looked at the cbp files for those plugins, I see "BUILDING_PLUGIN" is always defined in the cbp, from the cbplugin.h, I see that "BUILDING_PLUGIN" means "#define PLUGIN_EXPORT __declspec (dllexport)".
So, my question is: shall we enable all "__declspec (dllexport)" if I see the "-DDLL_EXPORT"? It looks like "DLL_EXPORT" comes from the configure/auto-make world, but I can't find its source.
Thanks.
I searched all the usage of PLUGIN_EXPORT in our source code base, and I see the only usage of the PLUGIN_EXPORT is in the wxSmith, such as:
"class PLUGIN_EXPORT wxsAdvQPP : public wxsQuickPropsPanel"
Basically, I think the other plugin just export all the symbols of the classes and functions. While, for wxsmith, only a limited symbols will be exported (because we can only exported the symbols with "__declspec (dllexport)").
So, when you define the "EXPORT_LIB", you add the "__declspec (dllexport)" to that symbol.
But export all the symbols of the whole dll is not a good idea, because not every symbol should be exported, and the total symbols resolution take extra time for the dll loader.
If I remember correctly, under wxWidgets, the dll only export a limited number of symbols, and it also reduce the dll size.
I have applied Tim's all patches in my git repo: https://github.com/asmwarrior/codeblocks_sfmirror
and when building the C::B, it looks OK.
But when I run the "mv" command, it failed in this line:
./bootstrap
./configure --disable-pch --with-contrib-plugins=all,-Valgrind --prefix=/opt/codeblocks
make -j$(nproc) install
mv /opt/codeblocks/lib/codeblocks/bin/*.dll /opt/codeblocks/bin/
mv /opt/codeblocks/lib/*.dll /opt/codeblocks/bin/
2024-09-26T12:43:53.9461424Z + mv /opt/codeblocks/lib/codeblocks/bin/libwxchartctrl-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxcustombutton-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxflatnotebook-0.dll /opt/codeblocks/lib/codeblocks/bin/libwximagepanel-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxkwic-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxled-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxmathplot-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxspeedbutton-0.dll /opt/codeblocks/bin/
2024-09-26T12:43:53.9636034Z + mv '/opt/codeblocks/lib/*.dll' /opt/codeblocks/bin/
2024-09-26T12:43:53.9781662Z mv: cannot stat '/opt/codeblocks/lib/*.dll': No such file or directory
2024-09-26T12:43:53.9845301Z ##[error]Process completed with exit code 1.
It looks like there is no file: /opt/codeblocks/lib/*.dll
@Grit Clef
Maybe, this mv line should be removed?
Quote from: ollydbg on September 26, 2024, 03:18:53 PM
I have applied Tim's all patches in my git repo: https://github.com/asmwarrior/codeblocks_sfmirror
and when building the C::B, it looks OK.
But when I run the "mv" command, it failed in this line:
./bootstrap
./configure --disable-pch --with-contrib-plugins=all,-Valgrind --prefix=/opt/codeblocks
make -j$(nproc) install
mv /opt/codeblocks/lib/codeblocks/bin/*.dll /opt/codeblocks/bin/
mv /opt/codeblocks/lib/*.dll /opt/codeblocks/bin/
2024-09-26T12:43:53.9461424Z + mv /opt/codeblocks/lib/codeblocks/bin/libwxchartctrl-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxcustombutton-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxflatnotebook-0.dll /opt/codeblocks/lib/codeblocks/bin/libwximagepanel-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxkwic-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxled-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxmathplot-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxspeedbutton-0.dll /opt/codeblocks/bin/
2024-09-26T12:43:53.9636034Z + mv '/opt/codeblocks/lib/*.dll' /opt/codeblocks/bin/
2024-09-26T12:43:53.9781662Z mv: cannot stat '/opt/codeblocks/lib/*.dll': No such file or directory
2024-09-26T12:43:53.9845301Z ##[error]Process completed with exit code 1.
It looks like there is no file: /opt/codeblocks/lib/*.dll
@Grit Clef
Maybe, this mv line should be removed?
I think you likely had an wxContribItems build error because memory says that is what plugin has dlls in that place.
Edit: Looks like your dlls went to a different place; so, removing it should be okay. Unless that is the location for the wxsmith dll.
Edit2: Find where the "libwxsmithlib.dll" is located because I think it should be in that location.
Tim S.
Quote from: stahta01 on September 26, 2024, 04:39:46 PM
Quote from: ollydbg on September 26, 2024, 03:18:53 PM
I have applied Tim's all patches in my git repo: https://github.com/asmwarrior/codeblocks_sfmirror
and when building the C::B, it looks OK.
But when I run the "mv" command, it failed in this line:
./bootstrap
./configure --disable-pch --with-contrib-plugins=all,-Valgrind --prefix=/opt/codeblocks
make -j$(nproc) install
mv /opt/codeblocks/lib/codeblocks/bin/*.dll /opt/codeblocks/bin/
mv /opt/codeblocks/lib/*.dll /opt/codeblocks/bin/
2024-09-26T12:43:53.9461424Z + mv /opt/codeblocks/lib/codeblocks/bin/libwxchartctrl-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxcustombutton-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxflatnotebook-0.dll /opt/codeblocks/lib/codeblocks/bin/libwximagepanel-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxkwic-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxled-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxmathplot-0.dll /opt/codeblocks/lib/codeblocks/bin/libwxspeedbutton-0.dll /opt/codeblocks/bin/
2024-09-26T12:43:53.9636034Z + mv '/opt/codeblocks/lib/*.dll' /opt/codeblocks/bin/
2024-09-26T12:43:53.9781662Z mv: cannot stat '/opt/codeblocks/lib/*.dll': No such file or directory
2024-09-26T12:43:53.9845301Z ##[error]Process completed with exit code 1.
It looks like there is no file: /opt/codeblocks/lib/*.dll
@Grit Clef
Maybe, this mv line should be removed?
I think you likely had an wxContribItems build error because memory says that is what plugin has dlls in that place.
Edit: Looks like your dlls went to a different place; so, removing it should be okay. Unless that is the location for the wxsmith dll.
Edit2: Find where the "libwxsmithlib.dll" is located because I think it should be in that location.
Tim S.
Thanks.
I see the "libwxsmithlib.dll" (actually the name is libwxsmithlib-0.dll) is not in the lib folder, but in the bin folder, see the log below:
Line 8135: 2024-09-26T12:40:09.5700956Z libtool: install: /usr/bin/install -c .libs/libwxsmithlib-0.dll /opt/codeblocks/lib/../bin/libwxsmithlib-0.dllSo, I just comment out the second "mv" command, and run the github action again.
BTW:
QuoteI think you likely had an wxContribItems build error because memory says that is what plugin has dlls in that place.
I don't think there is a build error. :)
EDIT:It looks like removing the second "mv" command solved the github action failure.
Quote from: ollydbg on September 25, 2024, 04:12:44 AM
Well, I see your patch's content is too large, and I apply it locally, and I see only two line changes:
see below:
diff --git a/src/plugins/contrib/wxSmith/Makefile.am b/src/plugins/contrib/wxSmith/Makefile.am
index 38262bf..dfe9df2 100644
--- a/src/plugins/contrib/wxSmith/Makefile.am
+++ b/src/plugins/contrib/wxSmith/Makefile.am
@@ -7,7 +7,7 @@ AM_CPPFLAGS = $(WX_CXXFLAGS) \
lib_LTLIBRARIES = libwxsmithlib.la
-libwxsmithlib_la_LDFLAGS = -version-info 0:1:0 -shared
+libwxsmithlib_la_LDFLAGS = @MODULE_SHARED_LDFLAGS@ -version-info 0:1:0 -no-undefined -avoid-version
libwxsmithlib_la_LIBADD = ../../../sdk/libcodeblocks.la \
properties/libwxsmith_properties.la \
I think this is exactly the patch file in msys2 here:
https://github.com/msys2/MINGW-packages/blob/f47229e160e1f31f24fdc6142be7b4df99b1a4c3/mingw-w64-codeblocks/001-makefile-wxsmith-add-no-undefined.patch
Another change line is here:
diff --git a/src/src/Makefile.am b/src/src/Makefile.am
index 49d5dd9..d59889b 100644
--- a/src/src/Makefile.am
+++ b/src/src/Makefile.am
@@ -75,7 +75,7 @@ codeblocks_LDADD += resources.$(OBJEXT) -lexchndl -lcomctl32
codeblocks_DEPENDENCIES = resources.$(OBJEXT)
codeblocks_SOURCES += associations.cpp
resources.$(OBJEXT): resources/resources.rc resources/amd64_dpi_aware_on.manifest
- $(WINDRES) $(WX_CXXFLAGS) -DcbDPI_AWARE_ON --include-dir $(top_srcdir)/src $< $@
+ $(WINDRES) $(WX_CPPFLAGS) -DcbDPI_AWARE_ON --include-dir $(top_srcdir)/src $< $@
endif
noinst_HEADERS = app.h \
This is the command line option you changed for compiling the resource rc file. I don't see a similar patch in msys2's codeblocks folder:
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-codeblocks
Another patch I see is here:
https://github.com/msys2/MINGW-packages/blob/f47229e160e1f31f24fdc6142be7b4df99b1a4c3/mingw-w64-codeblocks/005-codeblocks-plugin-fix.patch
--- a/src/sdk/configmanager.cpp (revision 13538)
+++ b/src/sdk/configmanager.cpp (working copy)
@@ -1497,7 +1497,7 @@
if (plugin_path_global.IsEmpty())
{
if (platform::windows)
- ConfigManager::plugin_path_global = app_path + _T("/../lib/codeblocks/plugins");
+ ConfigManager::plugin_path_global = app_path + _T("\\..\\lib\\codeblocks\\plugins");
else if (platform::macosx)
ConfigManager::plugin_path_global = data_path_global + _T("/plugins");
else
@Tim, can you say something about this code change? If we don't change this, what will happen? I don't see this code change in my github action's code.
Thanks.
The patch is intended to solve some problems on building, especially when building a 32bit codeblocks. I have tried those patches, like those in msys2, but git always gives me an error. So, I added the all-in-one patch to my repository.
Quote from: ollydbg on September 24, 2024, 04:54:24 PM
Quote from: Grit Clef on September 24, 2024, 04:39:28 PM
Oh, when I tried your command:
The result is, first 13571 came out and then an error:
Error: Process completed with exit code 141.
The method already works in my fork, see here:
my fork's main branch (https://github.com/asmwarrior/x86-codeblocks-builds/tree/main)
Oh, the command worked, thanks.
Quote from: Grit Clef on September 28, 2024, 07:15:52 AM
Quote from: ollydbg on September 24, 2024, 04:54:24 PM
Quote from: Grit Clef on September 24, 2024, 04:39:28 PM
Oh, when I tried your command:
The result is, first 13571 came out and then an error:
Error: Process completed with exit code 141.
The method already works in my fork, see here:
my fork's main branch (https://github.com/asmwarrior/x86-codeblocks-builds/tree/main)
Oh, the command worked, thanks.
I see your github action failed:
https://github.com/zxunge/x86-codeblocks-builds/actions/runs/11081484299/job/30793287105
+ mv '/opt/codeblocks/lib/*.dll' /opt/codeblocks/bin/
mv: cannot stat '/opt/codeblocks/lib/*.dll': No such file or directoryYou should comment out this line. I have comment out already, and should solved this issue.
I'm going to commit some the patches I used(mainly from Tim) to support building C::B release under github action.
I'm thinking some new idea:
We have a lot of third part plugin development in github, and maybe we can enough them to build those plugins under github action, and in our C::B, we may need to find a simple way to install/update the plugin.
Any comments?
I don't think the plugin developer need to build the whole C::B again, maybe they can just download/copy some prebuild C::B release from other code repo, and build there own plugin release.
Quote from: ollydbg on September 30, 2024, 05:43:45 AM
I'm going to commit some the patches I used(mainly from Tim) to support building C::B release under github action.
I'm thinking some new idea:
We have a lot of third part plugin development in github, and maybe we can enough them to build those plugins under github action, and in our C::B, we may need to find a simple way to install/update the plugin.
Any comments?
I don't think the plugin developer need to build the whole C::B again, maybe they can just download/copy some prebuild C::B release from other code repo, and build there own plugin release.
Please submit the update of "ax_cxx_compile_stdcxx.m4" because it likely needs done for more than Msys2 mingw building.
I am just too tired to try submitting any more patches; since, I see little gain from the effort.
Tim S.
Quote from: stahta01 on September 30, 2024, 05:59:12 AM
Quote from: ollydbg on September 30, 2024, 05:43:45 AM
I'm going to commit some the patches I used(mainly from Tim) to support building C::B release under github action.
I'm thinking some new idea:
We have a lot of third part plugin development in github, and maybe we can enough them to build those plugins under github action, and in our C::B, we may need to find a simple way to install/update the plugin.
Any comments?
I don't think the plugin developer need to build the whole C::B again, maybe they can just download/copy some prebuild C::B release from other code repo, and build there own plugin release.
Please submit the update of "ax_cxx_compile_stdcxx.m4" because it likely needs done for more than Msys2 mingw building.
I am just too tired to try submitting any more patches; since, I see little gain from the effort.
Tim S.
Hi, Tim, all your patches for the github action build under msys2/shell/configure/make methods were commited to svn now, many thanks for your contribution.
QuoteI see little gain from the effort.
Your contribution is so important for C::B, so it has great gain for C::B. :)
EDIT:I'd like to thank other guys like:
Carsten Arnholm(I forgot his nick name in our forum, sorry) create this git repo, https://github.com/arnholm/codeblocks_sfmirror
Grit Clef: create the github action to create C::B, https://github.com/zxunge/x86-codeblocks-builds
Great. Now the build process of CB would be more easier.
Do these changes fix this ticket (https://sourceforge.net/p/codeblocks/tickets/1199/)?
Quote from: Miguel Gimenez on September 30, 2024, 06:44:53 PM
Do these changes fix this ticket (https://sourceforge.net/p/codeblocks/tickets/1199/)?
A quick scan of that ticket shows that these patch, yet to be applied to codeblocks SVN, fixes the issue in a different way that was only tested using the MSys2 MinGW GCC toolchain. My patches did nothing on how the codeblocks installation went; but, patches other than mine was used. The ticket implied the installation was changed; I did not examine the patch files myself.
Since, the two recent patches I submitted went no where; I do not plan to submit any more to codeblocks patch system. I posted the very important one in the nightly build. I figure I will wait on the others till I see movement or after the next release. After the release, maybe they will start taking patches and applying them in a faster time frame.
Edit: That ticket appears to have aged poorly and I suggest closing it because of age. The git repo linked no longer exists.
Edit2: It looks like he used my many year old changes and edited them and some of those edit made it into Code::Blocks SVN and he gave up doing more work because of how long it took. I can relate. So, I think closing that ticket would be the correct thing to do.
Tim S.
Quote from: stahta01 on September 30, 2024, 08:54:57 PM
Since, the two recent patches I submitted went no where; I do not plan to submit any more to codeblocks patch system. I posted the very important one in the nightly build. I figure I will wait on the others till I see movement or after the next release. After the release, maybe they will start taking patches and applying them in a faster time frame.
Which ones? This one: Re: The 25 September 2024 build (13571) is out. (https://forums.next.codeblocks.org/index.php/topic,25880.msg176260.html#msg176260)?
I see your mentioned patches were in svn repo now.
Quote from: stahta01 on September 30, 2024, 08:54:57 PM
Edit: That ticket appears to have aged poorly and I suggest closing it because of age. The git repo linked no longer exists.
Edit2: It looks like he used my many year old changes and edited them and some of those edit made it into Code::Blocks SVN and he gave up doing more work because of how long it took. I can relate. So, I think closing that ticket would be the correct thing to do.
Thank you, I have just closed it.
Quote from: ollydbg on October 01, 2024, 06:08:32 AM
Quote from: stahta01 on September 30, 2024, 08:54:57 PM
Since, the two recent patches I submitted went no where; I do not plan to submit any more to codeblocks patch system. I posted the very important one in the nightly build. I figure I will wait on the others till I see movement or after the next release. After the release, maybe they will start taking patches and applying them in a faster time frame.
Which ones? This one: Re: The 25 September 2024 build (13571) is out. (https://forums.next.codeblocks.org/index.php/topic,25880.msg176260.html#msg176260)?
I see your mentioned patches were in svn repo now.
Wow, the patches are now being applied in the last 24 hours.
Thanks for the work. Looks like movement is happening.
Edit: It looks like all the patches have made it to SVN.
Edit2: I am now going to look at scripted wizard changes for MSys2 MinGW GCC changes; those are not important enough that moving to SVN is needed and can just be copied to folder till they get approved by people who are using them.
Tim S.
Quote from: stahta01 on October 01, 2024, 02:10:48 PM
Edit2: I am now going to look at scripted wizard changes for MSys2 MinGW GCC changes; those are not important enough that moving to SVN is needed and can just be copied to folder till they get approved by people who are using them.
Tim S.
I have 2 patches in my fork, one for wx, the other is for opencv.
Most of the libraries can be used by the pkg-config command in compiler or linker opinion.
Quote from: ollydbg on October 01, 2024, 05:04:44 PM
Quote from: stahta01 on October 01, 2024, 02:10:48 PM
Edit2: I am now going to look at scripted wizard changes for MSys2 MinGW GCC changes; those are not important enough that moving to SVN is needed and can just be copied to folder till they get approved by people who are using them.
Tim S.
I have 2 patches in my fork, one for wx, the other is for opencv.
Most of the libraries can be used by the pkg-config command in compiler or linker opinion.
I added your changes to my repo I will ignore those for now.
Tim S.
Quote from: stahta01 on October 01, 2024, 08:33:44 PM
Quote from: ollydbg on October 01, 2024, 05:04:44 PM
Quote from: stahta01 on October 01, 2024, 02:10:48 PM
Edit2: I am now going to look at scripted wizard changes for MSys2 MinGW GCC changes; those are not important enough that moving to SVN is needed and can just be copied to folder till they get approved by people who are using them.
Tim S.
I have 2 patches in my fork, one for wx, the other is for opencv.
Most of the libraries can be used by the pkg-config command in compiler or linker opinion.
I added your changes to my repo I will ignore those for now.
Tim S.
Fill free to modify my two patches about wx and opencv demo, I don't think they are very good, I think it is my hack to the wizard script code.
great :D
Good news: I had just forgotten to use some shell commands to change the Makefile so that it can work under MSYS2 zip. The following commands can change all back-slashes to forward-slashes and do other necessary modification:
sed '/zip -jq9*/ s/\\/\//g' Makefile_core -i
sed -i '85 s/LIB_SDK = $(LIB) -lshfolder -ltxml -lwxscintilla_cb -lsquirrel -lgdi32/LIB_SDK = -lshfolder -ltxml -lwxscintilla_cb $(LIB) -lsquirrel -lgdi32/' Makefile_core
sed 's/$(DEP_.*//g' Makefile_core -i
A successful action can be found at https://github.com/zxunge/winstyle-codeblocks-bins/actions/runs/11192814700
So now maybe we can use a automatical winstyle build.
I'm now wondering if cbp2make can convert .workspace files.
Quote from: Grit Clef on October 06, 2024, 05:22:58 AM
Good news: I had just forgotten to use some shell commands to change the Makefile so that it can work under MSYS2 zip. The following commands can change all back-slashes to forward-slashes and do other necessary modification:
sed '/zip -jq9*/ s/\\/\//g' Makefile_core -i
sed -i '85 s/LIB_SDK = $(LIB) -lshfolder -ltxml -lwxscintilla_cb -lsquirrel -lgdi32/LIB_SDK = -lshfolder -ltxml -lwxscintilla_cb $(LIB) -lsquirrel -lgdi32/' Makefile_core
sed 's/$(DEP_.*//g' Makefile_core -i
A successful action can be found at https://github.com/zxunge/winstyle-codeblocks-bins/actions/runs/11192814700
So now maybe we can use a automatical winstyle build.
I'm now wondering if cbp2make can convert .workspace files.
Very nice work!
I looked at the file:
https://github.com/zxunge/winstyle-codeblocks-bins/blob/main/.github/workflows/main.yml
and you just download all the wx header files and compilers used by nightly build?
If you looked at the
https://github.com/mirai-computing/cbp2make
You see that cbp2make also works for workspaces files.
I see, Thank you. Trying.
FortranProject build failed:
g++.exe -Wall -std=gnu++11 -pipe -mthreads -fmessage-length=0 -fexceptions -DBUILDING_PLUGIN -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DNOPCH -DwxUSE_UNICODE -I..\..\..\include -I..\..\..\include\tinyxml -I..\..\..\sdk\wxscintilla\include -ID:/msys64/opt/wxwidgets3.2/include -ID:/msys64/opt/wxwidgets3.2/lib\gcc_dll\msw -c projectdependencies.cpp -o ..\\..\\..\\.objs32\\plugins\\contrib\\FortranProject\\projectdependencies.o
In file included from D:/msys64/opt/wxwidgets3.2/include/wx/defs.h:45,
from D:/msys64/opt/wxwidgets3.2/include/wx/wxprec.h:12,
from ..\..\..\include/sdk_common.h:24,
from ..\..\..\include/sdk.h:14,
from projectdependencies.h:13,
from projectdependencies.cpp:10:
D:/msys64/opt/wxwidgets3.2/include/wx/platform.h:159:10: fatal error: wx/setup.h: No such file or directory
159 | #include "wx/setup.h"
| ^~~~~~~~~~~~
compilation terminated.
mingw32-make[1]: ***
I think it's because
-ID:/msys64/opt/wxwidgets3.2/lib\gcc_dll\msw
Why there's no 'u' after 'gcc_dll\msw'??
Maybe, you can exclude this plugin first from workspace.
If I remember correctly, this plugin's souce code is not in our svn.
Ask this plugin's author for some help. :)
OK. Thank you.
latest one seems to build no problem in msys2 :D even the 32 bit version works.
Quote from: reckless on October 09, 2024, 12:24:46 PM
latest one seems to build no problem in msys2 :D even the 32 bit version works.
msys2 added the FORTRAN plugin [as a separate package], also.
Tim S.
aye just built it 8) so far all seems in order.
Quote from: reckless on October 10, 2024, 12:02:09 AM
aye just built it 8) so far all seems in order.
Which method did you use?
The configure/make or cb2make.
Quote from: ollydbg on October 10, 2024, 12:45:31 AM
Quote from: reckless on October 10, 2024, 12:02:09 AM
aye just built it 8) so far all seems in order.
Which method did you use?
The configure/make or cb2make.
He likely talking about this https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-codeblocks-fortranproject (https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-codeblocks-fortranproject)
And, he likely built it the standard MSys2 Mingw package way.
Tim S.
cmd /c if not exist ..\..\..\devel32\share\codeblocks\plugins mkdir ..\..\..\devel32\share\codeblocks\plugins
cmd /c if exist ./clangd_client.zip del ./clangd_client.zip
zip -jq9 ./clangd_client.zip src/resources/manifest.xml src/resources/*.xrc src/resources/*.cbp
cmd /c "cd src/resources && zip -rq9 ../../clangd_client.zip images && cd ../.."
'esources' is not recognized as an internal or external command,
operable program or batch file.
mingw32-make[1]: *** [clangd_client_wx32.cbp.mak:62: after_default] Error 1
mingw32-make[1]: Leaving directory 'D:/a/winstyle-codeblocks-bins/winstyle-codeblocks-bins/codeblocks_sfmirror/src/plugins/contrib/clangd_client'
mingw32-make: *** [Makefile_plugins:56: plugins_contrib_clangd_client_clangd_client_wx32] Error 2
Error: Process completed with exit code 2.
I see this: main32 zxunge/winstyle-codeblocks-bins@e9dcd79 (https://github.com/zxunge/winstyle-codeblocks-bins/actions/runs/11318289074/job/31472698422#step:4:2488)
It looks like the batch command line error when building clangd_client plugin.
Now it might work; my hope.
Can this build bot work outside of GitHub (e.g. Gitea Runner, Woodpecker CI)?
Quote from: Grit Clef on October 16, 2024, 06:19:43 AM
Now it might work; my hope.
In the latest error message from github action, I see this:
g++.exe -std=gnu++11 -pipe -mthreads -fmessage-length=0 -fexceptions -DBUILDING_PLUGIN -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DNOPCH -DwxUSE_UNICODE -DBOOST_SYSTEM_NO_DEPRECATED -I..\..\..\include -I..\..\..\include\tinyxml -I..\..\..\sdk\wxscintilla\include -ID:/msys64/opt/wxwidgets3.2/include -ID:/msys64/opt/wxwidgets3.2/lib\gcc_dll\mswu -ID:/msys64/opt/boost_1_86_0/boost -c CParser.cpp -o ..\\..\\..\\.objs32\\plugins\\contrib\\NassiShneiderman\\CParser.o
CParser.cpp:5:10: fatal error: boost/spirit/include/classic.hpp: No such file or directory
5 | #include <boost/spirit/include/classic.hpp>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
mingw32-make[1]: *** [NassiShneiderman_wx32.cbp.mak:108: ..\\..\\..\\.objs32\\plugins\\contrib\\NassiShneiderman\\CParser.o] Error 1
mingw32-make[1]: Leaving directory 'D:/a/winstyle-codeblocks-bins/winstyle-codeblocks-bins/codeblocks_sfmirror/src/plugins/contrib/NassiShneiderman'
mingw32-make: *** [Makefile_plugins:40: plugins_contrib_nassishneiderman_nassishneiderman_wx32] Error 2
Error: Process completed with exit code 2.You have already installed the header files from the boost library?
Maybe you need to tweak the compiler search paths of the boost, as I can see that this search path is already included.
D:/msys64/opt/boost_1_86_0/So, do you have a folder named below?
D:/msys64/opt/boost_1_86_0/boost/spirit/include/classic.hppMaybe, as a workaround, you can exclude this plugin from the workspace to makefile generation.
Quote from: Михаил Агарков on October 16, 2024, 11:27:22 PM
Can this build bot work outside of GitHub (e.g. Gitea Runner, Woodpecker CI)?
Do you know if those CI systems support running msys2 environment, I think they can be used if msys2 is supported.
Quote from: ollydbg on October 17, 2024, 12:45:45 AM
Quote from: Grit Clef on October 16, 2024, 06:19:43 AM
Now it might work; my hope.
In the latest error message from github action, I see this:
g++.exe -std=gnu++11 -pipe -mthreads -fmessage-length=0 -fexceptions -DBUILDING_PLUGIN -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DNOPCH -DwxUSE_UNICODE -DBOOST_SYSTEM_NO_DEPRECATED -I..\..\..\include -I..\..\..\include\tinyxml -I..\..\..\sdk\wxscintilla\include -ID:/msys64/opt/wxwidgets3.2/include -ID:/msys64/opt/wxwidgets3.2/lib\gcc_dll\mswu -ID:/msys64/opt/boost_1_86_0/boost -c CParser.cpp -o ..\\..\\..\\.objs32\\plugins\\contrib\\NassiShneiderman\\CParser.o
CParser.cpp:5:10: fatal error: boost/spirit/include/classic.hpp: No such file or directory
5 | #include <boost/spirit/include/classic.hpp>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
mingw32-make[1]: *** [NassiShneiderman_wx32.cbp.mak:108: ..\\..\\..\\.objs32\\plugins\\contrib\\NassiShneiderman\\CParser.o] Error 1
mingw32-make[1]: Leaving directory 'D:/a/winstyle-codeblocks-bins/winstyle-codeblocks-bins/codeblocks_sfmirror/src/plugins/contrib/NassiShneiderman'
mingw32-make: *** [Makefile_plugins:40: plugins_contrib_nassishneiderman_nassishneiderman_wx32] Error 2
Error: Process completed with exit code 2.
You have already installed the header files from the boost library?
Maybe you need to tweak the compiler search paths of the boost, as I can see that this search path is already included.
D:/msys64/opt/boost_1_86_0/
So, do you have a folder named below?
D:/msys64/opt/boost_1_86_0/boost/spirit/include/classic.hpp
Maybe, as a workaround, you can exclude this plugin from the workspace to makefile generation.
That might be a further problem; now the cland_client still can't be built.
cmd /c "cd src\resources && zip -rq9 ..\..\clangd_client.zip images && cd ..\.."
Microsoft Windows [Version 10.0.20348.2700]
(c) Microsoft Corporation. All rights reserved.
D:\a\winstyle-codeblocks-bins\winstyle-codeblocks-bins\codeblocks_sfmirror\src\plugins\contrib\clangd_client>cmd /c copy ./clangd_client.zip ../../../devel32/share/CodeBlocks/clangd_client.zip
The syntax of the command is incorrect.
mingw32-make[1]: *** [clangd_client_wx32.cbp.mak:63: after_default] Error 1
I found that if you call cmd.exe inside MSYS2, there will be a strange problem; in some cases there're no errors, though. I'm not clear what made that.
I think you can run the mingw32-make.exe inside the cmd.exe shell, not the msys2's shell.
I made a repo in codeberg to test if the build bot can work in Woodpecker CI, just need to wait for the repo to get approved to use actions.
https://codeberg.org/MichaelAgarkov/x86-codeblocks-builds
Edit: removed the repo because they didn't respond, if it works on GitHub then it probably will work in any GitHub Actions' compatible CI/CD.
Quote from: Михаил Агарков on October 19, 2024, 09:55:36 AM
I made a repo in codeberg to test if the build bot can work in Woodpecker CI, just need to wait for the repo to get approved to use actions.
https://codeberg.org/MichaelAgarkov/x86-codeblocks-builds
Good work.
Why the repo should "get approved" to use the actions? :)
Quote from: ollydbg on October 19, 2024, 10:21:06 AM
Quote from: Михаил Агарков on October 19, 2024, 09:55:36 AM
I made a repo in codeberg to test if the build bot can work in Woodpecker CI, just need to wait for the repo to get approved to use actions.
https://codeberg.org/MichaelAgarkov/x86-codeblocks-builds
Good work.
Why the repo should "get approved" to use the actions? :)
https://docs.codeberg.org/ci/#using-codeberg's-instance-of-woodpecker-ci
Uhh, you might have used the wrong repository. It is https://github.com/zxunge/winstyle-codeblocks-bins , not the original x86-codeblocks-bins which is successful.
The fact is, those Makefiles generated by cbp2make are not so perfect that there are lots of bugs in build process. Many plugins can't be built owing to this or that reasons.
One problem I see often is like
...........
xcopy /Y index.ini ..\..\..\output32\share\CodeBlocks\docs
D:index.ini
1 File(s) copied
g++.exe -Wl,--enable-auto-image-base -Wl,--add-stdcall-alias -Wl,--enable-auto-import help_plugin.cpp before_help_plugin out_help_plugin after_help_plugin -o help_plugin
help_plugin.cpp:10:10: fatal error: sdk.h: No such file or directory
10 | #include "sdk.h"
| ^~~~~~~
compilation terminated.
mingw32-make[1]: *** [<builtin>: help_plugin] Error 1
mingw32-make[1]: Leaving directory 'D:/a/winstyle-codeblocks-bins/winstyle-codeblocks-bins/codeblocks_sfmirror/src/plugins/contrib/help_plugin'
mingw32-make: *** [Makefile_plugins:25: plugins_contrib_help_plugin_help_plugin_wx32] Error 2
............
The build commands were polluted, due to unknown reasons. The plugin had been already built, but the linking command was executed again, which was wrong.
Quote from: Grit Clef on October 19, 2024, 12:32:53 PM
The fact is, those Makefiles generated by cbp2make are not so perfect that there are lots of bugs in build process. Many plugins can't be built owing to this or that reasons.
One problem I see often is like
...........
xcopy /Y index.ini ..\..\..\output32\share\CodeBlocks\docs
D:index.ini
1 File(s) copied
g++.exe -Wl,--enable-auto-image-base -Wl,--add-stdcall-alias -Wl,--enable-auto-import help_plugin.cpp before_help_plugin out_help_plugin after_help_plugin -o help_plugin
help_plugin.cpp:10:10: fatal error: sdk.h: No such file or directory
10 | #include "sdk.h"
| ^~~~~~~
compilation terminated.
mingw32-make[1]: *** [<builtin>: help_plugin] Error 1
mingw32-make[1]: Leaving directory 'D:/a/winstyle-codeblocks-bins/winstyle-codeblocks-bins/codeblocks_sfmirror/src/plugins/contrib/help_plugin'
mingw32-make: *** [Makefile_plugins:25: plugins_contrib_help_plugin_help_plugin_wx32] Error 2
............
The build commands were polluted, due to unknown reasons. The plugin had been already built, but the linking command was executed again, which was wrong.
Maybe you can show us the generated makefile? So that the cb2make author or other devs can help on this.
Hey, does anyone know what packages to install to obtain TeX?
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
error: Problems running epstopdf. Check your TeX installation!
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
error: Problems running epstopdf. Check your TeX installation!
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
error: Problems running epstopdf. Check your TeX installation!
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
Quote from: Grit Clef on October 19, 2024, 12:48:46 PM
Hey, does anyone know what packages to install to obtain TeX?
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
error: Problems running epstopdf. Check your TeX installation!
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
error: Problems running epstopdf. Check your TeX installation!
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
error: Problems running epstopdf. Check your TeX installation!
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
My guess under msys2, it is the texlive package.
Package: mingw-w64-x86_64-texlive-bin - MSYS2 Packages (https://packages.msys2.org/packages/mingw-w64-x86_64-texlive-bin)
But please note that this package(group of packages) are huge, I guess it should takes about 4G or 8G bytes size.
Makefile for help_plugin.
Another common problem is:
g++.exe -shared -L..\..\..\devel32 -LD:/msys64/opt/wxwidgets3.2/lib -LD:/msys64/opt/wxwidgets3.2/lib\gcc_dll ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\DoxyBlocksLogger.o ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\ExtractDocs.o ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\AutoDoc.o ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\DoxyBlocks.o
∧∧∧∧∧∧
..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\DoxyBlocks.o ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\ConfigPanel.o ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\Config.o -o ..\\..\\..\\devel32\\share\\CodeBlocks\\plugins\\DoxyBlocks.dll -Wl,--enable-auto-import -mthreads -lcodeblocks -lwxmsw32u
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: ..\..\..\.objs32\plugins\contrib\DoxyBlocks\DoxyBlocks.o:DoxyBlocks.cpp:(.text+0x0): multiple definition of `DoxyBlocks::GetEventTable() const'; ..\..\..\.objs32\plugins\contrib\DoxyBlocks\DoxyBlocks.o:DoxyBlocks.cpp:(.text+0x0): first defined here
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: ..\..\..\.objs32\plugins\contrib\DoxyBlocks\DoxyBlocks.o:DoxyBlocks.cpp:(.text+0x10): multiple definition of `DoxyBlocks::GetEventHashTable() const'; ..\..\..\.objs32\plugins\contrib\DoxyBlocks\DoxyBlocks.o:DoxyBlocks.cpp:(.text+0x10): first defined here
...........
There are multiple same object files provided.
Quote from: ollydbg on October 19, 2024, 12:56:19 PM
Quote from: Grit Clef on October 19, 2024, 12:48:46 PM
Hey, does anyone know what packages to install to obtain TeX?
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
error: Problems running epstopdf. Check your TeX installation!
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
error: Problems running epstopdf. Check your TeX installation!
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
error: Problems running epstopdf. Check your TeX installation!
'epstopdf' is not recognized as an internal or external command,
operable program or batch file.
My guess under msys2, it is the texlive package.
Package: mingw-w64-x86_64-texlive-bin - MSYS2 Packages (https://packages.msys2.org/packages/mingw-w64-x86_64-texlive-bin)
But please note that this package(group of packages) are huge, I guess it should takes about 4G or 8G bytes size.
No, there's no 'epstopdf' in those packages; but an 'epspdf'. However, doxygen needs 'epstopdf'.
$ pacman -Qo /mingw64/bin/repstopdf.exe
/mingw64/bin/repstopdf.exe is owned by mingw-w64-x86_64-texlive-core 2023.20230404-1
Some places use "repstopdf" instead of "epstopdf"
Edit: But, it did not work for me.
C:\msys64\mingw64\bin\runscript.tlu:922: C:\msys64\mingw64\bin\runscript.tlu:853: no appropriate script or program found
: epstopdf
${MINGW_PACKAGE_PREFIX}-ghostscript should have missing scripts.
But, I still could not find script
Tim S.
Quote from: Grit Clef on October 19, 2024, 01:29:10 PM
Another common problem is:
g++.exe -shared -L..\..\..\devel32 -LD:/msys64/opt/wxwidgets3.2/lib -LD:/msys64/opt/wxwidgets3.2/lib\gcc_dll ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\DoxyBlocksLogger.o ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\ExtractDocs.o ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\AutoDoc.o ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\DoxyBlocks.o
∧∧∧∧∧∧
..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\DoxyBlocks.o ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\ConfigPanel.o ..\\..\\..\\.objs32\\plugins\\contrib\\DoxyBlocks\\Config.o -o ..\\..\\..\\devel32\\share\\CodeBlocks\\plugins\\DoxyBlocks.dll -Wl,--enable-auto-import -mthreads -lcodeblocks -lwxmsw32u
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: ..\..\..\.objs32\plugins\contrib\DoxyBlocks\DoxyBlocks.o:DoxyBlocks.cpp:(.text+0x0): multiple definition of `DoxyBlocks::GetEventTable() const'; ..\..\..\.objs32\plugins\contrib\DoxyBlocks\DoxyBlocks.o:DoxyBlocks.cpp:(.text+0x0): first defined here
D:/msys64/opt/mingw32/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: ..\..\..\.objs32\plugins\contrib\DoxyBlocks\DoxyBlocks.o:DoxyBlocks.cpp:(.text+0x10): multiple definition of `DoxyBlocks::GetEventHashTable() const'; ..\..\..\.objs32\plugins\contrib\DoxyBlocks\DoxyBlocks.o:DoxyBlocks.cpp:(.text+0x10): first defined here
...........
There are multiple same object files provided.
You mean there are 2 "DoxyBlocks.o" in the build options when linking?
I think the cb2make plugin should have some ways to remove those duplicated linking objects.
Quote from: stahta01 on October 19, 2024, 04:50:14 PM
$ pacman -Qo /mingw64/bin/repstopdf.exe
/mingw64/bin/repstopdf.exe is owned by mingw-w64-x86_64-texlive-core 2023.20230404-1
Some places use "repstopdf" instead of "epstopdf"
Edit: But, it did not work for me.
C:\msys64\mingw64\bin\runscript.tlu:922: C:\msys64\mingw64\bin\runscript.tlu:853: no appropriate script or program found
: epstopdf
${MINGW_PACKAGE_PREFIX}-ghostscript should have missing scripts.
But, I still could not find script
Tim S.
Got it.
$ pacman -Qo /mingw64/bin/epstopdf.exe
/mingw64/bin/epstopdf.exe is owned by mingw-w64-x86_64-texlive-font-utils 2023.20230404-1
Now this works
$ epstopdf --version
epstopdf ($Id: epstopdf.pl 66407 2023-03-06 23:44:49Z karl $) 2.31
Copyright 2009-2023 Karl Berry et al.
Copyright 2002-2009 Gerben Wierda et al.
Copyright 1998-2001 Sebastian Rahtz et al.
License RBSD: Revised BSD <http://www.xfree86.org/3.3.6/COPYRIGHT2.html#5>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Tim S.
The first codeblocks build with partial plugins is out.
See https://github.com/zxunge/winstyle-codeblocks-bins/actions/runs/11418689815 .
Quote from: Grit Clef on October 19, 2024, 06:33:07 PM
The first codeblocks build with partial plugins is out.
See https://github.com/zxunge/winstyle-codeblocks-bins/actions/runs/11418689815 .
The latest one should be here: Update main.yml zxunge/winstyle-codeblocks-bins@c608334 (https://github.com/zxunge/winstyle-codeblocks-bins/actions/runs/11423555138)
There are two packages, which one is the final result zip file?
Why do you have a "update.exe" in your code repo?
codeblocks32_output.zip is the final; update.exe was converted from update.bat use an online tool, for use inside MSYS2 shell.(I first used winpty, but it just succeeded on my PC, failed on GitHub CI Server. So I tried that; although it was not perfect as the exe couldn't copy CbLauncher.exe to the output32 directory.)
CodeBlocks was built partially, but it can't be put in use. Assertion failed on startup.
Quote from: Grit Clef on October 24, 2024, 06:18:51 AM
CodeBlocks was built partially, but it can't be put in use. Assertion failed on startup.
You may start the C::B without any plugins to see whether it is caused by the host exe file, or by loading the plugins files.
It looks like some toolbar buttons images are not correctly copied?
No, it is not about plugins but codeblocks itself. Strange.
I got access to ci.codeberg.org, I will try to make the automated build system to work with Woodpecker CI.
https://codeberg.org/MichaelAgarkov/x86-codeblocks-builds