Upgrade glib and gettext on Windows

[ilikenwf]

I tried, and failed...

In order to do this, we'll likely have to revamp the build system.

[johnmurrayvi]

I got updated ones to build on mac, but, windows...not so much. Just found this
http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/README.woe32

The deps don't use "nmake", but they do use "cl", which is not gcc. Most likely why these are so much trouble.

edit:
I did cross compile them though, but I think using the cross compiled deps /may/ force ng-h to be built with gcc as well then.

[ilikenwf]

As long as it runs, who cares which compiler we use?

Nice work. I'm sorry for not being much help lately!

[johnmurrayvi]

http://git.savannah.gnu.org/cgit/gettext.git/commit/README.woe32?id=68fca0cbbd8055f63c5ba9075b6a5ab5d3389bb2

Last gettext version that is build-able with msvc is 0.14.6?

edit: correction, 0.15 doesn't build...

[johnmurrayvi]

Editing title since these are updated on Mac. Windows is still a problem so far though.

[johnmurrayvi]

Hmm this is interesting:
https://wiki.gnome.org/Projects/GTK%2B/Win32/MSVCCompilationOfGTKStack

Also, if we do target gstreamer-1.0 for the next release, this is a blocker right now. I'm not sure how I built the xr 9.0.1 deps with gst-1.0 and gettext, but the xr 1.9.2 branch's glib/gettext is preventing the compilation of gst-1.0...

[johnmurrayvi]

I may have worked around this:

• Used the prebuilt libiconv [v1.9.1] from the old 1.9.2 deps - just copied it into
• Built gettext [v0.18] with KDE's changes and build system (it only outputs intl.dll, intl.lib, and libintl.h)
• Used/copied in GTK's prebuilt glib [v2.34.3] from here
• This is a weird step, but needed for gst-plugins-ugly since it tries to use msgmerge, which isn't built by gettext 0.18 right now.
  • I made a dir, "/local/ng/bin", and put it in my PATH for the MozillaBuild shell (by editing start-msvc8.bat)
  • From the OLD gettext [v0.14.6], copied everything from "gettext/release/bin" into "/local/ng/bin"
    • Files are: envsubst.exe gettext.exe gettextlib.dll gettextpo.dll gettextsrc.dll intl.dll msgattrib.exe msgcat.exe msgcmp.exe msgcomm.exe msgconv.exe msgen.exe msgexec.exe msgfilter.exe msgfmt.exe msggrep.exe msginit.exe msgmerge.exe msgunfmt.exe msguniq.exe ngettext.exe xgettext.exe
  • From the prebuilt libiconv [v1.9.2], copied everything from "libiconv/release/bin" into "/local/ng/bin"
    • Files are: iconv.exe charset.dll iconv.dll
• Proceeded to build the deps: xulrunner-1.9.2 (I already had built), zlib, sqlite, libjpeg-turbo, taglib, flac-1.2.1, libogg, libvorbis, libtheora, and finally gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-bad, gst-plugins-ugly.

This seemed to work and gstreamer and gst-plugins-* didn't complain.

I've been working in my xul-192-gst1-win branch.

[rsjtdrjgfuzkfg]

@johnmurrayvi :) Recent gst-plugins on win will be a big enhancement.

[johnmurrayvi]

The way I mentioned above was not very good. At all. Lol.
It ended up that the GTK prebuilt dependencies depend on the newer style library naming, even for MSVC: "lib-.dll" instead of ".dll".
I got it to work by adding all of the corresponding packaged deps (libiconv, gettext-runtime, glib, libffi), but there was also a dependency on pthreadGC2.dll.
I don't know if that would interfere with the mozilla threading...

I've spent the past two weeks trying to build libiconv, gettext, libffi, and glib natively, but it's been an extreme pain because of them using gnulib.

The other day I started thinking it may be beneficial to try to use msvc 2008 / vc9. Originally, when XR got updated to 1.9.2.28, POTI's work for mozcrt as the default C runtime library got overwritten. (see 6122136) This was particularly important for the debug version of the CRT. All of their work was done for vc8 though.
The past couple of days I've been working on repatching their work, then updating and modifying crt9sp1.diff to include the changes. That will allow vc9 to be used everywhere else.

I'm hoping it'll be easier to fix the native building using vc9 instead of vc8. I've got mozcrt building, but there were some changes in the mozilla code between 1.9.2.9 and 1.9.2.28 that created a "mozcpp" library (C++ runtime) as well. I think I've almost got those issues fixed as well.

So, I'm sorry this is taking so long. It's been really difficult trying to figure out everything, and even more difficult to get things to build, have libraries named correctly to match the old style, have them export the correct functions, and most importantly making sure they depend on the correct libraries and C runtime.