[PATCH/submitted,01/10] sim: ppc: move long long test to top-level
Checks
Commit Message
While the sim code doesn't utilize HAVE_LONG_LONG itself, other code
(like libiberty) seem to, so check for it in the top-level for all
ports to leverage.
---
sim/config.h.in | 3 +
sim/configure | 14 +-
sim/m4/sim_ac_platform.m4 | 1 +
sim/ppc/config.in | 33 --
sim/ppc/configure | 618 +-------------------------------------
sim/ppc/configure.ac | 2 -
6 files changed, 18 insertions(+), 653 deletions(-)
Comments
>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
Mike> While the sim code doesn't utilize HAVE_LONG_LONG itself, other code
Mike> (like libiberty) seem to, so check for it in the top-level for all
Mike> ports to leverage.
FWIW gdb solves this problem with gdb/libiberty.m4. Really this is
something that should be provided or fixed in a better way by libiberty.
Tom
On 09 Jan 2024 07:33, Tom Tromey wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
>
> Mike> While the sim code doesn't utilize HAVE_LONG_LONG itself, other code
> Mike> (like libiberty) seem to, so check for it in the top-level for all
> Mike> ports to leverage.
>
> FWIW gdb solves this problem with gdb/libiberty.m4. Really this is
> something that should be provided or fixed in a better way by libiberty.
in the mean time, seems like this file should get moved to gdbsupport/ since
gdb, gdbserver, and gdbsupport all rely on it ? then it'd be more reasonable
for sim to include that directly.
thinking beyond that, config/acinclude.m4 has CYG_AC_PATH_LIBERTY, but no one
seems to be using that. should we add config/libiberty.m4 and move all this
logic there ? and prob have it take care of exporting a LIBIBERTY_LIB var ?
-mike
>> FWIW gdb solves this problem with gdb/libiberty.m4. Really this is
>> something that should be provided or fixed in a better way by libiberty.
Mike> in the mean time, seems like this file should get moved to gdbsupport/ since
Mike> gdb, gdbserver, and gdbsupport all rely on it ? then it'd be more reasonable
Mike> for sim to include that directly.
It's fine by me.
Mike> thinking beyond that, config/acinclude.m4 has CYG_AC_PATH_LIBERTY, but no one
Mike> seems to be using that. should we add config/libiberty.m4 and move all this
Mike> logic there ? and prob have it take care of exporting a LIBIBERTY_LIB var ?
You'd probably want to open this discussion on gcc-patches.
I tend to think if bigger changes are being made here, then my
preferences would be:
1. Just avoid using any configure results in libiberty header files,
perhaps by relying on more recent standard features.
2. Have libiberty namespace its configure results (i.e., rename them
from the generic HAVE_* to LIBIBERTY_* or whatever) and provide /
install a "libiberty-config.h".
3. What we have now, to me clearly the worst solution of the bunch.
Tom
@@ -132,6 +132,7 @@ AC_CHECK_TYPES(socklen_t, [], [],
[#include <sys/types.h>
#include <sys/socket.h>
])
+AC_CHECK_TYPES([long long])
dnl Some System V related checks.
AC_CACHE_CHECK([if union semun defined],
@@ -382,8 +382,6 @@ if test $ac_cv_struct_statfs = yes; then
[Define if struct statfs is defined in <sys/mount.h>])
fi
-AC_CHECK_TYPES(long long)
-
AC_SUBST(sim_line_nr)
AC_SUBST(sim_opcode)
AC_SUBST(sim_switch)