Bug 682008 – sys-libs/glibc-2.28 with sys-devel/gcc-4.9.4 - n file included from pthread_mutex_getprioceiling.c:21: pthread_mutex_getprioceiling.c: In function 'pthread_mutex_getprioceiling': ../include/atomic.h:672:4: error: read-only variable '__atg100_val' used as

• Status: RESOLVED INVALID
• Product: Gentoo Linux

[Description Hans F. Nordhaug 2019-03-29 11:31:36 UTC]

We have a some programs that requires us to compile using GCC 4.9.4 still. Glibc 2.28 should compile with 4.9 - - no build requirement changes since 2.27 according to https://github.com/bminor/glibc/releases/tag/glibc-2.28 

I have tested with GCC 4.9.4 and glibc-2.27-r6 compiles just fine (without modifying USE_ATOMIC_COMPILER_BUILTINS). Compiling glibc-2.28-r5 fails with the following error:

In file included from ../sysdeps/nptl/internaltypes.h:23:0,
                 from ./pthreadP.h:30,
                 from pthread_mutex_getprioceiling.c:21:
pthread_mutex_getprioceiling.c: In function 'pthread_mutex_getprioceiling':
../include/atomic.h:672:4: error: read-only variable '__atg100_val' used as 'asm' output
    __asm ("" : "=r" (__atg100_val) : "0" (*(mem)));         \
    ^
pthread_mutex_getprioceiling.c:29:26: note: in expansion of macro 'atomic_load_relaxed'
   if (__builtin_expect ((atomic_load_relaxed (&(mutex->__data.__kind))

If I set USE_ATOMIC_COMPILER_BUILTINS to 1 in sysdeps/i386/atomic-machine.h glibc compiles successfully. I'm unsure if this is a recommened fix. (glibc-2.27-r6 compiles just fine and USE_ATOMIC_COMPILER_BUILTINS is zero.)

This bug seems to have been reported upstrem - see https://marc.info/?l=glibc-alpha&m=154482194923437&w=2 However, that report claims the issue was introduced first in 2.29. I haven't investigated if the problematic commit has been backported to 2.27.

Anyway, 2.28 should stil compile with GCC 4.9 and I would like to know what the correct fix is.

Thx for reading! 

PS! Support for GCC 4.9 seems to be have been dropped for 2.29 - see https://github.com/bminor/glibc/releases/tag/glibc-2.29

[Comment 1 Hans F. Nordhaug 2019-03-29 11:32:51 UTC]

A typo: "if the problematic commit has been backported to 2.27" => "if the problematic commit has been backported to 2.28".

[Comment 2 Sergei Trofimovich (RETIRED) 2019-03-29 22:25:56 UTC]

I think you still can build glibc with new gcc and have old gcc installed alongside and use it for other tools.

Note: <gcc-6 is masked and is not supported as a system compiler. Having said that we can apply patches to gcc or glibc if those are safe.

Please post full build.log and 'emerge --info'. Maybe that will shed some light as well.

[Comment 3 Hans F. Nordhaug 2019-04-08 06:22:55 UTC]

It turned out to be a misconception that we needed to build glibc with GCC 4.9.4 to make our (old) applications run. It was enough to compile a selection of other libraries with GCC 4.9.4. 

In other words, you can close this issue. Sorry about wasting your time. Other people with this issue (if any) at least has this report as starting point and a work-around.

[Comment 4 Sergei Trofimovich (RETIRED) 2019-04-08 06:57:54 UTC]

No problem.

[Comment 5 Sergei Trofimovich (RETIRED) 2019-10-13 09:31:22 UTC]

*** Bug 697554 has been marked as a duplicate of this bug. ***