Sake Blok wrote:
> On Mon, Mar 17, 2008 at 03:58:47PM -0700, Gerald Combs wrote:
>> The 1.0 trunk official. 1.0pre1 should be out this evening (PDT) or tomorrow
>> morning. There appears to be a problem with the gmodule DLL in recent releases
>> of GLib. I'll build the Windows installers by hand, substituting
>> libgmodule-2.0-0.dll from GLib 2.14.5, which is the latest release I've found
>> that works.
>
> Was it the objective to use Glib 2.14.5 in the pre-release also? I
> installed 1.0.0pre1 and noticed that Glib 2.14.6 was still used:
>
> Version 1.0.0pre1 (SVN Rev unknown)
>
> Copyright 1998-2008 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Compiled with GTK+ 2.12.8, with GLib 2.14.6, with WinPcap (version unknown),
> with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.5,
> with ADNS, with Lua 5.1, with GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT
> Kerberos, with PortAudio V19-devel, with AirPcap.
I built the 1.0.0pre1 Windows installers using the following process:
nmake -f makefile.nmake setup
[ copy libgmodule-2.0-0.dll 2.14.5 to wireshark-win32-libs\glib\bin ]
nmake -f makefile.nmake distclean all packaging packaging-u3 packaging-papps
As a result, GLib shows up as 2.14.6, even though that's not entirely true. This
was to work around bug 2357 (Wireshark/GTK+1 crashing on startup). I'd like to
have a better fix in place before the final release. Should we split
wireshark-win32-libs\glib into two directories, e.g. glib2-gtk2 (which would
contain the latest stable version) and glib2-gtk1 (which would contain the
latest stable version that works with GTK+1)? It's probably a safe bet that
future versions of GLib won't be guaranteed to work with GTK+1.
