Stuart Henderson wrote in
 <yeawupyfneoez...@symphytum.spacehopper.org>:
 |On 2021/03/08 21:55, Steffen Nurpmeso wrote:
 |> Steffen Nurpmeso wrote in
 |>  <20210308200314.r794j%stef...@sdaoden.eu>:
 |>|Stuart Henderson wrote in
 |>| <yezuykzcmgxr7...@symphytum.spacehopper.org>:
 |>||On 2021/03/08 18:53, Steffen Nurpmeso wrote:
 |>||> Steffen Nurpmeso wrote in
 |>||>  <20210224143220.o1zwb%stef...@sdaoden.eu>:
 |>||>|Update to v14.9.22 to unbreak a closefrom(2) / close_range(2)
 |>||>|brain damage of mine.
 |>||> 
 |>||> I just got an according bug report from Predrag regarding this.
 |>||> Dependent on what you do, version 14.9.21 is truly _broken_, and
 |>||> 14.9.22 really should replace 14.9.21 wherever possible, please.
 |>| ....
 |>||Committed.
 |>|
 |>|Thank you very much for this, Stuart.
 |>|
 |>||Can you advise how to tell the complicated make-config script how to
 |>||respect ports CFLAGS setting for compiler optimization please?
 |>|
 |>|If it is only optimization one could either overwrite it by
 |>|passing an additional EXTRA_CFLAGS=-O1 or similar to overwrite it,
 |>|or instead pass cc_maxopt=[0123] (this i have not tested for years
 |>|hmmm .. but still works).  Note that higher than -O3 is not
 |>|supported, if you want this then you have to go the EXTRA_CFLAGS
 |>|way.  (-Os also not built-in, it also seems badly maintained in,
 |>|granted gcc, upstream and caused inlining problems in the past
 |>|(AlpineLinux package).
 |> 
 |> Well, i mean, selectively picking something out of original
 |> $CFLAGS automatically is not supported, on the other hand.  Does
 |> any build system support that?  I.e., only adding warnings and
 |> hardening flags etc. _onto_ the otherwise unchanged original
 |> $CFLAGS?  Is it that would you mean?  This is i think an
 |> interesting suggestion i will try to address in the future, and
 |> ship with the next update of this package, then.
 ...
 |It's fairly common for software to add warnings/include paths/etc
 |after a provided CFLAGS, or sometimes via another variable (some use
 |COPTFLAGS). Where that's not supported, in most cases it's a simple
 |matter of patching a Makefile to remove -O3 etc but it's a bit more
 |complex here.

Well i mean the package could reinstantiate the OPT_AUTOCC=no that
i think William Yodlowsky introduced years ago, then the builder
is absolutely free to define whatever she desires.  I personally
have always been of the opinion that all the warning options,
stack guards, PIE, let alone the terrible retpoline that i really
refrain from uncommenting, as well as the noexecstack that
i personally could only dig if it were execstack on request,
should not be needed at all in shipout code.  I only ever used
-fno-exceptions -fno-rtti myself, but somehow CPU cycles have to
be wasted it seems.  Sandboxing we do not support yet, it requires
a program redesign.  At least we have OPT_AUTOCC_STACKPROT to get
rid of that, but it is on by default, you know.  Indifference has
won won won.

 |Trying EXTRA_CFLAGS it's nearly what's needed, though it relies on
 |the user setting an alternative -O to override the one added in
 |make-config.sh, you can't e.g. set EXTRA_CFLAGS="" to build with no
 |-O flag at all.
 |
 |Ports on OpenBSD (and I believe also FreeBSD) are generally meant to use
 |OS defaults or user settings via the standard interface e.g. "make
 |CFLAGS=-O0" etc, when building the port. When dealing with a collection
 |of thousands of programs, it's helpful to have standard interfaces like
 |this rather than have to figure out what's needed for each individual
 |port.

By the way, what actual optimization issue do you have.
But yeah, people get understandably frustrated without a -march=,
i apologise.

So i have implemented VAL_AUTOCC=, which for now offers
add_options,bind_now,pie,stackprot,fortify selections, where the
default is bind_now,pie,stackprot,fortify, and i would change the
port to use add_options,bind_now,pie,stackprot when the next
version is released.  We cannot do FORTIFY because that requires
optimization to be enabled, which can no longer be guaranteed.
Thanks for the suggestion Stuart.

Ciao from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Reply via email to