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 7426558973 for ; Thu, 28 Jan 2016 23:26:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7C93621C024; Thu, 28 Jan 2016 23:26:19 +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 16DC421C024 for ; Thu, 28 Jan 2016 23:26:18 +0000 (UTC) Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 9166A3408E5; Thu, 28 Jan 2016 23:26:17 +0000 (UTC) Date: Thu, 28 Jan 2016 18:26:17 -0500 From: Mike Frysinger To: Alex McWhirter Cc: gentoo-sparc@lists.gentoo.org Subject: [gentoo-sparc] Re: Official SPARC64 Port Message-ID: <20160128232617.GG14840@vapier.lan> Mail-Followup-To: Alex McWhirter , gentoo-sparc@lists.gentoo.org References: <56AA9F05.30307@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="/CMXFb8mCYhr2S8D" Content-Disposition: inline In-Reply-To: <56AA9F05.30307@triadic.us> X-Archives-Salt: 3d26727f-12d2-4a9b-84e1-5c352c4f4689 X-Archives-Hash: 3a788642df90a90c764de332c5ac3c60 --/CMXFb8mCYhr2S8D Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 28 Jan 2016 18:06, Alex McWhirter wrote: > It's also worth noting that at this moment i am not an official Gentoo > developer, although i am working towards having that goal met in the > very near future. So at this point it's possible all of my work is junk > as no one has really looked over it but me :p, so keep that in mind. you don't have to be a dev to get your work merged. you just have to be a dev to do the final push yourself. so if you have changes that you think are ready to go now, we can get them merged. > pciutils will not compile on sparc64, which i believe could be udev > related. See the error below. >=20 > ../../lib64/libudev.so: Only registers %g[2367] can be declared using > STT_REGISTER >=20 > It seems like systemd also has a similar issue. > https://sourceware.org/bugzilla/show_bug.cgi?id=3D19019 that bug indicates it's a bug when using gold. so if things are working fine w/ld.bfd, then it's fine to move forward. that bug also makes it sound like there's something fundamentally broken in gold that udev just happens to trip over, so we'd simply say gold isn't yet supported for sparc. > Originally it was decided to use the old sparc keyword for sparc32 and > sparc64, but in this case we have an app that will compile on sparc32 > but not sparc64. How should this be handled? A new keyword would be a > pain, so is there another way of dealing with this? let's ignore the bfd-vs-gold aspect and just assume that it's a situation where sparc64 always fails and sparc32 always works, and there's no way to fix the problem. if that truly is the case, packages can be masked in the sparc64-specific linux profile. it's a bit heavy weight, but since this scenario rarely comes up, it's not that big of a deal. a more pertinent example would probably be something like grub-0. the code fundamentally assumes 32-bit everywhere, and links against 32-bit system libs, so it's not worth our effort to try and rewrite the code to work in a 64-bit env. on amd64 non-multilib systems, we mask it, and provide a grub-static package instead. -mike --/CMXFb8mCYhr2S8D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWqqOYAAoJEEFjO5/oN/WBDIIP/32QAPH8t1BWfIIf7HdaZDQ9 kCmszrCnYdQyPHJUWFI+hVV9iTcpe2HAy1InVaZzlxtsyJ2Q8ZaBKnPW+eXGDShw L/M9n28r2mdC0SVMn7TYFL1PK3lM8Pnq0qcbp2w4TW4D3OhOpwJO8tbHlvT0Cp0D kCmoGKLTq13J69MYPZ6a8l2hRQHz5RkbDkqWymbJAaqoT6Bw/gFDqcPjv1Ca5KL/ PhgzvmTiOgCr6Q5uwf58MJ3l9Qjuy5hfcncMYVRMpuwGV911m3J6IJMfprtZSE/i VnKsx4exBZANjMlAQUd1SvUx7Bc1HmRyha2wBZa2de2h2I5qoxx0H35m6C9wZ5mM UvDmrKgTT8k1PbxcmAiCi1+1bDuVYyQVRNY+otbF7eXXnz3DMNIn1HBduVMz/9xe rVsNI2Nsk1yuHilrgM02jeB4bUA8DXQGl9KcG5x/I/PL75Jw44ulSlvMx+bnt5nb iXO+7+dnHVKWNNyN+fcc0TA0NG8QIZJSAn69ByWE0r3eiNc3SkxwOxn25WpRetAi iyxoJHLd6QAYt6rhap/UcjbnbRlV4LHoTpgQJeS93vnPMnK/3zGQkrF+RocdeWgz 4Z7Nsoi5d8hdGqP4/0veykdci2eLQYHOCswcXlxFgJZ1gHqvAZ9mPEjypF1Lejip 9lMjxw2JyLfS8zJETm2e =IB4O -----END PGP SIGNATURE----- --/CMXFb8mCYhr2S8D--