Language Selection

English French German Italian Portuguese Spanish

Minimum GCC Version Likely to Jump from 3.2 to 4.8

Submitted by Roy Schestowitz on Wednesday 11th of July 2018 03:09:04 PM Filed under
Development
GNU

The question of the earliest GCC compiler version to support for building the Linux kernel comes up periodically. The ideal would be for Linux to compile under all GCC versions, because you never know what kind of system someone is running. Maybe their company's security team has to approve all software upgrades for their highly sensitive devices, and GCC is low on that list. Maybe they need to save as much space as possible, and recent versions of GCC are too big. There are all sorts of reasons why someone might be stuck with old software. But, they may need the latest Linux kernel because it's the foundation of their entire product, so they're stuck trying to compile it with an old compiler.

However, Linux can't really support every single GCC version. Sometimes the GCC people and the kernel people have disagreed on the manner in which GCC should produce code. Sometimes this means that the kernel really doesn't compile well on a particular version of GCC. So, there are the occasional project wars emerging from those conflicts. The GCC people will say the compiler is doing the best thing possible, and the kernel people will say the compiler is messing up their code. Sometimes the GCC people change the behavior in a later release, but that still leaves a particular GCC version that makes bad Linux code.

Read more

»

More in Tux Machines

Openwashing: Zenko (Dual), Kong (Mere API) and Blackboard (Proprietary and Malicious)

Games: Descenders, War Thunder’s “The Valkyries”

Kernel: Virtme, 2018 Linux Audio Miniconference and Linux Foundation Articles

  • Virtme: The kernel developers' best friend
    When working on the Linux Kernel, testing via QEMU is pretty common. Many virtual drivers have been recently merged, useful either to test the kernel core code, or your application. These virtual drivers make QEMU even more attractive.
  • 2018 Linux Audio Miniconference
    As in previous years we’re trying to organize an audio miniconference so we can get together and talk through issues, especially design decisons, face to face. This year’s event will be held on Sunday October 21st in Edinburgh, the day before ELC Europe starts there.
  • How Writing Can Expand Your Skills and Grow Your Career [Ed: Linux Foundation article]
    At the recent Open Source Summit in Vancouver, I participated in a panel discussion called How Writing can Change Your Career for the Better (Even if You don't Identify as a Writer. The panel was moderated by Rikki Endsley, Community Manager and Editor for Opensource.com, and it included VM (Vicky) Brasseur, Open Source Strategy Consultant; Alex Williams, Founder, Editor in Chief, The New Stack; and Dawn Foster, Consultant, The Scale Factory.
  • At the Crossroads of Open Source and Open Standards [Ed: Another Linux Foundation article]
    A new crop of high-value open source software projects stands ready to make a big impact in enterprise production, but structural issues like governance, IPR, and long-term maintenance plague OSS communities at every turn. Meanwhile, facing significant pressures from open source software and the industry groups that support them, standards development organizations are fighting harder than ever to retain members and publish innovative standards. What can these two vastly different philosophies learn from each other, and can they do it in time to ensure they remain relevant for the next 10 years?

Red Hat: PodCTL, Security Embargos at Red Hat and Energy Sector

  • [Podcast] PodCTL #50 – Listener Mailbag Questions
    As the community around PodCTL has grown (~8000 weekly listeners) we’ve constantly asked them to give us feedback on topics to discuss and areas where they want to learn. This week we discussed and answered a number of questions about big data and analytics, application deployments, routing security, and storage deployment models.
  • Security Embargos at Red Hat
    The software security industry uses the term Embargo to describe the period of time that a security flaw is known privately, prior to a deadline, after which time the details become known to the public. There are no concrete rules for handling embargoed security flaws, but Red Hat uses some industry standard guidelines on how we handle them. When an issue is under embargo, Red Hat cannot share information about that issue prior to it becoming public after an agreed upon deadline. It is likely that any software project will have to deal with an embargoed security flaw at some point, and this is often the case for Red Hat.
  • Transforming oil & gas: Exploration and production will reap the rewards
    Through advanced technologies based on open standards, Red Hat deliver solutions that can support oil and gas companies as they modernize their IT infrastructures and build a framework to meet market and technology challenges. Taking advantage of modern, open architectures can help oil and gas providers attract new customers and provide entry into markets where these kinds of services were technologically impossible a decade ago.

More on Tux Machines: About ● Gallery ● Forum ● Blogs ● Search ● News ● RSS Feed

Part of Bytes Media ● Sister sites below.

TechBytes Techrights button

Powered by Drupal, an open source content management system

Content available under CC-BY-SA CC

© by original authors

Powered by CentOS 6.5 (GNU/Linux), Varnish, and Drupal 6