#1290 [PATCH] Support for CYGWIN

[Carlo Bramini]

I ported Code::Blocks to CYGWIN.
It required few simple changes to make it working.
I attached my patch created from the latest sources on the repository at the time of writing.

src/include/prep.h
Added platform_cygwin to the list of available platforms.

src/plugins/xpmanifest/windowsxplooknfeel.h
Description of the issue here:
https://sourceforge.net/p/codeblocks/tickets/1191/

src/sdk/Makefile.am
Description of the issue here:
https://sourceforge.net/p/codeblocks/tickets/1190/

src/sdk/configmanager.cpp
when platform::cygwin is true, the name of the file is cygcompiler.dll

src/sdk/pluginmanager.cpp
The DLLs created by CYGWIN start with the "cyg" prefix in their name.
The change adds RemoveLibraryPrefix() function to implement this and simplify the whole code.
Then, it also adds platform::cygwin to ScanForPlugins() for returning the right extension ".dll" for plugins, otherwise it will use ".so" which is wrong.

After applying the changes, you can see the result into the attached image.
This fix is provided by attached cygwin.txt

I did also an additional patch for fixing an annoying warning at compile time.
When building Code::Blocks, this message is continuously printed on the console for every source:

warning: -fPIC ignored for target (all code is position independent)

This happens because configure.ac calls uname for checking the target platform, but this is not a good idea actually. Instead, using $host variable has the advantage to work also with a cross compiler if you have installed one.
This fix is provided by attached configure.txt

Sincerely,
Carlo Bramini.

[Carlo Bramini]

PATCH: main fixes for adding support for CYGWIN.
Applying this patch also closes issues #1190 and #1191.

[Carlo Bramini]

PATCH: fix detection for supporting -fPIC option.

[Andrew Cottrell]

Do you have any docs on what Cygwin packages have to be installed and the steps you need to follow in order to build C::B using Cygwin so that you end up with a runable C::B exe in a directory or installed in the Cygwin directory tree?

You can look at the C::B wiki site for old docs or have a look at the following doc that I have created that you could use as a template:
https://github.com/acotty/CodeBlocks_Unofficial_Testing/blob/master/Readme_Build_Windows_MSYS2_by_Makefile.txt

[Carlo Bramini]

I wrote a detailed guide with all steps needed for running C::B on CYGWIN.
Perhaps, it would be worth to move it also in a wiki page, if you will find it useful.

[Carlo Bramini]

This is a guide for building and testing Code::Blocks on CYGWIN from scratch.

(1) Go to the site www.cygwin.com and download the installer tool. You must download the right tool according to your platform:

setup_x86_64.exe if you want to use 64-bit environment. (recommended)
setup_x86.exe if you want to use 32-bit environment.

(2) Create a directory into the root of your drive, for example c:\cygsetup, and copy that installer inside.

(3) Launch setup utility: for entering to the page for selecting the packages to install, follow these steps.
- press NEXT button on the welcome dialog.
- Select "Install from internet" option and press NEXT button.
- Select the point where CYGWIN will be installed (tipically under "c:\cygwin" or "c:\cygwin64"), select "All Users" and press NEXT button.
- Select the path where you want to store the downloaded packages (it should be already pointing to "c:\cygsetup") and press NEXT button.
- Select the preferred connection method, usually the "Use System Proxy Settings" is the best one, and press NEXT button.
- Select your favourite mirror site and press NEXT button.

(4) Now, we can add the packages needed for building C::B. To do so, into the combo box of the "View" option, select "Not installed" and add these packages:

autoconf
automake
gcc-core
gcc-g++
libtool
libboost-devel
libbz2-devel
libfam-devel
libgtk3-devel
libhunspell-devel
libwx_baseu3.0-devel
libwx_baseu3.0_0
libwx_gtku3.0-devel
libwx_gtku3.0_0
m4
make
pkgconf
subversion
unzip
xlaunch
zip
zlib0
zlib-devel

It is recommended that you install the latest version the packages.
Press NEXT button when you added all.

NOTE (1):
The versions of wxWidgets available on CYGWIN are:
- 2.8 available only with GTK+2.
- 3.0.5, available for GTK+2 and GTK+3.
- 3.1.5, available for GTK+2 and GTK+3.

Version 2.8 cannot be used since the minimum requirement for C::B is 3.0 or newer.
At the time of writing, version 3.1.5 cannot be use because it has been compiled without advanced support for regex expressions.
Instead, version 3.0.5 has been compiled with builtin support enabled for regex and so this is the only version of wxWidgets that can be used with C::B at the time of writing.

NOTE (2):
CYGWIN also provides support for both GTK+2 and GTK+3.
However, since GTK+2.0 had already its final release, it is recommended to use GTK+3.0 and don't consider the option to use the older version.

(5) Now, the setup tool will install all packages you need for building C::B. It will download about 300MB of archives from internet, so the entire process of download/install/configuration will require some time.
When the process is finished, set the options "Create icon on Desktop" and "Add icon to Start Menu" according to your needs and press FINISH button.

(6) Now, launch CYGWIN shell by either clicking on the desktop icon or launching the file cygwin.bat file under your "c:\cygwin" or "c:\cygwin64" directory.
When you reach the prompt of bash, type these commands:

svn checkout https://svn.code.sf.net/p/codeblocks/code/trunk codeblocks-code

cd codeblocks-code/

./bootstrap

mkdir codeblocks-build

cd codeblocks-build

../configure --prefix=$HOME/inst_cb --with-wx-config=/usr/bin/wx-config-3.0 --enable-silent-rules --with-contrib-plugins=all

make

make install

(7) Now, into your home directory, you will find the executable of C::B and you are ready for testing.
For launching C::B, you must launch the X server first. Hopefully, this task can be simplified by using the xlaunch utility. So, you can run this command:

xlaunch &

It is important to add the final "&" character, otherwise bash will be blocked.

(8) On the dialog box shown by xlaunch tool, follow these steps:
- Select "Multiple windows" (my favourite choice) and press NEXT button.
- Select "Start no client" and press NEXT button.
- Accept current options and press NEXT button.
- Press FINISH button.
Now, if the server has been run successfully, into the traybar of Windows Explorer you will see the icon of the X server.

(9) Now that the X server is running, type this command on the bash console:

export DISPLAY=:0.0

Finally, go into your $HOME/inst_cb/bin and run codeblocks executable. After few seconds, the windows of C::B will appear in all its beauty and it is ready to be used.

[Andrew Cottrell]

The package list shows libwx_gtku3.0 , but on the mirror I have used for the last 15 years I have the options of gtk2 or gtk3:
libwx_gtk2u3.0
libwx_gtk3u3.0*

I am assuming I should be using the gtk3. Can you edit the post above to update it or let me know if the mirror I am using is missing the files.

I will post more updates as I progress.

[Carlo Bramini]

Actually, CYGWIN provides both GTK+2 and GTK+3.
The versions of wxWidgets available on CYGWIN are:
- 2.8 available only with GTK+2.
- 3.0.5, available for GTK+2 and GTK+3
- 3.1.5, available for GTK+2 and GTK+3

Version 2.8 cannot be used since the minimum requirement for C::B is 3.0 as I can see.

At the time of writing, version 3.1.5 cannot be use because it has been compiled without advanced support for regex expressions.

So, the only option of wxWidget is version 3.0.5, which can be used with either GTK+2.0 or GTK+3.0. However, since GTK+2.0 had already its final release, my suggestion would be to use GTK+3.0, that's why I didn't even considered the option to use the older version.
However, if you prefer, I can add this description to the post.

[Andrew Cottrell]

When writing install or build guides if end users can choose an option that is dumb and will not work then expect issues because they will and there is nothing you can do, apart from making sure the doc specifies a working set of tools/packages and processes.
As such if you say install A and there are 4 versions if only two of them work the specify A version 1 or 2 (do NOT use 3 or 4).

[Andrew Cottrell]

The configure line has your home directory specified and newbies will just copy and paste the line without checking it as there is no info that it needs changing. I would suggest adding info that the user needs to change the --prefix or if ~ works then you would not need to change it (I do not know if ~ works on not).
../codeblocks-code/configure --prefix=/home/Carlo/inst_cb --with-wx-config=/usr/bin/wx-config-3.0 --enable-silent-rules

As there is no Code::Blocks Cygwin package you may also want to include the --prefix for installing it like a Cygwin package int eh C:\cygwin64 directory structure.

Update: You could also try using the $HOME environment variable instead of ~

[Carlo Bramini]

I modified the post according to your description, thank you.

[Andrew Cottrell]

The ../codeblocks-code/configure does not exist, it should be ../configure

[Carlo Bramini]

You are right, sorry, I forgot to add a "cd .." after bootstrap.
Modifying the configure line looks better, one command less to type.

[Andrew Cottrell]

The build and install worked fine. The resulting C::B looks to only have the Linux plugins and therefore does not have the extra Windows plugins. Have you looked at this to see if you can build the additional Windows plugins with Cygwin?

[Carlo Bramini]

Indeed, CYGWIN mimics a UNIX environment, could you give me more details about these missing plugins?

I also noticed that C::B does not detect x86_64-w64-mingw32 and i686-w64-mingw32 cross compilers automatically, but I don't know if this is expected to happen or it is not correct .

[Andrew Cottrell]

If you look at the plugin directory almost every one of the directories and sub directories is a plugin on Windows, but not on Linux.

Use the forum for cross compiling issues as it has nothing to do with this patch.

[Carlo Bramini]

I did some change to the post with the build & installation guide.
I added some additional libraries:

libfam-devel
libboost-devel
libhunspell-devel

and I added all missing plugins by including option --with-contrib-plugins=all when configuring.
Unfortunately, I got a number of these errors:

libtool:   error: can't build x86_64-unknown-cygwin shared library unless -no-undefined is specified

but not all libraries seem to need this option.
In my opinion, the -no-undefined flag surely needs to be added to:

src/plugins/contrib/wxSmith/Makefile.am

because it has -shared flag to LDFLAGS.
These libraries also generate the above error message:

src/plugins/contrib/wxContribItems/KWIC
src/plugins/contrib/wxContribItems/wxFlatNotebook
src/plugins/contrib/wxContribItems/wxImagePanel
src/plugins/contrib/wxContribItems/wxSpeedButton
src/plugins/contrib/wxContribItems/wxchart
src/plugins/contrib/wxContribItems/wxled
src/plugins/contrib/wxContribItems/wxmathplot
src/plugins/contrib/wxContribItems/wxthings

But I'm a bit reluctant to add -no-undefined to them too.
The reason is that they seem to be convenience libraries and, when you do make install, these DLLs are installed under lib/codeblocks/bin.
This has the sad effect to fail the loading of some plugins because those DLLs are not into the search path and both MINGW and CYGWIN do not support runtime search path at executable level.

Looking into the included cbp files, I have found that those libraries are compiled as static, like here for example:

https://sourceforge.net/p/codeblocks/code/HEAD/tree/trunk/src/plugins/contrib/wxContribItems/wxContribItems_wx30-unix.cbp

with <Option createStaticLib="1" />, so I did a patch by adding -static flag to their Makefile.am files.

Instead, when compiling those libraries as DLLs, there are some different ways for doing it.

By looking the content of the ZIP file with C::B version 20.03 compiled forWindows, I have seen that those DLLs have been moved into the root of the installation, where codeblocks.exe is. This is a first working solution.
Another one is to add the path to lib/codeblocks/bin to the $PATH environment variable or add somewhere in the source code an #if...#endif, for __WXMSW__ and __CYGWIN__, for manually loading the DLLs from a known path before loading the plugins.
Infact:

If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.

https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

At the moment, the easiest solution has been to add -static flag and this worked fine.
After compiling successfully also the contrib plugins, comparing to previous screenshot, you will see lot of newer toolbars appeared on screen, as you can see from attached screenshot.

Sincerely.

[Carlo Bramini]

The patch to the contrib plugins.

[Andrew Cottrell]

Have you checked if this patch causes build issues on Linux or Mac?

[Carlo Bramini]

At the moment, I have not a Linux or Mac machine for testing this change, sorry.

However, instead of doing static libraries, dynamic libraries could be still created, by leaving everything as it is and by just using -no-undefined instead of -static and writing something like this before PluginManager::LoadPlugin() is called:

if (platform::cygwin || platform::windows) {
    // append to $PATH the directory where these libraries are:
    // - wxchartctrl
    // - wxflatnotebook
    // - wxkwic
    // - wxmathplot
    // - wxcustombutton
    // - wximagepanel
    // - wxled
    // - wxspeedbutton
}

But unfortunately I don't know C::B so much for having the idea where it would be better to do so...

EDIT: Tested on Linux Debian 5.18.0-3-amd64 and it seems that it doesn't like to have these libraries as static.
It prints this message into a dialogbox:

../src/common/object.cpp(245): assert "classTable->Get(m_className) == NULL" failed in Register():
Class "wxFlatNotebookEvent" already in RTTI table - 
have you used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?

[Andrew Cottrell]

You can use VirtualBox or Vmware Player or Qemu to install a Linux distro and run it as a virtual machine. I do this and have multiple OS's to test on for various projects.

[Carlo Bramini]

This is a solution that seems to work fine for loading all contrib plugins under CYGWIN.
It just adds the right path to the $PATH variable, so the place with convenience libraries will be known to the dynamic linker.
Ater this change, all plugins are loaded successfully.
I made it for CYGWIN but I think that it could be used also for platform::windows, so there won't be the need to place the convenience libraries into the root of the intallation directory anymore. Unfortunately, cross compiling for MinGW will need some additional patches, so I left them out of this issue.

[Carlo Bramini]

First part of the patch: src_plugins_contrib.txt
Adds -no-undefined to various Makefile.am scripts. In my opinion, this should be done indipendently if the second part of the patch can be accepted or not, otherwise it simply won't build.

Second part of the patch: src_src.txt
Adds location of convenience libraries to $PATH.