Paul Eggert <egg...@cs.ucla.edu> writes: > On 2025-08-02 01:32, Pádraig Brady wrote: > >> it's worth mentioning run-time vs build-time checks. > > Yes, and this could be documented more. I installed the attached. > >> For reference I made some notes on various version compat at: >> http://pixelbeat/programming/linux_binary_compatibility.html > > I needed to use this URL: > > https://www.pixelbeat.org/programming/linux_binary_compatibility.html > >> the gnulib workaround isn't too onerous as SYS_BUFZISE_MAX is large, >> and I expect the glibc fix will be backported to glibc 2.41 systems >> promptly anyway. > > Yes, I went through similar thought processes. It didn't seem worth > the hassle to do the extra glibc runtime checks. Gnulib has always > used static checks for glibc versions, even in areas where this is > serious business (e.g., malloc misbehavior). So far, nobody has > reported an issue for this. Maybe people who build for older kernels > (which is dubious if you ask me) aren't building for older glibcs > (which is even more dubious). > > [2. text/x-patch; 0001-More-copy_file_range-commentary.patch]...
You can shorten sourceware (and gcc) bug URLs to: https://sourceware.org/PR123456 https://gcc.gnu.org/PR123456 if that is ever useful. The changes themselves look good. Really, c_f_r has been an API plagued with problems :(
