#1324 wxWidget wizard issues with Code::Blocks Release 20.03

[Axel MATTAUCH]

In Code::Blocks's Release 20.03 rev 11983 (2020-03-12 18:24:30), the wxWidget wizard don't work properly.

Attempting to use it to initate a wxSmith project, I identified three issues:

. The first and main issue is that linker settings generated by the wizard include the prefix an suffix in the filenames.
This is not compliant with the Code::Blocks documentation:

For a library called <path>\libs\lib<name>.a, just write <name>. The linker with the corresponding search paths will then include the libraries correctly.</name></name></path>

. Second issue: the wizard don't support the version 3.2.1 of wxWidget

. Third issue: the created folder structure don't follow strictly the naming rules applied to (recent?) wxWidget distributions. The wizard produces paths like <libpath>/lib/gcc_dll instead of <libpath>/lib/gcc810_x64_dll (as provided by simple dezip of the wxWidget distribution).</libpath></libpath>

The last issue is easily solved by proper renaming of the folder.
But for the first issues, it is necessary to modify the wizard code, or the wizard stay nearly useless.

---

I did some minor patches in the wizard, and now it seems to work as expected.

( Patched wizard as attachment)

A/ To resolve the first issue, I tried first
(1) to suppress the string completion by prefix and suffix like line 367+

    if (IsMonolithic)
    {
        lib_deb_name = _T("wxmsw") + LibWxVer + LibUnicSuffix + _T("d"); // instead of LibPrefix + _T("wxmsw") + LibWxVer + LibUnicSuffix + _T("d") + LibSuffix;
        lib_rel_name = _T("wxmsw") + LibWxVer + LibUnicSuffix;  // instead of LibPrefix + _T("wxmsw") + LibWxVer + LibUnicSuffix + LibSuffix;
    }

or (2) to desactivate prefix and suffix initialisation, like line 306+

    if (GetCompilerFactory().CompilerInheritsFrom(Wizard.GetCompilerID(), _T("gcc*")))
    {
        lib = lib + _T("gcc_");
        //  lib_prefix = _T("lib");
        //  lib_suffix = _T(".a");
    }

Both are solving the main issue, but at the expense of a remaining warning due to the string mismatch between the effective pathname and the lib_deb_name/lib_rel_name.

Thus (after trying more complex solutions) a smart solution arises from the conceptuel difference between the global variable LibPrefix (resp. LibSuffix ) and the local variable lib_prefix (resp. lib_suffix ):

. Line 361 & 364 the global variables remain empty:

    //    LibPrefix = lib_prefix; // Prefix of lib name
        LibWxVer <- lib_wxver; // Determines wx version
        LibUnicSuffix <- lib_unic_suffix; // Suffix for Unicode
    //    LibSuffix <- lib_suffix; // Suffix for Lib, defines file extension

. For the path comparison, lib_deb_name and lib_rel_name are generated with the local values of prefix/suffix instead of the global values (lines 369+):

    local lib_deb_name = _T("");
    local lib_rel_name = _T("");
    if (IsMonolithic)
    {
        lib_deb_name = lib_prefix + _T("wxmsw") + LibWxVer + LibUnicSuffix + _T("d") + lib_suffix;
        lib_rel_name = lib_prefix + _T("wxmsw") + LibWxVer + LibUnicSuffix + lib_suffix;
    }
    else /* Check for wxcore*/
    {
        lib_deb_name = lib_prefix + _T("wxbase") + LibWxVer + LibUnicSuffix + _T("d") + lib_suffix;
        lib_rel_name = lib_prefix + _T("wxbase") + LibWxVer + LibUnicSuffix + lib_suffix;
    }

---

B/ To resolve the second issue, the patches are quite obvious:

• The comment line 39 is completed

WxVersion <- 1; // 0 - wx 2.6, 1 - wx 2.8, 2 - wx 3.0, 3 -wx 3.1, 4 -wx 3.2

• The messages for the version selection frame are extended (lines 59+ and 94+)

• lines 59+ :*

  if (WizType == wizProject)
    {
        local intro_msg = _T("Welcome to the new wxWidgets 2.6.x / 2.8.x / 3.0.x / 3.1.x\nproject wizard!\n\n" +
                            "This wizard will guide you to create a new project using\n" +
                            "the wxWidgets cross-platform GUI library.\n\n" +
                            "When you 're ready to proceed, please click \"Next\"...");

        local wxpath_msg = _T("Please select the location of wxWidgets on your computer.\n" +
                                "This is the top-level folder where wxWidgets was unpacked.\n" +
                                "To help you, this folder must contain the subfolders\n" +
                                "\"include\" and \"lib\".");

        Wizard.AddInfoPage(_T("WxIntro"), intro_msg);
        Wizard.AddGenericSingleChoiceListPage(_T("wxVersionPage"),
                                              _T("Please select the wxWidgets version you want to use."),
                                              _T("wxWidgets 2.6.x;wxWidgets 2.8.x;wxWidgets 3.0.x;wxWidgets 3.1.x"),
                                              WxVersion); // select wxwidgets version

lines 94+, similar modification:

   else if (WizType == wizTarget)
    {
        local intro_msg = _T("Welcome to the new wxWidgets 2.6.x / 2.8.x / 3.0.x / 3.1.x / 3.2.x\nTarget wizard!\n\n" +
                            "This wizard will guide you to create a new target\n" +
                            "When you 're ready to proceed, please click \"Next\"...");

        local wxpath_msg = _T("Please select the location of wxWidgets on your computer.\n" +
                                "This is the top-level folder where wxWidgets was unpacked.\n" +
                                "To help you, this folder must contain the subfolders\n" +
                                "\"include\" and \"lib\".");
            Wizard.AddInfoPage(_T("WxIntro"), intro_msg);
        Wizard.AddGenericSingleChoiceListPage(_T("wxVersionPage"),
                                              _T("Please select the wxWidgets version you want to use."),
                                              _T("wxWidgets 2.6.x;wxWidgets 2.8.x;wxWidgets 3.0.x;wxWidgets 3.1.x;wxWidgets 3.2.x"),
                                              WxVersion); // select wxwidgets version

Then we have to define LibWxVer for the additional version (line 504+):

        if (WxVersion == 0)
            LibWxVer = _T("2.6");
        else if (WxVersion == 1)
            LibWxVer = _T("2.8");
        else if (WxVersion == 2)
            LibWxVer = _T("3.0");
        else if (WxVersion == 3)
            LibWxVer = _T("3.1");
        else if (WxVersion == 4)
            LibWxVer = _T("3.2");

And ultimately, giving for the 3.2.x versions at least the same extensions as applicable to the 3.1.x versions.

    if ((WxVersion == 3 || WxVersion == 4)  && GetCompilerFactory().CompilerInheritsFrom(Wizard.GetCompilerID(), _T("gcc*")))
    {
        project.AddLinkLib(LibPrefix + _T("shlwapi") + LibSuffix);
        project.AddLinkLib(LibPrefix + _T("version") + LibSuffix);
        project.AddLinkLib(LibPrefix + _T("oleacc") + LibSuffix);
        project.AddLinkLib(LibPrefix + _T("uxtheme") + LibSuffix);
    }

---

As said before: the wizard seems working. But I have very limited means to test it, and I neither have the skills nor the knowledge to be fully confident in these patches. So my intend is only to help investigation to create professionally a good wizard upgrade.
The test I made are limited to:
. Windows 8.1 plattform
. gcc 8.1.0 Windows/unicode - 64 bit
. Empty project tested with example code "Hello world" from wxWidget's site (https://docs.wxwidgets.org/latest/overview_helloworld.html )
. with and without PCH
. dll binding
. Simple wxSmith app (as per first WxSmith tutorial)

Also, be aware that I am a newbee, and I modified the script through intuition only (and relying on similar syntax as C). I have absolutely no knowledge about the real scripting rules and debugging tools.

---

Some pending questions are remainig, only someone of the Code::Blocks team can respond.

1) Reference path naming rules
The renaming of <libpath>/lib/gcc810_x64_dll into <libpath>/lib/gcc_dll is a solution.
My own feeling would be to suppress the intermediate folder, positioning the files and the mswu/mswud folders directly under <libpath>/lib/.
But I suppose you have your own rules at Code::Blocks. May be you will stay in line with wxWidget's naming rules.
In any case, a comment in the users documentation is welcome.</libpath></libpath></libpath>

2) Lib extensions for wxWidget version 3.2.x
My patches are only lazy modifications, assuming version 3.2.x need no more extensions as 3.1.x versions.
This has to be analysed.

3) Project vs Debug/Release search pathes
In fact, both Debug ans Release targets are build with the same include path.
Thus, why is the Search Directory defined twice, at the Debug and Release levels, and not at the Project level?

---

Thank You for reading

Axel Mattauch

[Miguel Gimenez]

20.03 is almost three years old, wxWidgets 3.2.1 did not exist at the time and many bugs have been fixed since 2020, including some in the wizards.

Please check the last nightly, if you find problems in the wizard please report in this thread.

[Axel MATTAUCH]

Thank You Miguel
I had an old version because this is the only one available as install. Due to my poor skills, I avoided the better, but more complex process of the nighty builds.
Well, now I have unistalled the 20.03 version, suppressed the <username>\AppData\Roaming\CodeBlocks folder and installed the most recent nighty build (I suppose so) and the tdm64-gcc-10.3.0-2.
Now I've lauched the new Code::Blocks. The start screen indicates:
**svn build rev 12990 (2022-10-21 07:51:00) gcc 8.1.0 Windows/unicode - 64 bit **</username>

Incidentally I don't understand the gcc 8.1.0 reference , because in the Global Compiler settings and GDB/CDB debugger path all the links are done for the tdm64-gcc-10.3.0-2 installation folder.

I have a problem at execution stage (I will explain hereafter, but I think it is out of this topic). Neverthless, even with this limitation, I believe the
wizard has one remaining issue:
At the end of the wizard, as checked in Build Options, most of the build options seems ok, but the produced Linker Settings to linker libraries are:
libwxmsw32ud_core.a
libwxbase32ud.a
that is with both prefix and suffix.
Other points OK (support for wxWidget 3.0, 3.1, 3.2).

---

• My exec issue:*
  With this CB , the compilation and execution of a simple console application (i.e. the "Hello World" produced by the Console application wizard ) works fine.
  But at the execution of the wxWidget app , i have an error message : lauching not possile because libgcc_s_seh_64-1.dll is missing (attachment).
  I will read more documentation and will use the forum...
  Obviously, if You have a tip, I accept it gracefully.

[Miguel Gimenez]

GCC 8.1.0 is the compiler used to create the nightly, it is not related to the compiler you use.

The lib prefix and .a suffix are OK.

To solve the execution issue outside C::B, you must copy said DLL from the TDM folder to the application folder OR compile you application after checking the three compiler options related to static linking. If you have problems with this please ask in the forum.

I will close the ticket