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 668572 - glib_cv_g_atomic_lock_free config.cache setting not honored by configure
glib_cv_g_atomic_lock_free config.cache setting not honored by configure
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
2.31.x
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-01-24 12:50 UTC by Enrique Ocaña González
Modified: 2012-01-25 04:40 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Proposed patch (1.31 KB, patch)
2012-01-24 12:52 UTC, Enrique Ocaña González 		none Details | Review
New patch using AC_CACHE_CHECK (1.37 KB, patch)
2012-01-24 15:48 UTC, Enrique Ocaña González 		reviewed Details | Review
New patch (1.32 KB, patch)
2012-01-24 18:06 UTC, Enrique Ocaña González 		accepted-commit_now Details | Review
Honor the glib_cv_g_atomic_lock_free env var in configure (1.32 KB, patch)
2012-01-25 04:40 UTC, Matthias Clasen 		committed Details | Review

Description Enrique Ocaña González 2012-01-24 12:50:13 UTC 
When the glib_cv_g_atomic_lock_free setting is forced by config.cache or by being set as an environment variable before doing ./configure, it's not recognized and the check is always done. Consequently, that setting can't be forced when compiling for some specific hardware configuration.
Comment 1 Enrique Ocaña González 2012-01-24 12:52:17 UTC 
Created attachment 205969 [details] [review]
Proposed patch

I'm attaching a patch to fix the bug
Comment 2 Allison Karlitskaya (desrt) 2012-01-24 13:54:43 UTC 
There must surely be some better way to deal with this problem.

I'm against ad-hoc additions of these tests around a small number of our checks just because those ones are sometimes needed to be overridden by cross-compilers (and have been reported to us).  I'm similarly against adding this sort of test to every single check.
Comment 3 Colin Walters 2012-01-24 15:15:37 UTC 
Yes, the better way is called AC_CACHE_CHECK()
Comment 4 Enrique Ocaña González 2012-01-24 15:48:58 UTC 
Created attachment 205996 [details] [review]
New patch using AC_CACHE_CHECK

Thanks for the suggestion Colin. Ryan, what do you think about this new patch?
Comment 5 Colin Walters 2012-01-24 17:04:04 UTC 
Review of attachment 205996 [details] [review]:

::: configure.ac
@@ +2340,3 @@
+                 [glib_cv_g_atomic_lock_free=yes],
+                 [glib_cv_g_atomic_lock_free=no])
+  AC_MSG_RESULT($glib_cv_g_atomic_lock_free)])

AC_CACHE_CHECK runs AC_MSG_RESULT for you - you should be seeing double "...yes...yes" right?  

Just look at the other instances of AC_CACHE_CHECK() that exist in configure.ac now.
Comment 6 Enrique Ocaña González 2012-01-24 18:06:36 UTC 
Created attachment 206000 [details] [review]
New patch

You're right about the double "yes". Didn't notice that AC_CACHE_CHECK already printed the result.

Now it's done using the same pattern as in "Check for nl_langinfo and CODESET".
Comment 7 Colin Walters 2012-01-24 18:22:44 UTC 
Review of attachment 206000 [details] [review]:

Looks good, thanks.
Comment 8 Matthias Clasen 2012-01-25 04:40:43 UTC 
The following fix has been pushed:
aa95853 Honor the glib_cv_g_atomic_lock_free env var in configure
Comment 9 Matthias Clasen 2012-01-25 04:40:47 UTC 
Created attachment 206052 [details] [review]
Honor the glib_cv_g_atomic_lock_free env var in configure

This fixes bug: