On 1/30/2020 1:49 PM, Ken Moffat via blfs-support wrote:
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.
Only when new features come along that glibc needs to be aware of, but I
am with Alan on this one. If I'm rebuilding or updating glibc, I'm going
to update the kernel headers at the same time - this is the only time
that you should update the headers (and only if you are keeping a long
running system). Most of us do not maintain systems long term because
we've made it fairly easy to just rebuild and side step any potential
issues. Easy or not, I don't have the time to rebuild every few weeks.
I'm not of the mind to discourage users from doing this, as long as they
understand that they are in largely uncharted territory in this
community. It's been said many times before: You break it, you get to
keep both pieces!
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.
Also a fair point, but both glibc and kernel should be ABI compatible
within reasonable upgrade intervals. That said, no need to rebuild glibc
(or update the headers) just for a kernel version update (you'll likely
need a newer glibc to take advantage of it anyway).
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
