This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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).

Agreed.

> * --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[012])        base_machine=cx0 machine=cx0/c30 ;;
> c4[04])         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.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]