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 C1251198003 for ; Fri, 8 Mar 2013 11:11:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9D80EE066E; Fri, 8 Mar 2013 11:11:01 +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 B824FE0662 for ; Fri, 8 Mar 2013 11:11:00 +0000 (UTC) Received: from portable (AMontpellier-651-1-409-215.w92-133.abo.wanadoo.fr [92.133.76.215]) (using SSLv3 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id D5E0C33DD98; Fri, 8 Mar 2013 11:10:58 +0000 (UTC) Date: Fri, 8 Mar 2013 12:10:54 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Cc: tommy@gentoo.org Subject: Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs Message-ID: <20130308121054.60b922bf@portable> In-Reply-To: <5138E397.4040700@gentoo.org> References: <20130303000230.13fea8b8@pomiocik.lan> <51334A02.40705@gentoo.org> <20130303162404.5488ada7@portable> <5133709F.4020909@gentoo.org> <20130303171022.101be411@portable> <51337A06.20400@gentoo.org> <20130303175826.24a7f0c1@pomiocik.lan> <20130303181812.3d6b5cbe@portable> <20130303232503.3ad202e5@pomiocik.lan> <20130304110240.75f9d12e@portable> <5135016E.20903@gentoo.org> <20130307172930.2e390908@portable> <5138E397.4040700@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; 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=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 8220456c-dc58-40a9-8a2f-4c6f189931a9 X-Archives-Hash: 2a239f255176c4a98bf545480e4c47cd On Thu, 07 Mar 2013 19:59:35 +0100 Thomas Sachau wrote: > > I dont have a list of binaries, i either noticed myself some > abi-specific behaviour or got user reports for abi-specific behaviour. > As an example i remember, dev-libs/libIDL has a config binary not > matching the usual *-config scheme (libIDL-config-2), so instead of > adding a random list of patterns, i simply added that package to the > list of packages with wrapped binaries. The same applies to mysql, > which has a mysql_config binary. Ok, so those make perfect sense for being wrapped and should be done per-binary not per-package: We do not really want to wrap all mysql binaries just for mysql_config. Ebuilds should declare the binaries they want to be wrapped, so we can grep the tree for getting a list of what to fight against if we want a cleaner multilib system :) > I am not sure about the target of your qmake question, so as a general > answer: > > qmake is something like configure for qmake based build systems. If > you want to see the difference between qmake (32bit) and qmake > (64bit), run a 64bit qmake on a qmake based package and do the same > with a 32bit qmake and check the difference between the 2 runs. Well, I'm asking this because I don't have access to a 32bit qmake here so a diff of the files generated by the two will be useful :P And I believe it makes sense to study in details this case to understand whether we want to wrap it or not. As Davide said, it is likely that overriding the correct variable may make qmake output not abi-specific. The difference between g++-64 and g++-32 qmake mkspec is only a -m32 vs -m64 cflag which I think is overridden elsewhere in our ebuilds so this should not matter much. Alexis.