Correct. It's hard to nail down the right terminology when I'm learning by doing. I want GCC to ignore x86 flags that aren't znver1, and keep znver1 as the default.
On Fri, Mar 8, 2019, 3:44 PM Jonathan Wakely <jwakely....@gmail.com> wrote: > On Fri, 8 Mar 2019 at 22:00, Vanida Plamondon > <vanida.plamon...@gmail.com> wrote: > > > > 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. > > (If you're creating a toolchain then surely you're configuring GCC.) > > > 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. > > If by "configures a different cpu or architecture" you mean "uses the > -march option when invoking GCC" then you're correct. > > Using --with-arch=znver1 will make GCC automatically select that > architecture. But it won't prevent that automatic selection being > overridden by an explicit -march option. > > > > 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. > > Yes, that does seem simpler. > > > If the --with-arch= and --with-cpu= gcc configuration options cause > > gcc to ignore non-default configure options, then please, let me know. > > I find this use of "configure options" confusing too. You're talking > about flags passed to GCC when invoking it, not "configure options", > right? >
