After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 662810 - Valac generates code dependent upon deprecated GLib functions (jhbuild build breaker)
Valac generates code dependent upon deprecated GLib functions (jhbuild build ...
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Code Generator
0.14.x
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
: 663197 (view as bug list)
Depends on:
Blocks: 667825
 
 
Reported: 2011-10-26 22:17 UTC by Travis Reitter
Modified: 2012-09-16 18:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
glib-2.0: Deprecate several threading symbols (4.09 KB, patch)
2011-11-05 11:42 UTC, Luca Bruno
none Details | Review

Description Travis Reitter 2011-10-26 22:17:58 UTC
Valac can generate C code that uses g_static_rec_mutex* which are deprecated in the latest version of GLib.

GLib recommends:

g_static_rec_mutex_init -> g_rec_mutex_init
g_static_rec_mutex_free -> g_rec_mutex_free

Since jhbuild sets -Wdeprecated-declarations, this breaks the build (within jhbuild) for Folks (and any other code that uses lock(), I think). 

There may be other newly-deprecated functions that Valac uses which Folks doesn't trigger (so I haven't noticed).
Comment 1 Luca Bruno 2011-11-05 10:50:51 UTC
*** Bug 663197 has been marked as a duplicate of this bug. ***
Comment 2 Luca Bruno 2011-11-05 11:42:00 UTC
Created attachment 200746 [details] [review]
glib-2.0: Deprecate several threading symbols

Proposed patch, not really complete as Private is very tricky and there's
no StaticCond.
Comment 3 Evan Nemerson 2011-11-05 19:41:19 UTC
(In reply to comment #2)
> Created an attachment (id=200746) [details] [review]
> glib-2.0: Deprecate several threading symbols
> 
> Proposed patch, not really complete as Private is very tricky and there's
> no StaticCond.

When targeting GLib >= 2.32, instead of deprecating Mutex I think we should switch it to a struct and deprecate StaticMutex. You would have to target glib >= 2.32, so it shouldn't cause any problems with older software. It keeps us in line with other languages, and Static* is ugly.
Comment 4 Jürg Billeter 2012-07-31 09:53:23 UTC
A few fixes for this were committed a while ago. Are there still issues left (when targeting GLib >= 2.32)?
Comment 5 Adam Dingle 2012-09-11 21:19:09 UTC
This does not appear to be fixed:

=== test.vala ===
class Foo {
    int xyz;

    public void inc() {
        lock (xyz) { ++xyz; }
    }
}

void main() {
    new Foo().inc();
}
=== end ===

$ valac --version
Vala 0.17.6
$ valac --target-glib=2.32 test.vala
/home/adam/test/test.vala.c: In function ‘foo_inc’:
/home/adam/test/test.vala.c:70:3: warning: ‘g_static_rec_mutex_lock’ is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:173): Use 'g_rec_mutex_lock' instead [-Wdeprecated-declarations]
/home/adam/test/test.vala.c:80:4: warning: ‘g_static_rec_mutex_unlock’ is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:179): Use 'g_rec_mutex_unlock' instead [-Wdeprecated-declarations]
/home/adam/test/test.vala.c: In function ‘foo_instance_init’:
/home/adam/test/test.vala.c:222:2: warning: ‘g_static_rec_mutex_init’ is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:170): Use 'g_rec_mutex_init' instead [-Wdeprecated-declarations]
/home/adam/test/test.vala.c: In function ‘foo_finalize’:
/home/adam/test/test.vala.c:230:2: warning: ‘g_static_rec_mutex_free’ is deprecated (declared at /usr/include/glib-2.0/glib/deprecated/gthread.h:189): Use 'g_rec_mutex_free' instead [-Wdeprecated-declarations]
$
Comment 6 Jürg Billeter 2012-09-16 18:47:32 UTC
commit dfb95c8093363a057e52da24929e11b2b72b17f0
Author: Jürg Billeter <j@bitron.ch>
Date:   Sun Sep 16 20:45:15 2012 +0200

    codegen: Do not use deprecated functions for lock statements
    
    Fixes bug 662810.