OK, so it seems I need to give more information to clarify what I am trying to do.
I am not invoking or configuring gcc directly. I am creating debian source code packages which are then dispatched to launchpad.net, which then automatically compiles and builds my package based on the debian configuration files. I am trying to created a toolchain that does this automatically while also setting the znver1 optimisations automatically. As far as I can tell, the --with-arch= and --with-cpu= gcc configuration options set defaults, and do not enforce compilation with these options if a package specifically configures a different cpu or architecture, so correct me if I am wrong. Regardless, I do have those options set in the various versions of gcc in my toolchain, but I need gcc to ignore rogue packages that configure to a different x86 architecture. My PPAs only target znver1 for x86 code, so nothing breaks if my toolchain ignores other x86 architectures. Since I am trying to create an automatic toolchain, it would be much easier to have a gcc that ignores non-default x86 configuration options then it is to try to create a script that finds, catches, and corrects an upstream package that uses a non-default configuration. If the --with-arch= and --with-cpu= gcc configuration options cause gcc to ignore non-default configure options, then please, let me know. Otherwise, I would like someone to tell me if my proposed modification will work as I expect, and If someone has a better way, I need an explanation so I know if the proposed solution is going to work the way I want. On Fri, Mar 8, 2019 at 1:58 PM Jonathan Wakely <jwakely....@gmail.com> wrote: > > On Fri, 8 Mar 2019 at 11:28, Vanida Plamondon > <vanida.plamon...@gmail.com> wrote: > > > > I realise that, however, debian packages seem to use multiple build > > systems (automake, dh_automake, ninja, etc.), and have no standard > > (that is adhered to), for setting up each build environment. > > Additionally, some packages seem to throw their build configuration > > setup throughout multiple files that are difficult to pin down, and > > usually have little documentation. I am trying to set up a toolchain > > that automatically fetches upstream sources when updated, updates the > > changelog to reflect that the package is znver1 optimised, and > > automatically compiles the package with the znver1 optimisations. Even > > worse, many packages use different environmental variables, and some > > even unset some of such standard variables. > > > > This means I need to setup gcc so that any x86 code thrown at it is > > automatically compiled with znver1 optimisations to overcome these > > limitations. > > That's what the configure options Richi showed will do. > > N.B. he didn't say to use -march=znver1 when compiling with GCC, he > said to use --with-arch=znver1 when configuring GCC itself.
