From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30716 invoked from network); 25 Aug 2004 19:43:09 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 25 Aug 2004 19:43:09 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1C03fo-0002Eg-6A for arch-gentoo-dev@lists.gentoo.org; Wed, 25 Aug 2004 19:43:08 +0000 Received: (qmail 24787 invoked by uid 89); 25 Aug 2004 19:42:58 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 23250 invoked from network); 25 Aug 2004 19:42:58 +0000 Message-ID: <412CEBF4.10804@gentoo.org> Date: Wed, 25 Aug 2004 15:43:48 -0400 From: Travis Tilley User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040811) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org, gentoo-core@lists.gentoo.org, amd64@gentoo.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [gentoo-dev] Two requests for ebuild maintainers+writers X-Archives-Salt: 7283fc92-3610-4a3f-b0d7-c945eae2362e X-Archives-Hash: 940d647306fd503316995f20b7ae3393 I have two requests that will help to make my work incredibly easy. ;) 1) start using $(get_libdir) wherever possible instead of referencing lib directly. get_libdir is now part of the eutils eclass and is used by gen_usr_ldscript in eutils. so, where previously it had: cat > ${D}/usr/lib/$1 <<"END_LDSCRIPT" it now has: cat > ${D}/usr/$(get_libdir)/$1 <<"END_LDSCRIPT" The get_libdir function will always return "lib" if using portage <2.0.51_pre20 or if CONF_LIBDIR isnt set, so it should be safe to use -everywhere-. If CONF_LIBDIR is set, it should return lib32 or lib64, depending on what multilib capable arch you are running on. package maintainers arent expected to be aware of any issues with using lib32/lib64 (well, unless you're an amd64 dev or helping with multilib on mips i guess), so feel free to slap any bugs related to lib64/lib32 onto the arch maintainers. ;) please mark any lib32/lib64 bugs critical so that they're sure to be noticed, even if they're not technically critical. *pokes amd64 devs so that they know this was requested and dont downgrade any of those bugs* 2) install and use gcc 3.4 if possible. this isnt a biggie for most archs, i'd just like for packages to be tested with gcc 3.4 since I havent run into any major problems on amd64 in a while, and would like to know what x86 or ppc specifics fail (i expect there to be a small few that only fail on these archs). Note that i'm not requesting anyone -switch- to gcc 3.4 here, just that they test the packages they maintain to see if they fail, and fix them if possible. a note about c++ apps: if you dont plan on switching to gcc 3.4 completely, it might not be easy to test any c++ apps. 3.4 includes an incompatible libstdc++, and strange bugs pop up or apps fail to compile when one dep links to .so.5 (gcc 3.2.3->3.3.x) and another links to .so.6 (gcc 3.4.x). they dont -always- pop up, but they -often- do. if you keep gcc 3.3 around, some retarded apps still link to .so.5 even when compiled using 3.4 unless you move gcc 3.3's libstdc++.so out of the way. :/ gcc 3.4 is slotted, but if you switch completely, the suggestion is to remove 3.3.x and 3.2.x. morfic has also been kind enough to provide us with an experimental gcc 3.4 on x86 profile for those willing to make the switch: profiles/default-linux/x86/2004.2/gcc34/ Travis Tilley -- gentoo-dev@gentoo.org mailing list