Re: glib 2.2.3/2.3.2 binary incompatibility

["J. Ali Harlow" <ali avrc city ac uk>]

On 2004.03.04 19:26 Hans Breuer wrote:
> At 12:34 04.03.04, Tor Lillqvist wrote:
> > I wrote:
> >  > For ABI compatibility also that will have to be added (back) to
> >  > 2.4's gobject.def then.
>
> [...]
>
> > Still, just for cleanliness, it's probably a good idea to filter out
> > the incorrectly exported entries from gobject's import libraries (the
> > gcc and MS ones).
>
> The def file syntax allows a much more simple way :
>
> diff --exclude-from=c:\util\tool\diff.ign -u -r 
> from-cvs/glib/gobject/gobject.def my-gtk/glib/gobject/gobject.def
> --- from-cvs/glib/gobject/gobject.def   Thu Mar  4 20:16:28 2004
> +++ my-gtk/glib/gobject/gobject.def     Thu Mar  4 20:19:50 2004
> @@ -173,7 +173,7 @@
>         g_signal_stop_emission
>         g_signal_stop_emission_by_name
>         g_signal_type_cclosure_new
> -       g_slist_remove_all
> +       g_slist_remove_all PRIVATE
>         g_source_set_closure
>         g_strdup_value_contents
>         g_strv_get_type
> @@ -244,7 +244,7 @@
>         g_type_set_qdata
>         g_type_test_flags
>         g_type_value_table_peek
> -       g_unichar_validate
> +       g_unichar_validate PRIVATE
>         g_value_array_append
>         g_value_array_copy
>         g_value_array_free
>
> This way they are in the DLL but not the LIB, that's what the optional
> keyword PRIVATE is all about. (Problem solved at least for the msvc
> build ;)

I've now tested this with mingw32. It ignores the PRIVATE keyword (so 
having
it there doesn't cause mingw32 any problems - it just isn't effective). 
I
guess it might be possible for Tor to use it in his filter.

Cheers,

Ali.