Windows installer: C and GTK runtime installation

[eht16]

This is a RFC:

currently, the Windows installer offers to automatically install the bundled GTK runtime environment or to skip the installation of the corresponding files.
Actually, this option refers not only to the GTK runtime environment but also to the C/C++ runtime environment (libgcc_s_dw2-1.dll, libstdc++-6.dll, libwinpthread-1.dll) but this is not mentioned in the installer.

Some days ago, a Geany user reported this fact via PM to me, it is also reported in #976.

acd4a92 will include the necessary C runtime libraries into the base installation, without any chance for the user to disable it. That way users still have to choice to use a seperate GTK stack but don't need to think about the C runtime.

d92c690 will keep installing the bundled C runtime only when also the bundled GTK runtime is installed. But the title as well as the description of the option to omit installing those files is reworded to make more clear this affects the C and GTK runtime and skipping them might cause problems.

I don't have a strong opinion on which way we want to go, but certainly the current situation need to be improved.

Please do not merge yet. Both commits are mutually exclusive, we should merge only one of them.

Fixes #976.

[codebrainz]

The other option is to link to those libraries statically since they're required for Scintilla, which is not optional, and different versions anyone would drop-in could be harmful due to different C++ ABIs in different versions. Something like -static-libgcc -static-libstdc++ -static -lpthread ... should work IIRC.

[eht16]

Nice idea. Unfortunately, I was not able getting it to work. I tried your list of flags as well as -static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic.
-static doesn't work at all, it will raise tons of "undefined reference" errors. Without, I could statically link linwinpthread but not libgcc and libstdc++, even not with "-static-libgcc -static-libstdc++".
Maybe because I added the flags via *_LDFLAGS to Autotools but IIRC such flags need to be defined last, but Autotools doesn't let me add flags via *_LIBADD oder *_LDADD and bails out.
If anyone comes up with a working example, this could be an interesting option.

[codebrainz]

Hum yeah, I don't know the correct voodoo either. I've done it before for my own small programs with msys2, but not with autolibtools or gtk or any of that stuff.

IMO, we should just unconditionally install the C++ stdlib (and the other two DLLs, which AFAIK are to support C++ exceptions and C++ threading), as they are required by Geany itself (or Scintilla) and probably at least libstdc++ doesn't offer stable ABI between versions, compilers, options, etc (does it?).

[elextr]

and probably at least libstdc++ doesn't offer stable ABI between versions, compilers, options, etc (does it?).

IIRC there was an ABI break around about GCC 5 even on linux.

[b4n]

I agree with @codebrainz: best would probably be statically linking them, second best to always install them. Points raised on why requiring the user to install them is not a great idea seem to make sense.

Without, I could statically link linwinpthread but not libgcc and libstdc++, even not with "-static-libgcc -static-libstdc++".
Maybe because I added the flags via *_LDFLAGS to Autotools but IIRC such flags need to be defined last, but Autotools doesn't let me add flags via *_LIBADD oder *_LDADD and bails out.
If anyone comes up with a working example, this could be an interesting option.

What if you pass them manually using LDFLAGS? (make) envvar? I think they end up last, and as it's not a build requirement but a choice, it would make sense to only have those flags when building our releases and not force them on every user.

$ LDFLAGS="-static-libgcc -static-libstdc++" ./configure …
$ # or
$ make LDFLAGS="-static-libgcc -static-libstdc++"

Not tested at all, just a suggestion.

[codebrainz]

$ LDFLAGS="-static-libgcc -static-libstdc++" ./configure …

This is what I tried, it didn't work. I also tried passing --enable-static --disable-shared to configure. In both cases it built and linked fine, but when I opened in Dependency Walker (fancy win32 ldd) it showed those libs were still dynamically linked (at least libstdc++ was). I also tried leaving the end of the LDFLAGS as static (without putting -Wl,Bdynamic after statically linked stuff) but it totally broke and got all kinds of undefined symbol errors, I guess same as @eht16 described.

[eht16]

Tried also both suggested variants with a successful build but still references to libgcc and libstdc++ :(.

[gostal]

Some time ago I agreed to be guinea pig regarding potential solutions to the GTK-runtime and Wiki issues. This is what I have sofar:

Installed files:
2016-07-08 15:58 geany-1.28nightly20160703_pr1108_01_setup.exe
2016-07-08 15:59 geany-plugins-1.28nightly20160703_setup.exe
2016-07-08 15:59 gtk2-runtime-2.24.10-2012-10-10-ash.exe

The files are installed on a virtual win7 guest on a linux host (OpenSuse Leap 42.1). I opted not to install the bundled GTK and got a symbol error:

The installed gtk2-runtime (wiki page https://wiki.geany.org/howtos/win32/running) is rather old and apparently not compatible.

I have yet to try the runtimes provided by win-builds mingw-w64.

[b4n]

@gostal latest nightlies requires a newer version of GLib, and are likely built against a newer version of the whole GTK stack (yet using GTK 2.24 which is the latest). So currently you can't simply use GTK2 bundle from gtk.org, you either need the one bundled with Geany, or fetch it from MSYS2 (most compatible as it's what we use to build the installers AFAIK)

[eht16]

If nobody stops me, I'll push & merge acd4a92 later today so that we get it into 1.28. That is, including the C libraries in the core installation and so have them installed unconditionally.

[eht16]

@gostal I thought I said this already via PM, using the old gtk.org bundle will most probably never work and is not supported. If you want your own GTK stack, then it has to be compatible with the MSYS2 environment. So either take the binaries from there(this is the same as bundled in the Geany installer) or compile it yourself using the MSYS2 environment.
Everything else would be just luck if it would work regarding binary compatibility.

[b4n]

@eht16 sounds good to me

[gostal]

@eht16 I know you did. I never really thought things would work with the old gtk binary but sometimes
things work better than expected and if they had then some little piece of maintenance effort regarding
the wiki would have been spared.

[gostal]

Further to my trials regarding the GTK-runtime. I fear that this posting may get on your nerves and if so I apologize. I did get the message regarding older runtimes of GLib and GTK but the whole point was to see if other versions of the GTK-runtime might work. (I already knew that the bundled one did.) I have now also tried the win-builds mingw-w64 versions of the runtime libs and clearly they also are too old so it seems that the best way to go about having system wide accessible runtime libs is to follow the advice of @b4n and make the Geany bundle and corresponding source accessible in case I need to develop using GTK or use the MSYS2 ones or perhaps just live with multiple versions although it may require a bit of extra work.

[eht16]

I personally still don't see the big need to redistribute the development environment with each Geany release, only to do to it. But if anyone want to provide a script or patch to existing scripts which will create a suitable bundle while keeping the further maintenance overhead small, I'd be fine with it. Just me personally won't work on it.
Remember, the whole process of setting up a suitable Geany development environment on Windows is documented at http://wiki.geany.org/howtos/win32/msys2. So, creating another bundle containing the development libraries and headers is more or less just redistributing MSYS2.