Lenovo ideapad 13O-14l KB about 5 yrs old. Change root environment but gcc still pass 2. TCL tests failed http and finally hung on http11 but I don't see how that affects GMP. Everything else built ok till now.

Tests failed:
1) t-do-exceptions-work-at-all-with-this-compiler
2) t-ops2z
3) t-assign
4) t-constr
5) t-rand

tried various builds --build=x86_64-pc-linux-gnu, --host=x86_64-lfs-linux-gnu, config.guess seems to be KabyLake-pc-linux-gnu, with and without --disable-static -- always same 5 tests fail.
Any ideas welcome!

Attached Files

	cpu.txt (2.8 KB, 4 views)
	gmp.log (123.5 KB, 3 views)

https://wiki.gentoo.org/wiki/Safe_CFLAGS

Usually this error means something is compiled with incorrect CFLAGS for your CPU. There is also a rare issue one might experience, in case you load new CPU microcode when OS is already running it may disable some CPU instruction which was present when system intialized, thus microcode must be loaded when kernel loads, I build it into kernel image myself.

1 members found this post helpful.

Bearing in mind what you said about possible duplication of microcode, Emerson, and since this gcc (pass 2) was built with gmp/mpfr/mpc math libraries in the source tree, could they be interfering in the new gmp? But I expect I had flags set in error when gcc was built. Since the change root no CFLAGS have been set, even for installing glibc. The first installation of glibc refused to continue without at least "-O2".

My last try was using configfsf and configfsf.sub instead of config and config.sub. Same errors so I'll have to untar the source again. That gcc was built with "--languages=c,c++" but it's the cxx tests that are failing. I sometimes have "CXXFLAGS=-std=gnu++2b" but gcc wouldn't build with that.

Other possible factors are binutils being rebuilt in /usr now, different from the binutils when gcc was built, and tcl (needed for the tests) failed various http tests, hanging indefinitely on http11. I couldn't fix that so I installed it anyway.

Anyway I appreciate your advice and thanks.

(1) Many newer GNU tarballs have "post-compile tests" which fail, and the README say to expect false failures (so see README carefully if you run tests).

your GMP may be working fine

http://totally-built-linux-distro.s3...com/index.html

(2) i checked TBLD for any build options that may help. gmp-6.0.0 isn't in it at all which means that "it build with default TBLD environment".

GMP usually builds easy without any 'configure' commandline args. But your compiling chain needs to be correct. (that other apps built doesn't mean gmp's pre-requires are satisfied. maybe maybe not.)

If you persist that all post-test should not fail, perhaps try compiling an older or newer GMP and see how that goes. Good place to start.

But be aware that this sometimes/often happens in GNU. FOO revises it's code (or binutils is rewritten with non-standards floating) and then FOO's post-compile tests are no longer themselves correct tests.

This is TBLD's default environment when GMP is built 64-bit. It may not help you but might.

env CFLAGS=' -O1 -march=x86-64 -mtune=core2 -I/usr/local/comp64/include -I/
usr/local/comp64/usr/include -I/usr/include -std=gnu89 ' CPPFLAGS=' -I/usr/lo
cal/comp64/include -I/usr/local/comp64/usr/include -I/usr/include -std=gnu89 '
CVSROOT=/root/cvs CXXFLAGS=' -O1 -march=x86-64 -mtune=core2 -I/usr/local/c
omp64/include -I/usr/local/comp64/usr/include -I/usr/include -std=gnu++98' EL
VISGUI=termcap HOME=src HOSTTYPE=i386 LANG=C LANGUAGE=C LC_ALL=C LDFLAGS=' -L/us
r/local/comp64/lib64 -L/usr/local/comp64/usr/lib64 -L/usr/local/comp64/lib -L/us
r/local/comp64/usr/lib' LOCALE=C LOGNAME=root MACHTYPE=i386-pc-linux-gnu MAKE2=m
ake MAKE2i=make OSTYPE=linux-gnu PATH=/usr/local/comp64/sbin:/usr/local/comp64/u
sr/sbin:/usr/local/comp64/sbin:/usr/local/comp64/usr/sbin:/usr/local/app64/sbin:
/usr/local/app64/usr/sbin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/usr/sbin:/u
sr/local/comp64/bin:/usr/local/comp64/usr/bin:/usr/local/comp64/usr/local/bin:/u
sr/local/comp64/bin:/usr/local/comp64/usr/bin:/usr/local/comp64/usr/local/bin:/u
sr/local/app64/bin:/usr/local/app64/usr/bin:/usr/local/app64/usr/local/bin:/bin:
/usr/bin:/usr/local/bin:/usr/local/musl/bin PKG_CONFIG_PATH=/usr/local/comp64/li
b64/pkgconfig:/usr/local/app64/share/pkgconfig POSIXLY_CORRECT=y PWD=/usr/local/
src9 SHELL=/bin/sh SHELLOPTS=braceexpand:hashall:interactive-commentsosix TERM
=xterm TERMCAP=/etc/termcap TTY=/dev/ttyp1 UNAME=Linux USER=src USER2_PATH=/usr/
local/comp64/sbin:/usr/local/comp64/usr/sbin:/usr/local/comp64/sbin:/usr/local/c
omp64/usr/sbin:/usr/local/app64/sbin:/usr/local/app64/usr/sbin:/sbin:/usr/sbin:/
usr/local/sbin:/usr/local/usr/sbin:/usr/local/comp64/bin:/usr/local/comp64/usr/b
in:/usr/local/comp64/usr/local/bin:/usr/local/comp64/bin:/usr/local/comp64/usr/b
in:/usr/local/comp64/usr/local/bin:/usr/local/app64/bin:/usr/local/app64/usr/bin
:/usr/local/app64/usr/local/bin:/bin:/usr/bin:/usr/local/bin:/usr/local/musl/bin
\
./configure --prefix=/usr/local/comp64 --exec-prefix=/usr/local/comp64 --datar
ootdir=/usr/local/comp64/share --datadir=/usr/local/comp64/share --sysconfdir=/u
sr/local/comp64/etc --libdir=/usr/local/comp64/lib64 --with-gnu-ld $* 2>&1 >>
build.configure.log 2>&1
exit
# /lib64:/usr/lib64:/usr/local/comp64/lib64:/usr/local/comp64/usr/lib64:/usr/loc
al/app64/lib64:/usr/local/app64/usr/lib64:/usr/local/lib64:/usr/local/usr/lib64:
/lib:/usr/lib:/usr/local/comp64/lib:/usr/local/comp64/usr/lib:/usr/local/app64/l
ib:/usr/local/app64/usr/lib:/usr/local/lib:/usr/local/usr/lib

for GMP to compile i'd say make sure you have clean headers in /usr/include.

also see these pre-requisites may effect it

*perl-5.10.1
make-3.80
termcap-1.3.2
termutils-2.0
texinfo-4.13
make-3.80
m4-1.4.16
autoconf-2.71
automake-1.15.1
libtool-2.4.6
bison-2.7
flex-2.5.35
gmp-6.0.0

(perl and gcc must be existing and work then be re-built later, a chicken and egg)

of the above i'd suspect "make m4 auto-tools bison flex" as being cappable of causing naming conflicts that lead to bad instructions

that being said: "binutils" encodes instructions, also gcc's cxx can causing naming issues that then cause improper instructions chosen. for those i will say: you do have to have a compiling set cappable of compiling gmp. that means the right versions (some README have incorrect minimum versions these days). and build correctly.

GMP isn't usually a problem

and again: suspect that "post compile tests" themselves might be flawed and that GMP is working. check that end of things before doing too much elsewise.

Thank you very much for your advice, xlfs, and sorry I haven't replied till now. I made a decision to install gmp anyway and since then I haven't had many test failures. Most of them seem to be 95%+ successful and the misses mainly skipped tests. The gcc tests in particular seemed ok to my inexpert eye and I was breezing along (occasionally choppy for various causes) up to vim and only half a dozen packages to a safe landing.

Vim itself reported a couple of test failures but I wasn't worried till eudev check failed 1 out of 2. I think that should be a new thread as its probably unrelated.


Thanks again for your help.