On Mon, Jan 16, 2023 at 9:01 PM Jakub Jelinek <jakub@xxxxxxxxxx> wrote:
>
> On Mon, Jan 16, 2023 at 08:42:32PM +0100, Miro Hrončok wrote:
> > On 16. 01. 23 20:30, Siddhesh Poyarekar wrote:
> > > If it is for distribution packages then I reckon the flags should be
> > > as close as possible for the mere reason of consistency within the
> > > distribution.
> >
> > Nope, the individual packages with extension modules all¹ use the
> > %{build_cflags} flags by default.
> >
> > ¹: Technically they are required to and it is really hard not to do that noways.
> >
> > > If they're used for custom built modules (e.g. through
> > > a tool that python auto-generates to build modules), then a very small
> > > subset of the above flags would be necessary to retain binary
> > > compatibility; you should be able to remove most of it.
> >
> > That is what I thought. Thank you.
>
> Options like -m64/-m32 are ABI changing (but in %{optflags} these days
> mostly uselessly because we don't usually cross-compile and gcc defaults to
> those), -fsigned-char/-funsigned-char (I see it in redhat-rpm-config but
> for armv3l/armv4b/armv4l which we don't build - in the past it was used on
> more platforms) would be ABI changing, again on arm the various
> -march=, -mfpu=, -mfloat-abi=, -mabi= options (but note that e.g. on most
> other arches the -march= options aren't ABI changing, one just needs hw with
> all the ISAs required by the built code), -fexceptions could be considered
> partly ABI changing (at least say pthread_cancel through some objects
> built with -fexceptions and others without that or with -fno-exceptions
> will not destruct everything that should be after reaching frames without
> it or similarly throwing C++ exceptions won't work well), so I'd suggest
> to keep that one in. -mlong-double-{64,128} would be ABI changing, but
> we just use compiler's default. -mabi={ibm,ieee}longdouble are ABI changing
> on ppc64le too, but again we use the compiler defaults.
> If you look at gcc documentation, many options are marked as ABI changing,
> but I don't see them used in our %{optflags}...
>
> So, when talking about options actually in use currently in f36/f37/f38 on
> Fedora supported arches, I think -fexceptions is the only one I'd list.
Isn't the problem here that building Python extensions needs to work
correctly in two - possibly conflicting - scenarios:
- in RPM packages, where using system compiler flags is a MUST
- when user installs Python packages manually, for example with pip in
a venv, where using system compiler flags isn't necessary (or
necessarily a good idea)
Just dropping everything but `-fexceptions` would certainly violate
Packaging Guidelines (i.e. packages not getting built with default
compiler and hardening flags) in the first scenario, wouldn't it?
Fabio
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
