Bug 70255 - Build fails with glib-2.38
Summary: Build fails with glib-2.38
Status: RESOLVED FIXED
Alias: None
Product: shared-mime-info
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Shared Mime Info group
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-07 21:53 UTC by John Ralls
Modified: 2013-10-09 20:13 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
ifdef-out g_type_init if Glib version >= 2.36. (1.19 KB, patch)
2013-10-08 18:35 UTC, John Ralls
Details | Splinter Review

Description John Ralls 2013-10-07 21:53:50 UTC
Because there's a call to g_type_init() in test-tree-magic.c
Comment 1 Bastien Nocera 2013-10-08 07:29:26 UTC
Unless you disabled deprecated functions in GLib, it should still compile. It's just been deprecated, not removed (eg. it builds fine for me against GLib 2.38).
Comment 2 John Ralls 2013-10-08 18:35:24 UTC
Created attachment 87297 [details] [review]
ifdef-out g_type_init if Glib version >= 2.36.

(In reply to comment #1)
> Unless you disabled deprecated functions in GLib, it should still compile.
> It's just been deprecated, not removed (eg. it builds fine for me against
> GLib 2.38).

Try with -Werror.

Anyway, it's a tiny change, a couple of lines each in configure.ac and test-tree-magic.c, and it'll have to be fixed sooner or later regardless. Why wait?

As an inducement, patch attached.
Comment 3 Bastien Nocera 2013-10-09 09:47:41 UTC
Or define GLIB_DISABLE_DEPRECATION_WARNINGS, or using GLIB_VERSION_MIN_REQUIRED. There's no need for configure.ac changes.

(In reply to comment #2)
> Created attachment 87297 [details] [review] [review]
> ifdef-out g_type_init if Glib version >= 2.36.
> 
> (In reply to comment #1)
> > Unless you disabled deprecated functions in GLib, it should still compile.
> > It's just been deprecated, not removed (eg. it builds fine for me against
> > GLib 2.38).
> 
> Try with -Werror.

Why would you compile with deprecated warnings and -Werror?

> Anyway, it's a tiny change, a couple of lines each in configure.ac and
> test-tree-magic.c, and it'll have to be fixed sooner or later regardless.
> Why wait?

Sooner or later? When glib 2.x is obsolete? That'll be a while.

> As an inducement, patch attached.
Comment 4 John Ralls 2013-10-09 19:34:33 UTC
(In reply to comment #3)
> Or define GLIB_DISABLE_DEPRECATION_WARNINGS, or using
> GLIB_VERSION_MIN_REQUIRED. There's no need for configure.ac changes.

That won't help when the API is removed and it becomes a hard error.

> 
> (In reply to comment #2)
> > Created attachment 87297 [details] [review] [review] [review]
> > ifdef-out g_type_init if Glib version >= 2.36.
> > 
> > (In reply to comment #1)
> > > Unless you disabled deprecated functions in GLib, it should still compile.
> > > It's just been deprecated, not removed (eg. it builds fine for me against
> > > GLib 2.38).
> > 
> > Try with -Werror.
> 
> Why would you compile with deprecated warnings and -Werror?

To catch them and fix them, so that they don't go flying by unnoticed. 

> 
> > Anyway, it's a tiny change, a couple of lines each in configure.ac and
> > test-tree-magic.c, and it'll have to be fixed sooner or later regardless.
> > Why wait?
> 
> Sooner or later? When glib 2.x is obsolete? That'll be a while.

Sounds a bit optimistic. My understanding of the policy is that API can be removed after it has been deprecated for 2 minor revs. Doesn't have to be, but can be.  

Anyway, I have more important stuff to do than to argue about nits.
Comment 5 Bastien Nocera 2013-10-09 20:13:19 UTC
(In reply to comment #4)
<snip>
> Anyway, I have more important stuff to do than to argue about nits.

So do I.

commit 2397314542265405498ea8c82121c174ed9011a5
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Oct 9 22:09:56 2013 +0200

    test: Call g_type_init() with older glib
    
    Only call g_type_init() when compiling against an older glib.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=70255


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.