I spent the last 2 or 3 hours tracking this bug.

It's related to a behaviour in glib about how to interpret dlerror()
return value.

To make a long story short, here's what happens:

* g_module_open() looks for symbol 'g_module_check_init'

* _g_module_symbol() for 'dl' platform is thus called, which calls
  dlsym()

* dlsym() returns NULL, thus a variable is set containing the value of
  dlerror()

* g_module_symbol, the wrapper around _g_module_symbol, doesn't check the
  return value of _g_module_symbol, but the return value of
  g_module_error, which returns the NULL from dlerror

Thus g_module_symbol is fooled and returns a NULL pointer.

The fix for that is a one-liner in gmodule/gmodule-dl.c (change the one
and only fetch_dlerror(FALSE) to fetch_dlerror(TRUE), near the end of the
file).

Somehow it doesn't feel right. As much as not testing the return value of
dlsym() feels like a bug in glib, dlsym returning NULL *is* an error,
hence dlerror() should explain it.

Which is more fix worthy ? Both ?

Is transcode behaviour right ? As glib, it checks return value of dlerror
instead of the one of dlsym. Maybe we should change that. I don't know how
FreeBSD and Linux behave with that issue.

-- 
Quentin Garnier - cube@cubidou.net
"Feels like I'm fiddling while Rome is burning down.
Should I lay my fiddle down and take a rifle from the ground ?"
Leigh Nash/Sixpence None The Richer, Paralyzed, Divine Discontents, 2002.