Re: [gtk-list] Loading 2.6 symbols when linked against 2.4

[mpsuzuki hiroshima-u ac jp]

Hi,

On Fri, 15 Sep 2006 13:01:47 +0900
mpsuzuki hiroshima-u ac jp wrote:
>If the functions to be checked is in yet-not-loaded pluggable
>modules (e.g. pango-arabic-fc.so), g_module_symbol() will be
>useful.
>
>But, ellipsis issue is slightly different, because it is in
>libpango, and it is linked at once when the program is started.
>It's out of gmodule framework, so we don't have module object
>for libpango, as a result, g_module_symbol() cannot scan the
>symbols in libpango - I suppose.

THIS WAS MISTAKE.

During a test on GNU/Linux, I found g_module_symbol() can
scan the symbols that are already resolved (before calling
any g_module_open()), in some systems.

--

On HP-UX, g_module_open() is a wrapper of shl_findsym().
According to the "man shl_findsym":

    ...If a pointer to NULL is passed for this argument,
    shl_findsym() searches all user defined symbols (those defined by
    shl_definesym()), all currently loaded shared libraries and the
    program to find the symbol; otherwise shl_findsym() searches only
    the specified shared library.  The return value of handle will be
    NULL if the symbol found was generated via shl_definesym().
    Otherwise the handle of the library where the symbol was found is
    returned.  The special handle PROG_HANDLE can be used to refer to
    the program itself, so that symbols exported from the program can
    also be accessed dynamically.

So, we can scan libpango symbols (without g_module_open())
by passing PROG_HANDLE (or NULL?) to g_module_open().

--

On MacOS X, g_module_open() is a wrapper of NSLookupSymbolInModule().

    static gpointer
    _g_module_symbol (gpointer     handle,
                      const gchar *symbol_name)
    {
      NSSymbol sym;
      char *msg;
    
      if (handle == &self_module)
        {
          if (NSIsSymbolNameDefined (symbol_name))
            sym = NSLookupAndBindSymbol (symbol_name);
          else
            sym = NULL;
        }
      else
        sym = NSLookupSymbolInModule (handle, symbol_name);
    ...

As you can see, if we can pass "&self_module" to g_module_symbol,
we can scan libpango symbols without g_module_open(). However,
yet I don't know how to calculate &self_module.

--
I don't have conclusion for platforms with Sun-style dynamic
loaders (dlopen(),dlsym(),dlclose()), and AIX. On these systems,
gmodule just pass arguments to dlsym(), aslike:

    static gpointer
    _g_module_symbol (gpointer     handle,
                      const gchar *symbol_name)
    {
      gpointer p;
      
      p = dlsym (handle, symbol_name);
      if (!p)
        g_module_set_error (fetch_dlerror (FALSE));
      
      return p;
    }

According to FreeBSD 4.11's "man dlsym", passing NULL handle
is enough to scan symbols before dlopen().

    If dlsym() is called with the special handle NULL,
    it is interpreted as a reference to the executable
    or shared object from which the call is being made.
    Thus a shared object can reference its own symbols.

I can find similar notes in SunOS 4.1.4 "man dlsym".

--

GNU/Linux "man dlsym" is obsolete, does not mention about
the case when we pass NULL handle, but when I do small
experiments, passing NULL handle works. I tested on
glibc-2.0.7pre and glibc-2.2.5.

--

AIX 5.3 (at least) has special handle to scan the symbol
of the running process: RTLD_MYSELF.
	http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.basetechref/doc/basetrf1/dlsym.htm?resultof=%22%64%6c%73%79%6d%22%20

AIX 5.1 doesn't mention.
	http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/basetrf1/dlsym.htm#HDRDUP0003

--

At present, I have no access to other systems. However,
I can say, gmodules does not provide portable method
to scan the symbols of the symbols without g_module_open().