From glibc-2.2.5 to 2.3.2: the LFS way at jeopardy?
rgollub at uninet.com.br
Fri Mar 14 14:54:39 PST 2003
James Iwanek wrote:
> and the way to fix it is:
> ln -s /usr/bin/cpp /lib/cpp
> hope this helps:
> btw: upgrading from glibc-2.2.5 to 2.3.x is quite dangerous
> my advice would be to start again from scratch using the cvs version of the
tks for your reply.
Don't be offended but I thought of doing this trivial intervention, but
I didn't in view of my analysis of the *nature* of the errors being
reported by gcc in the 'config.log'.
You see, glibc-2.3.2's configure is quite more sophisticated than
2.3.1's counterpart. The error is connected to the fact that now the
configure test programs require headers (in this case,
/usr/include/limits.h from a *pre-existing* glibc) that would ordinarily
be present on a "normal" system, but obviously is lacking, as glibc in
LFS is compiled on an empty environment (first step in chapter 6, inside
IOW, the tests are failing for the wrong reason, meaning that the
"conclusion" reached by the tests are erroneous.
Implementing the Right Hack (???) here seems apparently out of reach.
The cpp link might work, but it certainly isn't addressing the real
problem, and other tests may also fail due to similar reason but
deriving erroneous conclusions. The whole build is jeopardized due to
wrong premises. This remains to be fully assessed and checked, but I
think that I have a solid case here for investigation.
The main reason for posting here is to check whether the situation is
strictly of my own making or not. Hope there are other reports,
confirming (or denying), but, nevertheless reports.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev