Commit Graph

7 Commits

Author SHA1 Message Date
Mike Frysinger 7edb25725d libgloss: switch to standard AC_PROG_CC
Now that we use AC_NO_EXECUTABLES, and we require a recent version of
autoconf, we don't need to define our own copies of these macros.  So
switch to the standard AC_PROG_CC.
2022-02-24 19:06:21 -05:00
Mike Frysinger 67c600b995 libgloss: restore multilib settings in subdir makefiles
Commit 754f8def0d ("libgloss: merge stub
arch configure scripts up a level") had an unintended side-effect: the
MULTI* variables in the Makefiles no longer get rewritten at configure
time in the subdirs.  Only the top-level Makefile still is.  This is
because the configure integration of multilib (both the way libgloss
did it manually and the way AM_ENABLE_MULTILIB does it) only rewrites
"Makefile".

We could try propagating the MULTI* variables from libgloss/Makefile
down via FLAGS_TO_PASS, but this runs into a limitation: the multilib
logic uses this variable to switch from libgloss/ to each multilib
libgloss/, and libgloss uses this variable to enter subdirectories.
The latter we want, but the former ends up overridding the Makefile
environment.  We could side-step that with some GNU Make directives,
but it feels like we're getting a bit too deep down the rabbit hole.

Instead, let's call config-ml.in ourselves for each subdir Makefile
that the top-level configure generates.  This restores the previous
behavior and should be less risky in general.

This logic should be unnecessary when/if we switch libgloss over to
a non-recursive Automake build (since all build+install settings are
in the single libgloss/Makefile), but it'll be a while before we can
land that rework, so let's fix this up now.
2022-02-04 19:33:29 -05:00
Mike Frysinger 8622002ffc libgloss: move to ../config/multi.m4 for multilib logic
The current libgloss multilib logic is almost exactly the same as the
config/multi.m4, and the differences should be minor, so switch over
to that to delete custom logic on ourside.

The insertions here look larger and that's because none of the scripts
were declaring --enable-multilib explicitly even though they checked the
flag and changed behavior.
2022-02-01 23:07:11 -05:00
Mike Frysinger a100e80fc9 require autoconf-2.69 exactly
The newlib & libgloss dirs are already generated using autoconf-2.69.
To avoid merging new code and/or accidental regeneration using diff
versions, leverage config/override.m4 to pin to 2.69 exactly.  This
matches what gcc/binutils/gdb are already doing.

The README file already says to use autoconf-2.69.

To accomplish this, it's just as simple as adding -I flags to the
top-level config/ dir when running aclocal.  This is because the
override.m4 file overrides AC_INIT to first require the specific
autoconf version before calling the real AC_INIT.
2022-01-14 15:24:33 -05:00
Mike Frysinger 7f8fa1de4f libgloss: hardcode AC_CONFIG_AUX_DIR path
In order to transition to automake, we have to use hardcoded paths in
the AC_CONFIG_AUX_DIR macro call (since automake evaluates the path
itself, and doesn't expand vars), so simplify all the calls here.
2022-01-10 19:50:35 -05:00
Mike Frysinger 873da400e0 libgloss: regenerate aclocal.m4 & configure w/newer versions
Regenerate the files using automake-1.15 & autoconf-2.69 to match the
binutils/gdb/gcc projects.  Ran:

libgloss $ find -name configure.ac -printf '%h\n' | while read d; do
  (cd $d; export WANT_AUTOCONF=2.69 WANT_AUTOMAKE=1.15;
   aclocal-1.15 -I.. && autoconf-2.69); done
2021-11-06 14:14:50 -04:00
Mike Frysinger 920617998e libgloss/newlib: rename configure.in to configure.ac
The .in name has been deprecated for a long time in favor of .ac.
2021-09-13 10:14:37 -04:00