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 4B7E71386E2 for ; Sun, 27 Jan 2013 16:11:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C9D5621C0C9; Sun, 27 Jan 2013 16:11:51 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AC97A21C0C2 for ; Sun, 27 Jan 2013 16:11:50 +0000 (UTC) Received: from localhost (pc-234-79-101-190.cm.vtr.net [190.101.79.234]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 1C10E33DB11; Sun, 27 Jan 2013 16:11:48 +0000 (UTC) Date: Sun, 27 Jan 2013 13:11:42 -0300 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Cc: mgorny@gentoo.org Subject: Re: [gentoo-dev] The gx86 multilib project -- masterplan Message-ID: <20130127131142.6dcdacef@gentoo.org> In-Reply-To: <20130127161237.1a04614e@pomiocik.lan> References: <20130127161237.1a04614e@pomiocik.lan> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.14; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 6a797440-4132-4aed-a05f-cbd99da6384a X-Archives-Hash: a47ed16373729a10e7f9642c9ae563a8 On Sun, 27 Jan 2013 16:12:37 +0100 Micha=C5=82 G=C3=B3rny wrote: > 5. Solutions to specific problems > --------------------------------- >=20 > 1. x11-proto packages >=20 > Those packages install headers to /usr/include and pkg-config files > to /usr/lib64. This supposedly means that the headers could be > ABI-specific; however, so far I haven't seen a single difference. >=20 > Possible solutions: >=20 > a) check the headers by hand, move pkg-config files to /usr/share, >=20 > b) make the proto packages multilib. This will cause identical .pc > files to be installed to lib32 & lib64 but will also enable eclass > checks for header consistency. b) sounds like what we should do by default while lobbying upstream to do a) :) > 2. packages which install ABI-dependent headers >=20 > e.g. libogg. The issue needs to be fixed in the specific ebuild. >=20 > a) fix the headers, e.g.: >=20 > typedef short ogg_int16_t; > typedef unsigned short ogg_uint16_t; > typedef int ogg_int32_t; >=20 > to: >=20 > #include >=20 > typedef int16_t ogg_int16_t; > ... >=20 > b) install the header(s) in an alternate location. With packages using > pkg-config, that would be easy. b) is not an option: this will break those that do not use pkg-config a) is the correct solution, in cooperation with upstream of course, and it shouldn't be that hard for the libogg example since, as far as I can see, they already have such typedefs for other OSes. > 3. packages which still reinvent pkg-config with their *-config >=20 > e.g. llvm. Really painful to solve; probably will require action both > on llvm ebuild side and consumer side. >=20 > a) long-term solution: convince upstream to use pkg-config. >=20 > b) short-term: rename the llvm-config script and use the renamed > version for 32-bit build. yes, but b) is a mess as there will be no generic solution :(