Summary: | dev-libs/gmp[pgo] fails to build on arm with error: unknown type name 'clock_gettime' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | tt_1 <herrtimson> |
Component: | [OLD] Unspecified | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arm, conikost |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://gmplib.org/list-archives/gmp-bugs/2016-November/004032.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
compressed build.log
output of emerge --info tuneup-clock-gettime.patch |
Created attachment 419266 [details]
output of emerge --info
+1 same problem here That error is caused by LDFLAGS="-Wl,--as-needed". When "-Wl,--as-needed" is not set, this error is gone. But after that, I am still unable to compile dev-libs/gmp[pgo], because I am hitting a new error: libtool: compile: armv7a-hardfloat-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/portage/dev-libs/gmp-6.1.0/work/gmp-6.1.0/mpz -I.. -D__GMP_WITHIN_GMP -I/var/tmp/portage/dev-libs/gmp-6.1.0/work/gmp-6.1.0 -march=armv7ve -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mtune=cortex-a7 -O3 -mfloat-abi=hard -mthumb -pipe -fomit-frame-pointer -c /var/tmp/portage/dev-libs/gmp-6.1.0/work/gmp-6.1.0/mpz/bin_uiui.c -fPIC -DPIC -o .libs/bin_uiui.o In file included from /var/tmp/portage/dev-libs/gmp-6.1.0/work/gmp-6.1.0/mpz/array_init.c:32:0: /var/tmp/portage/dev-libs/gmp-6.1.0/work/gmp-6.1.0/gmp-impl.h:1384:34: error: unknown type name ‘mp_srcptv’ __GMP_DECLSPEC void mpn_toom44_mul (mp_ptr, mp_srcptr, mp_size_t, mp_srcptr, mp_size_t, mp_ptr); ^ fails for armv6 too Created attachment 453690 [details, diff]
tuneup-clock-gettime.patch
Placing that patch fixed this for me.
The cause is simple.
When USE="pgo" is set, the eBuild runs:
./tune/tuneup | tee gmp.mparam.h.new
Apparently, something does wrong and the string "clock_gettime is 1.000ns accurate" is beeing written to gmp-mparam.h.new (which is later moved to gmp-mparam.h)
Problem solved, thanks a lot! This is a bit off the topic, but are there any speedtests to see wether the use of pgo speeds up something in the end? (In reply to tt_1 from comment #6) > This is a bit off the topic, but are there any speedtests to see wether the > use of pgo speeds up something in the end? It definitely does not. Which is also the reason why every major compiler includes this technology. thanks guys. i've sent a patch upstream for the issue. let's see what they have to say about it. https://gmplib.org/list-archives/gmp-bugs/2016-November/004032.html upstream has merged the fix, so pushed on our side: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=02c897444d280edc7330204b9fb43afb0a52d0ba |
Created attachment 419264 [details] compressed build.log see attached build.log for further details.