From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 8A54A58973 for ; Mon, 1 Feb 2016 20:51:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D3D4821C074; Mon, 1 Feb 2016 20:51:25 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5EE0221C074 for ; Mon, 1 Feb 2016 20:51:25 +0000 (UTC) Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 853DB340D98 for ; Mon, 1 Feb 2016 20:51:23 +0000 (UTC) Date: Mon, 1 Feb 2016 15:51:23 -0500 From: Mike Frysinger To: gentoo-sparc@lists.gentoo.org Subject: Re: [gentoo-sparc] Official SPARC64 Port Message-ID: <20160201205123.GO7732@vapier.lan> Mail-Followup-To: gentoo-sparc@lists.gentoo.org References: <56AA9F05.30307@triadic.us> <56AC03AC.3040405@triadic.us> <20160130004457.GP14840@vapier.lan> <56AC09E4.6000606@triadic.us> <20160201174452.GH7732@vapier.lan> <56AFB22B.5090405@triadic.us> <20160201202447.GM7732@vapier.lan> <56AFC16B.1060602@triadic.us> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-sparc@lists.gentoo.org Reply-to: gentoo-sparc@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LvAn5G4Ewe70kJ1i" Content-Disposition: inline In-Reply-To: <56AFC16B.1060602@triadic.us> X-Archives-Salt: 59aac943-6fd7-4f82-96d6-e7f6fc13b88d X-Archives-Hash: 804f60d2208299bcc60ec9ab28004312 --LvAn5G4Ewe70kJ1i Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 01 Feb 2016 15:34, Alex McWhirter wrote: > On 02/01/2016 03:24 PM, Mike Frysinger wrote: > > On 01 Feb 2016 14:29, Alex McWhirter wrote: > >> On 02/01/2016 12:44 PM, Mike Frysinger wrote: > >>> On 29 Jan 2016 19:55, Alex McWhirter wrote: > >>>> On 01/29/2016 07:44 PM, Mike Frysinger wrote: > >>>>> On 29 Jan 2016 19:28, Alex McWhirter wrote: > >>>>>> Regarding the issue with pcitutils, it is indeed and issue with go= ld. It > >>>>>> turns out udev is broken as well, as in it wont start. > >>>>>> > >>>>>> binutils has supposedly fixed this issue upstream, i may try to em= erge > >>>>>> 9999 later tonight. perhaps eudev fairs a bit better than udev? Wo= uld > >>>>>> there be any issue with moving to eudev as a default? > >>>>> arches should not be picking any defaults like udev. we should be = using > >>>>> the same default across all linux systems. especially if the only = point > >>>>> is to workaround a bug in gold. > >>>>> > >>>>> is the fix in binutils-2.26 ? that's going into the tree in a bit = =2E.. > >>>>> i'm waiting for some feedback from upstream before i push it. > >>>> I can check to see if the fix is in .26, but eudev does work without > >>>> issue for what it's worth. pciutils is also compiling without issue = with > >>>> eudev. > >>>> > >>>> I will try pulling 9999 and see if the issue is no longer there, if = it's > >>>> been resolved there then ill check into .26 > >>>> > >>>> Without that fix, sparc64 is probably a no-go. I suppose we could al= ways > >>>> patch .25 if needed. > >>> why ? as i said, gold is not the default, and we don't hold up issues > >>> because of gold compatibility. if sparc64 w/ld.bfd works fine, then > >>> that's all we need. > >> It looks like udev is hard coded to use gold, i may have to hack around > >> with configure.ac to get it to compile with bfd. > > OK, that's an important point :). yes, we'll want to deploy a hack for > > `use sparc` to the udev ebuild to disable the usage of gold. should be > > as simple as: > > if use sparc ; then > > sed -i 's:-Wl,-fuse-ld=3Dgold::' configure.ac || die > > fi >=20 > The systemd mailing list makes it look like this may not be a sparc only > problem, it looks like it can also happen to 64 bit mips. What about > patching configure.ac to have an --disable-lto option? in cases like this, the preference would be to get any patches merged upstream, and then add that to our ebuild. but if upstream won't pick up a patch that'll help, just minimize the sed/patch hackary. generally the whole point of doing a "clean" patch is to get it merged upstream. -mike --LvAn5G4Ewe70kJ1i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWr8VKAAoJEEFjO5/oN/WBHoEQANiF5BPbhxTEqCTkyb4K718O wIhiFkAhT7qoruK2ZyHUIaYEEVZaEconRQ1q7DYy7QUhYDB3iDz0vy4WqeaIhxLW ooIjFkj+svyWl5pg4oOkBurgqQl2cXWLFFCjfqxU92py0CIwBHvZrs/BUj4fVXWa Dhd3ysQm4pNCC/OxEozAJPrhoXBUwjwer+M8ZacOx6fP6NOmFux4aQMl+3AQ+acn BX+110yjMxVPL1zoAEarRpBTOPMXZriB98RcAjRcTFwfzYYvsNiVDSjYeyaMfA5h 7LiCRX5fWkmRxtcYt9CS2FRIX2Xcn1ayv9P26Z/b4nLBUZ6x0luhfeXtnsa1Y6Lk BDpLt4aKd7H9MFFBeuqBVU/felIF0AEGT8Ce64BAtARVXo9+65oNKwgI0xnkCtBg 5tuaoNVIdTuSpn23ZLkjrMqkHYHbC2YYX0N92Bb7IdyItDLSVRFNTgOApg3rIyRu QBSsEPYYn5brAw1S61pEmn/tzAVRvY99RDVQ/gz/8hWyuSRto3uIlD0KA99r/cw1 zgnyvrQAZZZqPfxTSOaR2eeKq91rNW2FxDu+sFFRtw0EobNSW1XxB9rEyrjdJDhr 7cxQRDVnvtzYuMFCE7BySan1WSvPkpMeGghU1AaQ4CSZjyy6dsW04PNNssr60qpF GgfPrHCRQUp1GjoteWxW =7FKF -----END PGP SIGNATURE----- --LvAn5G4Ewe70kJ1i--