[Bug other/102665] New: ELF-specific configure flags should be rejected on non-ELF platforms

[Bug other/102665] New: ELF-specific configure flags should be rejected on non-ELF platforms

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665

            Bug ID: 102665
           Summary: ELF-specific configure flags should be rejected on
                    non-ELF platforms
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---

Specifically, --enable-gnu-unique-object and --enable-secureplt are
ELF-specific configure flags, and yet are accepted anyways by the top-level
configure script on non-ELF platforms with no complaint. The help string for
--enable-gnu-unique-object at least mentions that it's ELF-specific, but the
one for --enable-secureplt doesn't, so that's another thing that could be
updated.

[Bug other/102665] ELF-specific configure flags should be rejected on non-ELF platforms

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=34422

--- Comment #1 from Eric Gallager <egallager at gcc dot gnu.org> ---
bug 34422 is semi-related, since it's also a case of a configure flag that
should be rejected where it won't work.

[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org

--- Comment #2 from Eric Gallager <egallager at gcc dot gnu.org> ---
(this is something discussion with Iain Sandoe prompted me to file, btw, so I'm
cc-ing him on this)

[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-05-24
           Assignee|unassigned at gcc dot gnu.org      |egallager at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1

--- Comment #3 from Eric Gallager <egallager at gcc dot gnu.org> ---
Mine.

[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665

--- Comment #4 from Eric Gallager <egallager at gcc dot gnu.org> ---
Hm, looking in gcc/configure.ac (where these are defined), it looks like
there's a bunch of other flags that this bug could apply to, too...

[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Eric Gallager from comment #4)
> Hm, looking in gcc/configure.ac (where these are defined), it looks like
> there's a bunch of other flags that this bug could apply to, too...

Note that I would try to clarify:

It is my understanding that the purpose of configure is to isolate the end user
from having to know about all the nasty little nooks and crannies of their
target.  As such it is not a "maintainer preference" to avoid end user having
to manipulate many such options but, rather, that if we reach that situation,
then the configure script is not doing its job and needs work.

As far as I understand things the right behaviour of configure is to choose a 
correct default value for each option based on the target.  The way that the
options work it is usually possible to ignore one for a specific target if it
does not apply at all.

Therefore:

1. making sure defaults are correct is valuable

2. perhaps just ignoring ELF-specific options (for Darwin)is useful (you could,
even diagnose that the option has been ignored if the user attempts to set it).

3. As you have noted, there are quite likely more options that
could/should/maybe already are ignored for Darwin.

[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665

--- Comment #6 from Eric Gallager <egallager at gcc dot gnu.org> ---
WIP: I stubbed in a start on this in my autotools-tinkering branch a bit:
https://github.com/gcc-mirror/gcc/commit/c2caa289485edb40eddcd240a7fc655cfd7c38ba
(it's got some unrelated parts in it that I'll need to strip out again when
cherry-picking it over to my branch for this PR, though...)

[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102665

--- Comment #7 from Eric Gallager <egallager at gcc dot gnu.org> ---
Making some more progress on this:
https://github.com/gcc-mirror/gcc/compare/master...cooljeanius:gcc:me/PR102665
Some notes:
- There are a lot of these; I'm not quite sure how many to include in a single
patch, or where I should stop...
- I'm currently testing platform based on target, but I'm not quite sure if
that's correct? Are these target flags or host flags?
- All I've done so far has been to test to make sure that the flags are
properly rejected on platforms where they're unsupported; I'd appreciate it if
people could help with testing that they're still accepted on platforms where
they're supposed to be accepted, though...