From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Fnzsm-0001n8-IX for garchives@archives.gentoo.org; Wed, 07 Jun 2006 15:23:45 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k57FKo2t025479; Wed, 7 Jun 2006 15:20:50 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k57FE9SN028095 for ; Wed, 7 Jun 2006 15:14:09 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B1E4164675 for ; Wed, 7 Jun 2006 15:14:08 +0000 (UTC) Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25990-14-3 for ; Wed, 7 Jun 2006 15:14:06 +0000 (UTC) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by smtp.gentoo.org (Postfix) with ESMTP id 7AED3647E5 for ; Wed, 7 Jun 2006 15:14:06 +0000 (UTC) Received: from nightcrawler (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (rwcrmhc11) with SMTP id <20060607151405m1100jsehme>; Wed, 7 Jun 2006 15:14:05 +0000 Date: Wed, 7 Jun 2006 08:13:25 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] fix binary debug support, part elevenity billion + 1 Message-ID: <20060607151325.GA27076@nightcrawler> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Status: No, score=-2.517 required=5.5 tests=[AWL=0.082, BAYES_00=-2.599] X-Spam-Score: -2.517 X-Spam-Level: X-Archives-Salt: 876008f4-6ae8-4d30-8c77-d31a2e05bc34 X-Archives-Hash: 2f8daf5aad9ff5e55e24644473ce8823 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Resurrecting this issue (yet another round) since FEATURES=3Ddebug-build=20 was shoved in... Background info- http://thread.gmane.org/gmane.linux.gentoo.devel/35202/focus=3D35212 Quick summary, there needs to be an easy way to flag on essentially=20 "leave the symbols intact/don't mangle the code too much for this build";= =20 needs a few things- 1) flip on nostrip in the restrict. 2) adjust CX*FLAGS, LDFLAGS For #1, use conditional support was added to portage somewhere around=20 2.0.51_pre18; support is still there, so you can use=20 RESTRICT=3D"debug-build? ( nostrip )" now. As for #2, we already have eclasses mangling flags, this is no=20 different. Two approaches to this- 1) FEATURES=3D"debug-build". pros:=20 1) doesn't require modifying anything in the tree. cons:=20 1) no way to know if the feature will actually affect a pkg (won't=20 do jack to a pure python/perl/shell/ruby pkg, no point in even=20 trying) 2) FEATURES are not controllable via any package.* file. 3) pkgs that support debug builds, but are not affected by trying to set a default set of *FLAGS have to now go and check FEATURES to=20 discern if they should produce a debug build. 4) no way to make the debug-build option associative to deps; simple=20 example, consider mysql python bindings. Debug info there quite=20 likely isn't all that useful for a segfault- if the horkage occurs=20 in mysql, you just get the usual ?? backtrace, and wind up having=20 to take a second manual step of rebuilding mysql with debug=20 enabled. 5) cannot control the setting per package. 2) USE=3D"debug-build" pros: 1) it's explicit. if the package can generate a debug-build version=20 of itself, you see the debug-build flag in it's IUSE. 2) appropriate designed eclass, ebuild can specify up front any=20 nonstandard *flags additions that should be made- for example,=20 ciaran's suggestion to mangle CXXFLAGS when dealing with STL so=20 that the result is useful. Possible via FEATURES, but ebuild would=20 have to test features for it (something it should be mostly unaware=20 of, features are mainly pkg manager directives, not ebuild). 3) via use deps, it's possible to address 1.4 from above-=20 python-mysql can just slip in a=20 "debug-build? ( dev-db/mysql[debug-build] )", one less manual step required. 4) use flags can be controlled per package via package.use; you can force $YOUR_PERSONAL_PROJECT to always be built with debug symbols=20 cleanly. cons: 1) requires modifying the tree, and introduction of eclass for it. 2) existing USE=3D"debug" (namely nano) is used to enable runtime=20 changes, asserts, etc; would have two sets of flags, debug-build=20 and runtime changes (debug flag). Now... not to hard to figure out from above which route I prefer, but=20 that *should* be an accurate pro/con of the two routes for this. =20 Note also that common pros/cons are exempted; fex, ability to specify=20 via profile default debug *flags. So... kindly state which you view as best. Thoughts? ~harring --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEhu0VvdBxRoA3VU0RAvl7AJ4grAw5UhalNfC/fGfWLjLZ8Z98wwCffI2Z F3XM3xYUkMBoG0y5kVEHZFc= =Obzs -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- -- gentoo-dev@gentoo.org mailing list