[opensuse] glib.h triggers new error: /usr/include/pthread.h:1000:58: error: expected ‘;’, ‘,’ or ‘)’ before ‘__cond’
All, This is bewildering. On my 13.1 laptop, something broke building GTK apps in the last 10 days. Now compiling fails with: In file included from /usr/include/glib-2.0/glib/deprecated/gthread.h:123:0, from /usr/include/glib-2.0/glib.h:109, from /usr/include/glib-2.0/gobject/gbinding.h:30, from /usr/include/glib-2.0/glib-object.h:25, from /usr/include/glib-2.0/gio/gioenums.h:30, from /usr/include/glib-2.0/gio/giotypes.h:30, from /usr/include/glib-2.0/gio/gio.h:28, from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30, from /usr/include/gtk-2.0/gdk/gdk.h:32, from /usr/include/gtk-2.0/gtk/gtk.h:32, from gtk_windef.h:4, from gtk_windef.c:1: /usr/include/pthread.h:1000:58: error: expected ‘;’, ‘,’ or ‘)’ before ‘__cond’ extern int pthread_cond_wait (pthread_cond_t *__rdstrict __cond, Huh? This is new, I've built this code 500 times, last without error on 7/29. The only apps installed on the system since then were from OSS: Tue 02 Aug 2016 08:31:55 PM CDT pcre-doc 8.33-2.1.2 Tue 02 Aug 2016 08:31:55 PM CDT pcre-tools 8.33-2.1.2 Mon 08 Aug 2016 01:57:47 PM CDT libada48 4.8.1_20130909-3.2.1 Mon 08 Aug 2016 01:57:51 PM CDT gcc-ada 4.8-2.1.2 Mon 08 Aug 2016 01:57:51 PM CDT gcc48-ada 4.8.1_20130909-3.2.1 I can't see any of thoses causing issue (sure the ada compiler is the same as the remaining gcc tools), e.g.: rpm -qa | grep gcc | sort gcc-32bit-4.8-2.1.2.x86_64 gcc-4.8-2.1.2.x86_64 gcc-ada-4.8-2.1.2.x86_64 gcc-c++-4.8-2.1.2.x86_64 gcc-fortran-4.8-2.1.2.x86_64 gcc-gij-4.8-2.1.2.x86_64 gcc-info-4.8-2.1.2.x86_64 gcc-java-4.8-2.1.2.x86_64 gcc-objc-4.8-2.1.2.x86_64 gcc48-32bit-4.8.1_20130909-3.2.1.x86_64 gcc48-4.8.1_20130909-3.2.1.x86_64 gcc48-ada-4.8.1_20130909-3.2.1.x86_64 gcc48-c++-4.8.1_20130909-3.2.1.x86_64 gcc48-fortran-4.8.1_20130909-3.2.1.x86_64 gcc48-gij-4.8.1_20130909-3.2.1.x86_64 gcc48-info-4.8.1_20130909-3.2.1.noarch gcc48-java-4.8.1_20130909-3.2.1.x86_64 gcc48-objc-4.8.1_20130909-3.2.1.x86_64 gccmakedep-1.0.2-6.1.2.noarch libgcc_s1-32bit-4.8.1_20130909-3.2.1.x86_64 libgcc_s1-4.8.1_20130909-3.2.1.x86_64 Did installing ada cause some regression? Passing -DG_DISABLE_DEPRECATED solves the problem, but I've never had to disable depricated headers before. Now simply including glib.h causes the error. Has anyone else run into this problem? Has anyone else found a fix? (side note: it also disclosed glib's abuse of enum in /usr/include/glib-2.0/gobject/gparam.h with G_PARAM_DEPRECATED = 1 << 31 which is definitely not an 'int' constant [by +1]) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
10.08.2016 05:55, David C. Rankin пишет:
/usr/include/pthread.h:1000:58: error: expected ‘;’, ‘,’ or ‘)’ before ‘__cond’ extern int pthread_cond_wait (pthread_cond_t *__rdstrict __cond,
Is it really __rDstrict? It is suposed to be __rEstrict. ...
(side note: it also disclosed glib's abuse of enum in /usr/include/glib-2.0/gobject/gparam.h with
G_PARAM_DEPRECATED = 1 << 31
which is definitely not an 'int' constant [by +1])
What it is? Floating point? String? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/09/2016 10:44 PM, Andrei Borzenkov wrote:
10.08.2016 05:55, David C. Rankin пишет:
/usr/include/pthread.h:1000:58: error: expected ‘;’, ‘,’ or ‘)’ before ‘__cond’ extern int pthread_cond_wait (pthread_cond_t *__rdstrict __cond, Is it really __rDstrict? It is suposed to be __rEstrict.
...
Yes, really is...
(side note: it also disclosed glib's abuse of enum in /usr/include/glib-2.0/gobject/gparam.h with
G_PARAM_DEPRECATED = 1 << 31
which is definitely not an 'int' constant [by +1])
What it is? Floating point? String?
INT_MAX = (1 << 31) - 1; Evidently the shifts 0-30 were used and instead of finding some nice number in the range of int, they just shifted by 31 and left it. The solved part of the response can be chocked up to a big "I have no clue what was broke", but `zypper up -r update` pulled in an update for pcre-tools, and attempting the build again -- worked fine. So all is well again. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/09/2016 10:55 PM, David C. Rankin wrote:
The solved part of the response can be chocked up to a big "I have no clue what was broke", but `zypper up -r update` pulled in an update for pcre-tools, and attempting the build again -- worked fine.
So all is well again.
And I guess to be fair, we ought to at least apply a little logic to the situation and narrow down the suspects, Since there was no issue with glib.h throwing the error prior to install of pcre-tools on 8/2/16 from OSS, I suspect that gcc, or cpp more likely, will use pcregrep if it is installed, otherwise using grep (or sed, or whatever, I haven't found the default logic yet). Once pcregrep was installed, through whatever defect existed, the error was generated regarding: /usr/include/pthread.h:1000:58: error: expected ‘;’, ‘,’ or ‘)’ before ‘__cond’ extern int pthread_cond_wait (pthread_cond_t *__rdstrict __cond, Andrei correctly pointed out the __rDstrict v. __rEstrict strangeness in error reporting. pthread.h was in fact correct: $ sed -n '1000'p /usr/include/pthread.h extern int pthread_cond_wait (pthread_cond_t *__restrict __cond, So somewhere in the daisy-chain of header inclusions and parsing, something really mucked up was happening. My last suspicion is that updating to pcre-tools-8.37-2.4.1 from the update repo fixed the issue causing all to be right in the world again. So 'Go figure...'? I'll try and track down any bug reports for pcre-tools and see if there is anything that appears related and report on anything found. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Aug 10, 2016 at 12:44 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Andrei correctly pointed out the __rDstrict v. __rEstrict strangeness in error reporting. pthread.h was in fact correct:
That's only a 1-bit flip error. That happens on rare occasion in ram. If you can't reproduce it on a different machine, I'd say you have a hardware issue (or were the unlucky recipient of a cosmic ray). Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/10/2016 12:24 PM, Greg Freemyer wrote:
On Wed, Aug 10, 2016 at 12:44 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Andrei correctly pointed out the __rDstrict v. __rEstrict strangeness in error reporting. pthread.h was in fact correct:
That's only a 1-bit flip error.
That happens on rare occasion in ram.
If you can't reproduce it on a different machine, I'd say you have a hardware issue (or were the unlucky recipient of a cosmic ray).
HAH! Hell yes! My neutrino detector works! -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Aug 10, 2016 at 6:55 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
(side note: it also disclosed glib's abuse of enum in /usr/include/glib-2.0/gobject/gparam.h with
G_PARAM_DEPRECATED = 1 << 31
which is definitely not an 'int' constant [by +1])
What it is? Floating point? String?
INT_MAX = (1 << 31) - 1;
Note that in C90 this is implementation defined. Further standards explicitly call this undefined behavior. GCC documentation on implementation defined aspects: --><-- o The results of some bitwise operations on signed integers (C90 6.3, C99 and C11 6.5). Bitwise operators act on the representation of the value including both the sign and value bits, where the sign bit is considered immediately above the highest-value value bit. Signed ‘>>’ acts on negative numbers by sign extension. GCC does not use the latitude given in C99 and C11 only to treat certain aspects of signed ‘<<’ as undefined, but this is subject to change. --><-- [I admit to not full understand the last sentence being non-native English speaker, but I take it as "the behavior is not undefined"] And if you look at generated assembly, this expression is replaced by -1 integer constant which is pretty much legal in this context. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Andrei Borzenkov -
David C. Rankin -
Greg Freemyer