Hi Nathan,
On 04/15/2016 12:00 AM, Nathan Bibb wrote:
On Thu, Apr 14, 2016 at 12:49 PM, Nathan Bibb <[email protected]
<mailto:[email protected]>> wrote:
At this point I think I am a bit stuck. I see my options as:
1. Continue with the install and see what horrible mess I get into;
I actually decided to see if 'make install' would do anything different,
and I got the exact same error there.
As I've understood, your compilation (configure and make) had no issues.
So you are having that error in 'make check'. This is not a test failure
(some failing tests are expected) but an error that aborts the command.
Right?
And now you are getting "the same" error in 'make install'? That is, the
installation is aborted too?
I have confirmed that cacheinfo.c exists in the sysdeps/i386 folder, but
it only calls the version in the x86_64 folder - so no help there.
Code in x86_64 folder is also used for x86 builds. They are reusing code.
All of the articles online that bear any resemblance to this issue
involve valgrind - I know valgrind is not specifically installed in LFS,
but is it included in some test suite distributions?
I think Valgrind loads some libraries that confuses glibc in determining
the CPU type where it is built on, for some old types of CPU. Something
similar could be happening here for this old Pentimum MMX on a recent
glibc, not sure at all...
So...is it time for me to through in the towel? I feel that I am
grasping at straws at this point.
> > `maxidx >=
> > 2' failed.
>
For the sake of curiosity, this could be the failing code.
=== sysdeps/x86_64/cacheinfo.c ===
static long int __attribute__ ((noinline))
handle_intel (int name, unsigned int maxidx)
{
assert (maxidx >= 2);
/* OK, we can use the CPUID instruction to get all info about the
caches. */
===
There is an assert in cacheinfo.c code for any guessed Intel CPU. Your
build seems to get here and fail.
You can try a quick test. Before compiling glibc, modify the code to
prevent the assert to fail in your machine. Add a line in:
=== sysdeps/x86_64/cacheinfo.c ===
static long int __attribute__ ((noinline))
handle_intel (int name, unsigned int maxidx)
{
assert (maxidx >= 2);
...
===
something like this:
===
static long int __attribute__ ((noinline))
handle_intel (int name, unsigned int maxidx)
{
if (maxidx < 2) return 0;
assert (maxidx >= 2);
...
===
Dirty, but it can give some insight if it works.
It is your own time that you'll bet on this build. If you are decided to
keep pushing forward, for such an specific machine I would probably set
CFLAGS/CXXFLAGS with "-march=pentium-mmx" from the very beginning. See
Ch 6.4 for a hint if you haven't.
Regards.
Alz.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
