On 23 Jan 2022 17:57, R. Diez wrote:
> > Mike Frysinger wrote:
> > [...]
> > there is only one set of top-level files.  they get manually synced from
> > gcc to the other projects by devs who notice & need the fixes.
> 
> OK, I gather that copying those files across from GCC is the standard practice.
> But why do we need to keep doing that in Newlib? According to the (outdated)
> cross toolchain build instructions, when combining the tree the GCC versions should prevail.

i don't understand what you're asking.  the top-level provides files that
newlib uses.  they need to be kept up-to-date.  see AC_CONFIG_AUX_DIR use
throughout the tree.

> It is not like anybody would take Newlib without GCC and use those top-level files (the
> 'configure' script) to build say just Newlib and Binutils, is it?

why not ?  i have a gdb/binutils dir that i link just newlib & libgloss
into.  the GNU simulator is part of those trees, and it pulls ABI info
out of newlib & libgloss.  being able to iterate on those parts without
rebuilding gcc is helpful.

> >> My guess is that GCC's build system is calling 'configure',
> >> 'make' etc. inside newlib/, and it does not really matter
> >> if the versions are a little different.
> >> Or is a lot of the build system really shared?
> 
> > Joel Sherrill wrote:
> > Based on how we always build, I'd say it is just invocation.
> 
> > Mike Frysinger wrote:
> > the contract at build time is `./configure`, and even if newlib had its script
> > generated with an old version of autoconf, it doesn't really change the API.
> > the top-level Makefile knows to `cd newlib && ./configure ...` and that will
> > work regardless of the autoconf version.
> 
> There seems to be consensus that the Autoconf version in Newlib does not matter,
> and that the "combined tree" building system interface is just invoking 'configure' and 'make' under newlib/.
> 
> Why do we need to fix the Autoconf version to 2.69 then? We could use the newer 2.71 for Newlib.

the top-level config/ pins to that version.  it also contains macros we utilize
(like the multilib logic).  if no one else is testing newer versions, it sounds
like pointless landmines for newlib.

conversely, what does autoconf 2.71 get us ?  i'm not aware of functionality in
there that we need or otherwise fixes/improves things for newlib specifically.

> How about the Automake version? The Automake version is not checked like the
> Autoconf version is, isn't it? The checked-in "Makefile.in" files were generated
> with Automake 1.15.1 from 2017-06-19, and the latest is 1.16.5 from 2021-10-03.
> 
> If we want to strictly keep in sync with GCC, shouldn't we check the exact Automake version too?

we pin the min version via AM_INIT_AUTOMAKE to 1.15.1.  you're right we don't
currently pin the maximum, it's more through everyone agreeing to use that
version.  if gcc et al had a macro to pin the automake version, we'd prob
leverage it too.

pinning the versions in general is meant to keep generated noise/conflicts
down between devs working on these projects, and to make expectations more
obvious to users.  if diff devs were using autoconf 2.68 & 2.69 to regen
and push changes, there would be a ton more noise, and conflicts would be
a lot more frequent when pulling git updates.  users tend to not be savvy
with autotools ... they just run whatever until things compile.  getting
support requests like "i tried to run autoconf-2.50 and it didn't work"
(or conversely, "i tried to run autoconf-2.100 and it didn't work") is a
waste of valuable dev time.  putting "we used xxx versions" into README
files has historically proven to be insufficient.

> > Mike Frysinger wrote:
> > the multilib multiplexing logic with libraries makes things a bit messier too.
> 
> Does the multilib multiplexing logic affect the interface between the combined
> tree build system and Newlib? Or does it require something special inside newlib/
> that would conflict with newer Autotools versions?

gcc's multilib logic expects a certain layout that newlib provides, and this is
simplified by using the same multilib configure+make logic.  this is space that
hasn't really been documented anywhere that i'm aware of, and can sometimes be
a bit fragile.  i've run into this at various times with diff targets and when
maintaining toolchain packages in distros.
-mike