On Thu, Jan 30, 2020 at 11:54:31AM -0700, Alan Feuerbacher via blfs-support wrote: > On 1/30/2020 11:22 AM, Pierre Labastie via blfs-support wrote: > > Le 30/01/2020 à 17:19, Alan Feuerbacher via blfs-support a écrit : > > > On 1/29/2020 8:52 PM, Ken Moffat via blfs-support wrote: > > I think you have missed this warning on the kernel page: > > " Warning > > > > The headers in the system's include directory (/usr/include) should always > > be > > the ones against which Glibc was compiled, that is, the sanitised headers > > installed in Section 5.6, “Linux-5.4.13 API Headers”. Therefore, they should > > never be replaced by either the raw kernel headers or any other kernel > > sanitized headers. " > > I saw that, but may have interpreted its meaning wrongly. > > I just replied to Bruce on this issue and asked for clarification. > > So let me recap: Upon first building LFS, I built linux-5.4.6 and its > headers, and glibc-2.30. > > Then I built the headers for linux-5.4.8, rebuilt glibc-2.30 and built > linux-5.4.8. > > Then I built the headers for linux-5.4.13, rebuilt glibc-2.30 and built > linux-5.4.13. > > So in upgrading linux-5.4.6 -> 5.4.8 -> 5.4.13 should I have left glibc-2.30 > alone? If so, then glibc would not have been compiled against 5.4.13 > headers. Would this not contradict the above Warning? This is the source of > my confusion. >
The link, as with all links within LFS and BLFS, happens to contain the current version of the package. The point is that once you have installed sanitized headers in /usr/include you do NOT update them. > > I usually upgrade all the packages on my blfs systems when new versions come > > along, to test what can go wrong. I've even upgraded sometimes upgraded > > glibc. > > But I've never upgraded the kernel headers in /usr/include. That may be > > needed > > for a long term system, but since I rebuild everything anyway every 6 months > > to test the rc's, I've never seen any issue with keeping the initial kernel > > headers. New headers might show that the kernel has new facilities (new namespaces, 32-bit time fixes for y2038, openat2 in 5.6, whatever). Glibc normally lags the kernel in enabling new things, most packages lag glibc. With unchanged headers, what used to work should still work. ĸen -- The politics of wizardry were either very simple, and resolved by someone ceasing to breathe, or as complex as one ball of yarn in a room with three bright-eyed little kittens. - Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
