This is the mail archive of the
mailing list for the glibc project.
Re: Should --enable-bounded be removed?
> * Conditionals for non-ELF object formats (note I recently removed the
> dead AIX support from ports, there's no need for the --with-xcoff
> configure option or aix* case in configure.in now).
> * --enable-omitfp (GCC enables -fomit-frame-pointer by default at
> appropriate -O levels nowadays when appropriate for the target and with
> DWARF debug info it does not cause problems with debugging).
Agreed. If anybody wants to control it explicitly, they can set CFLAGS
when they run configure.
> * Some relics of support for pre-C90 compilers such as use of __const
> instead of plain const in some headers.
In installed headers I think we don't want to break -traditional if it
worked before. So there is no real reason to change these.
> * Support for Linux kernel versions prior to 2.6.0 final, in
> arch_minimum_kernel settings, kernel-features.h and places testing (in
> code only used with Linux) __ASSUME_* macros for features added (for all
> architectures) by 2.6.0. NPTL means that glibc effectively requires 2.6
> and has done so for years (though some distributions may have backported
> support to 2.4 kernels, I don't think those should be considered relevant
> to future glibc releases).
I'm inclined to agree with this, but I'm not really positive that nobody is
using pre-2.6 kernels. Let's have something like a wiki page of deprecated
stuff slated for removal and let it stew a bit there before doing this.
> * There's a case in configure.in that includes a whole series of
> architectures with no current glibc support:
> a29k | am29000) base_machine=a29k machine=a29k ;;
> c3) base_machine=cx0 machine=cx0/c30 ;;
> c4) base_machine=cx0 machine=cx0/c40 ;;
> m88???) base_machine=m88k machine=m88k/$machine ;;
> m88k) base_machine=m88k machine=m88k/m88100 ;;
Indeed. I'm pretty sure we've done things right by now so that add-on
preconfigure or something can supply this. So there's no reason to keep
such cruft around even if ports were to show up one day.
> and another similarly irrelevant bit of code:
> # Make sco3.2v4 become sco3.2.4 and sunos4.1.1_U1 become sunos4.1.1.U1.
> os="`echo $os | sed 's/\([0-9A-Z]\)[v_]\([0-9A-Z]\)/\1.\2/g'`"
This is sort of generically applicable and generally harmless.
> and then most of the case over $os except for the gnu* and linux* cases,
> and quite a bit of what follows.
I'm fine with removing some such stuff if everything that ever worked can
still be supported by add-ons.
> (Ideally I think architecture cases should generally be avoided in
> architecture-independent configure scripts; that is, the non-obsolete
> architecture cases for libc architectures would move to subdirectory
> scripts in a similar way to that used for ports. And I'd apply the same
> to kernel-features.h: again, I think the separation into
> architecture-specific files used for ports would be a better approach for
> libc as well.)
I concur with the general sentiment. But we need to look at the details
case by case.