Skip to contentSkip to conversation

docs/manual: gcc 4.4 is the lowest we are known to work with

PATCH New Yann E. MORIN 4 participants 6 messages Aug 5, 2018 – Aug 13, 2018

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 docs/manual: gcc 4.4 is the lowest we are known to work with

gcc-2.95 is old. No, it is not old; it is antediluvian.

The odlest gcc version we are testing against is gcc-4.4 (on Holiss' autobuilder using RHEL6.5).

Update the manual accordingly.

Cc Thomas Petazzoni <[email protected]>
Cc Hollis Blanchard <[email protected]>
---
 docs/manual/prerequisite.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
docs/manual/prerequisite.txt +2 -2
index 110fab41fd..66e1b88f16 100644
@@ -23,8 +23,8 @@ between distributions).
 ** +make+ (version 3.81 or any later)
 ** +binutils+
 ** +build-essential+ (only for Debian based systems)
-** +gcc+ (version 2.95 or any later)
-** `g++` (version 2.95 or any later)
+** +gcc+ (version 4.4 or any later)
+** `g++` (version 4.4 or any later)
 ** +bash+
 ** +patch+
 ** +gzip+
Signature · 1 line
2.14.1
#1 lore raw

PATCH 1/1 docs/manual: gcc 4.4 is the lowest we are known to work with

All,

Quoted 6 lines · Yann E. MORIN

gcc-2.95 is old. No, it is not old; it is antediluvian.

The odlest gcc version we are testing against is gcc-4.4 (on Holiss' autobuilder using RHEL6.5).

Any suggestions if we keep the minimum host compiler requirement at 4.4, how should I address the below build failures with "error:
'__ATOMIC_ACQUIRE' undeclared " on the RHEL6.5 autobuilder?
http://autobuild.buildroot.net/?reason=host-libselinux-2.7

If this was a more recent compiler version issue, I'd dig into the package and look at up-streaming a compatibility ifdef check.

Matt

#2 lore raw

PATCH 1/1 docs/manual: gcc 4.4 is the lowest we are known to work with

Hi Matt,

Quoted 8 lines · Matthew Weber
Quoted 6 lines · Yann E. MORIN

gcc-2.95 is old. No, it is not old; it is antediluvian.

The odlest gcc version we are testing against is gcc-4.4 (on Holiss' autobuilder using RHEL6.5).

Quoted 7 lines

Any suggestions if we keep the minimum host compiler requirement at 4.4, how should I address the below build failures with "error:
'__ATOMIC_ACQUIRE' undeclared " on the RHEL6.5 autobuilder?
http://autobuild.buildroot.net/?reason=host-libselinux-2.7

If this was a more recent compiler version issue, I'd dig into the package and look at up-streaming a compatibility ifdef check.

The atomic operations were introduced in gcc version 4.7:

https://gcc.gnu.org/gcc-4.7/changes.html

baruch

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
#3 lore raw

PATCH 1/1 docs/manual: gcc 4.4 is the lowest we are known to work with

Baruch,

Quoted 17 lines · Baruch Siach

Hi Matt,

Quoted 13 lines · Matthew Weber
Quoted 6 lines · Yann E. MORIN

gcc-2.95 is old. No, it is not old; it is antediluvian.

The odlest gcc version we are testing against is gcc-4.4 (on Holiss' autobuilder using RHEL6.5).

Any suggestions if we keep the minimum host compiler requirement at 4.4, how should I address the below build failures with "error:
'__ATOMIC_ACQUIRE' undeclared " on the RHEL6.5 autobuilder?
http://autobuild.buildroot.net/?reason=host-libselinux-2.7

Quoted 7 lines
Quoted 2 lines

If this was a more recent compiler version issue, I'd dig into the package and look at up-streaming a compatibility ifdef check.

The atomic operations were introduced in gcc version 4.7:

https://gcc.gnu.org/gcc-4.7/changes.html

Yeah.

#4 lore raw

PATCH 1/1 docs/manual: gcc 4.4 is the lowest we are known to work with

In reply to Matthew Weber
Quoted 8 lines · Matthew Weber

Any suggestions if we keep the minimum host compiler requirement at 4.4, how should I address the below build failures with "error:
'__ATOMIC_ACQUIRE' undeclared " on the RHEL6.5 autobuilder?
http://autobuild.buildroot.net/?reason=host-libselinux-2.7

If this was a more recent compiler version issue, I'd dig into the package and look at up-streaming a compatibility ifdef check.

I'm not an expert in this area, but I'm surprised atomic operations are needed in addition to the pthread_mutex_lock. See these comments, for example:
https://stackoverflow.com/questions/24137964/does-pthread-mutex-lock-contains-memory-fence-instruction
. AFAIK, these atomic operations could be replaced with their native equivalents.

That said, I'm not using SELinux, and even if I were I wouldn't care too much about the host binaries, so I'm not interested in a lengthy email debate about compiler optimizations, processor pipelines, atomic operations, and memory barriers. :-) If we're not comfortable with removing them altogether, then I think we could use the older "__sync" builtins
<https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Atomic-Builtins.html>
instead. Going for correctness instead of performance:

build/host-libselinux-2.7/src/label_file.h 2018-08-09 09:50:47.036960057 -0700 renamed from build/host-libselinux-2.7/src/label_file.h.orig 2018-08-09 09:47:46.432960085 -0700 +18 -0
@@ -349,8 +349,14 @@
          * init_routine does not take a parameter, it's not possible
          * to use, so we generate the same effect with atomics and a
          * mutex */
+#ifdef __ATOMIC_ACQUIRE
         regex_compiled =
                 __atomic_load_n(&spec->regex_compiled, __ATOMIC_ACQUIRE);
+#else
+       /* GCC <4.7 */
+       __sync_synchronize();
+       regex_compiled = spec->regex_compiled;
+#endif
         if (regex_compiled) {
                 return 0; /* already done */
         }
@@ -358,8 +364,14 @@
         __pthread_mutex_lock(&spec->regex_lock);
         /* Check if another thread compiled the regex while we waited
          * on the mutex */
+#ifdef __ATOMIC_ACQUIRE
         regex_compiled =
                 __atomic_load_n(&spec->regex_compiled, __ATOMIC_ACQUIRE);
+#else
+       /* GCC <4.7 */
+       __sync_synchronize();
+       regex_compiled = spec->regex_compiled;
+#endif
         if (regex_compiled) {
                 __pthread_mutex_unlock(&spec->regex_lock);
                 return 0;
@@ -402,7 +414,13 @@
         }
  
         /* Done. */
+#ifdef __ATOMIC_RELEASE
         __atomic_store_n(&spec->regex_compiled, true, __ATOMIC_RELEASE);
+#else
+       /* GCC <4.7 */
+       spec->regex_compiled = true;
+       __sync_synchronize();
+#endif
         __pthread_mutex_unlock(&spec->regex_lock);
         return 0;
  }

If there's general agreement with this approach, I can submit it as a Buildroot patch.

Hollis Blanchard
Mentor Graphics Emulation Division

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180809/f849b621/attachment.html>

#5 lore raw

PATCH 1/1 docs/manual: gcc 4.4 is the lowest we are known to work with

All,

Quoted 9 lines · Hollis Blanchard

On 08/09/2018 06:08 AM, Matthew Weber wrote:

Any suggestions if we keep the minimum host compiler requirement at 4.4, how should I address the below build failures with "error:
'__ATOMIC_ACQUIRE' undeclared " on the RHEL6.5 autobuilder?
http://autobuild.buildroot.net/?reason=host-libselinux-2.7

I've submitted this patch to require at least 4.7. I don't have a target to test this. Hollis, would you mind trying it on your RHEL 6.5?

http://patchwork.ozlabs.org/patch/957001/