add linking to gthread-2.0.lib in lcm.vcproj and lcm-logger.vcproj

[simbaforrest]

Without this change, the compile will fail. Tested with VS2010 under x86 settings.

[tprk77]

What version of GLib are you using? We recently bumped the minimum version to 2.32.0. This makes linking gthread-2.0 obsolete. The change was recent, for #76. See 673a30c for changes to the Windows README.txt.

I know a couple other users are using 2.45.4 successfully. I think they might be using MSYS or compiling the library themselves.

[simbaforrest]

Aha, unfortunately, I can only use the prebuilt binary here which is 2.28:
http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.28/

I tried MSYS but there is not .lib but all .a files installed...

[mwoehlke-kitware]

Can you use CMake instead?

[shanemd]

This is still broken with the Ubuntu 16.04 repos. I'm beginning to think this is Ubuntu's problem though.

EDIT: My bad, ldd is in glibc not glib. Regardless, build still fails and it appears I have libglib-2.0 version 2.48. Any ideas?

apt list shows I've got 2.48

~$ apt list --installed | grep libglib
libglib2.0-0/xenial-updates,now 2.48.1-1~ubuntu16.04.1 amd64 [installed]
libglib2.0-bin/xenial-updates,now 2.48.1-1~ubuntu16.04.1 amd64 [installed]
libglib2.0-data/xenial-updates,xenial-updates,now 2.48.1-1~ubuntu16.04.1 all [installed]
libglib2.0-dev/xenial-updates,now 2.48.1-1~ubuntu16.04.1 amd64 [installed]
libglibmm-2.4-1v5/xenial,now 2.46.3-1 amd64 [installed,automatic]

But ldd says it's only 2.23

~$ ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu3) 2.23
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Anyone else seeing this problem?

[mwoehlke-kitware]

apt list shows I've got 2.48 [...] But ldd says it's only 2.23

Huh? You are comparing the version of glib (2.48) to the version of ldd (2.23). Why would you expect them to be the same?

Maybe you are being confused because ldd mentions glib**c**? glibc != glib; glibc is the system C runtime (specifically, the GNU C Runtime Library), GLib is "the low-level core library that forms the basis for projects such as GTK+ and GNOME".

Also, what does this have to do with the PR?

[shanemd]

I was in confusing glib and glibc. See EDIT above.

I believe this is still pertinent though. I'm running glib 2.48 and the build is failing with:
/tmp/lcm/lcm-logger/lcm_logger.c:546: undefined reference to g_thread_init'`

git bisect is pointing this commit as introducing the build failure:
b4c3caa Merge pull request #77 from tprk77/remove-gthread-dependency

[mwoehlke-kitware]

I believe this is still pertinent though. I'm running glib 2.48 and the build is failing [...]

Okay, but I'll repeat my earlier question: is it broken with CMake? 😄

Personally, I wouldn't mind the other build systems just going away. After all, that's one of the claimed benefits of using CMake: we don't need to maintain separate build systems for {Windows, Python, everyone else}.

(Otherwise, I'd expect a PR to fix autotools also.)

[tprk77]

@shanemd Thanks for noticing the build failure. We are in a transitional period with the build system, as you've already noticed. (This might have been better filed as a separate issue, but no matter.) Thanks for helping out.

The problem you encountered has to do with the Autotools build missing deprecated symbols. Apparently g_thread_init (a deprecated function) is only defined in libthread-2.0.a (a deprecated library). The fix is to delete all instances of g_thread_init. I've fixed this in #94.

[ashuang]

#94 is merged in. Sorry for all the dependency churn, it's been a bit unstable since we've been messing with both the build system and GLib required version

[tprk77]

Since the original issue was about re-adding the link to gthread-2.0, and we're not going to do that, I think we can close this as a "wontfix".