From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Stubdom compilation failure on Fedora 24 beta Date: Fri, 13 May 2016 14:35:21 +0200 Message-ID: <20160513123521.GO1171@mail-itl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0171879166490081331==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: xen-devel List-Id: xen-devel@lists.xenproject.org --===============0171879166490081331== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bc2iwAtkAaXP8cWF" Content-Disposition: inline --bc2iwAtkAaXP8cWF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm trying to build Xen 4.6.1 on Fedora 24 beta. Since gcc 6, I need to pull some patches from unstable, but then I hit some strange problem: During configure run in stubdom/gmp-x86_64 I've got: checking size of unsigned short... configure: error: cannot compute siz= eof (unsigned short) See `config.log' for more details. It turned out the failing line in conftest is: return ferror (f) || fclose (f) !=3D 0; ferror(f) returned 1. That's strange, when running under gdb, manually checking ferror(f) (`p ferror(f)`) returns 0. So I've looked at code produced (after slight modification to have "if (ferror(f)) ..."), ferror(f) was turned to: 0x000000000040063d <+55>: testb $0x40,0x10(%rbx) This doesn't look like ferror from glibc. And 0x40 is not _IO_ERR_SEEN (0x2= 0). This looks like ferror from newlib (stubdom/newlib-1.16.0/newlib/libc/inclu= de/stdio.h): #define __SERR 0x0040 /* found error */ #define __sferror(p) (((p)->_flags & __SERR) !=3D 0) #define ferror(p) __sferror(p) Configure is called this way (stubdom/Makefile): cd $@; CPPFLAGS=3D"-isystem $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/= include $(TARGET_CPPFLAGS)" CFLAGS=3D"$(TARGET_CFLAGS)" CC=3D$(CC) $(GMPEXT= ) ./configure --disable-shared --enable-static --disable-fft --without-read= line --prefix=3D$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf And indeed $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include contains head= ers =66rom newlib. Any idea how to fix this? And why it was working before? --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --bc2iwAtkAaXP8cWF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXNcoIAAoJENuP0xzK19csFAUH/2E9Qmg/0wJYfhhaUBBxG+Se 3BbyY2AXGDJHsL5SI9m6eI3EwI5JjoZJhvPPcr1agQZxqmIEHLFgxKQTzqO/T+/X hEFqsD7aPJmYegOBp5EKr+XDTn9VEYFxxEg4giqhQdN7rUXY9PIFlzu92pBB36gH 74/Pvzz50gz7uAkHHxtbPQsZw6xon9Qbijxa+dT/2hwHrV0hkGLKinpSCdbubYHM v4t+KVEDc07Xk2B30l0qKsxu/4O6N+rWuPNHPxV3n+qjhfwsLWIBWBgavEZVyCCi xyNwEIQPJmziyVtVo3wgbv5jDHq2oPUjTkZOngdTW7EfqzD2eHa5M98SCIWOCh4= =MSmi -----END PGP SIGNATURE----- --bc2iwAtkAaXP8cWF-- --===============0171879166490081331== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============0171879166490081331==--