Re: Defining macros for function symbol versions

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Wed, 2016-12-07 at 16:14 +0000, Joseph Myers wrote:
> I have a possible use for an automatically-generated header (used in the 
> build, not installed) that defines macros for the first symbol version at 
> which each symbol was added.  E.g.
> 
> #define FIRST_VERSION_libm_fmaxl GLIBC_2_1
> 
> The place in the build that seems closest to having this information is 
> versions.awk, where it reads the Versions.tmp file to generate .map files 
> for each library.  Does it seem reasonable to make this code also process 
> the lists of symbol names in Versions.tmp to generate a corresponding 
> header?
> 
> My motivation is as follows.  Consider 
> sysdeps/ieee754/ldbl-opt/math-type-macros-double.h.  It has a long list of 
> LDOUBLE_*_libm_version macros for various functions defined using 
> type-generic templates, the purpose of which is to use in 
> LONG_DOUBLE_COMPAT tests "was this function originally added before glibc 
> supported long double != double on this platform?".  Those could be 
> replaced by the generated FIRST_VERSION_* macros.
> 
> That's a first use for such a header.  With additional macros 
> automatically defined for each function, there are further uses.  Consider 
> how ldbl-opt has its own versions of recently added long double functions 
> that use type-generic templates, to avoid math-type-macros-ldouble.h using 
> long_double_symbol for them (s_nextdownl.c s_canonicalizel.c w_llogbl.c).  
> Requiring additional files like that for new functions is not ideal.  I 
> imagine math-type-macros-ldouble.h instead doing something like
> 

This all seems to be very disruptive change, this late in the 2.25
cycle.

Many of your restructuring and TS 18661-* related changes have caused
churn that required constant forward porting and re-forward porting of
our float128 patch set.

Given that TS 18661 is an emerging stand that very few applications need
or intend to use. It seems prudent to defer further TS 18661 work until
2.26 and allow our float128 (which you specificity asked for) to proceed
and deliver key components before 2.25 closes.

This will set up for completing the float128 work for powerpc and more
of the TS 18661 changes in 2.26

Thanks