On 22 Feb 2022 12:34, Jon Turney wrote:
> On 22/02/2022 11:31, Corinna Vinschen wrote:
> > On Feb 21 19:21, Mike Frysinger wrote:
> >> GNU ar has undocumented behavior where it doesn't dedupe its inputs if
> >> they're all on the same command line, so we have to dedupe ourselves.
> >> ---
> >> v2
> >> - use awk to dedupe the object list
> 
> I think this could still at least use a comment about how the ordering 
> of the inputs relates to which duplicate object are dropped and which 
> are kept.

i had updated the comment locally already and just hadn't posted it:
## GNU ar has undocumented behavior when specifying the same name multiple times
## in a single invocation, so we have to dedupe ourselves.  The algorithm here:
## - Generates the set of unique objects based on the basename.
## - Favors objects later in the list (since machine objects come last).
## - Outputs object list in same order as input for reproducibility.

> (I'm assuming cpu-specific ones are meant to be kept in preference to 
> generic routines, but how does this achieve that?)
> 
> > This seems to work.
> > 
> > However, what do we have to do in future to make sure the order is
> > always correct?

i've documented this in 3 places, so think it's fine.

(1) libc/Makefile.inc & (2) libm/Makefile.inc both have:
## The order of includes is important for two reasons:
## * The integrated documentation (chapter ordering).
## * Object overridding -- machine dir must come last.
## Do not change the order without considering the doc impact.

(3) in the heavily rewritten build documentation i sent out [1].
it's pending review from folks, so hasn't been merged yet.

> > And the heritic question: Wouldn't it be safer to keep the old
> > per-subdir lib.a logic?

i think this is a false dichotomy.  the lib.a logic has the same problem,
albeit it was never documented: if the order of SUBDIRS isn't maintained,
then the machine overrides do not work correctly.  if the order of the
lib.a unpacking was not done correctly, then the machine overrides do not
work correctly.  the fact that it's been "stable for so long" isn't due
to the code being written well (no offense), it's because it's been so
dense & undocumented that no one has wanted to touch it with a 3m pole :P.

> Considering the problem in the next larger context: why are we doing 
> this at all?
> 
> Is this just so the generic fenv routines are chewed on as they contain 
> the doc markup?  In which case it would be simpler to do that explicitly.
> 
> If it's so that a cpu- specific fenv doesn't need to provide all the 
> objects, well, that could be done explicitly as well, I think?

assuming you're asking about the machine-override logic specifically and
not "why am i changing the build system at all", then the current newlib
design supports more than fenv.  fortunately, i believe i already wrote
up all the docs you want :).  please give it a look and see if i missed
anything.
[1] https://sourceware.org/pipermail/newlib/2022/019275.html
-mike