Re: GtkModule fixes



Tim Janik <timj gtk org> writes:

> On 26 Aug 2001, Owen Taylor wrote:
> 
> > 
> > Another thing I forgot to ask about this; in the bug report I have:
> > 
> >    * add_dll suffix out of gtkmain.c into gtkmodule, GModule search path?
> > 
> >    I believe this means that you should be able to do GTK_MODULES=gle,
> >    not GTK_MODULES=libgle.so.
> > 
> > Can you explain further?
> 
> GTK_MODULES=gle is already possible, early in starting gtk devel this was added:
> 
> #ifdef __EMX__
> static gchar *
> add_dll_suffix (gchar *module_name)
> {
>     gchar *suffix = strrchr (module_name, '.');
> 
>     if (!suffix || stricmp(suffix, ".dll"))
>     {
>         gchar *old = module_name;
> 
>         module_name = g_strconcat (module_name, ".dll", NULL);
>         g_free (old);
>     }
>     return (module_name);
> }
> #endif
> 
> and i kept a note back then, since this doesn't belong into gtkmain.c.
> if this is still necessary, it prolly should go somewhere into GModule.

Errr, this is OS/2-only code that should never have been added into GTK+.

Look down where it is called:

#ifndef __EMX__
      if (!g_path_is_absolute (module_name))
	{
	  gchar *old = module_name;
	  
	  module_name = g_module_build_path (NULL, module_name);
	  g_free (old);
	}
#else
      module_name = add_dll_suffix (module_name);
#endif

The __EMX__ stuff should just be removed, since the equivalent handling
is done for windows in g_module_build_path(). (And I don't think the 
OS/2 "port" is working in a lot of other ways either.)

But the g_module_build_path() handling then sufficient for what you 
mean? ... it does seem to do the gle => libgle.so handling.

Regards,
                                        Owen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]