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 09A1A138247 for ; Tue, 21 Jan 2014 21:30:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ADB52E11A0; Tue, 21 Jan 2014 21:30:22 +0000 (UTC) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 00EF6E119F for ; Tue, 21 Jan 2014 21:30:21 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id c41so4336881eek.2 for ; Tue, 21 Jan 2014 13:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=IsBH6az4gRwicPbOX5p5p+uUen1kWFFtvX53fuHGsaw=; b=VyZHbly2vT78WqNghaqIAEgoHiTvVh1uGEmuIrh4hoCu4xMHOZpG+1Z0bU/CiNP/0r Z8RcAXiinaqX6OB6S+j3DYYsaApHxtTtnLeXXZ/ORp/1mkytFYI9no7E6NOqFlNLF47S vdaLJOA2m6nU8te2OtmOXFFGHyU5zwmHSOuGd5XL4Kjyqbkl4Sq3hwFXSkWqDPLmxh/M R7VuTYArtWyEkCGu3asTm5HnrKw9B9dV/IB/lCpv1f9Cgf11xiAH+S5XPFY/lVVOA6x1 iaB/Aw7RChiuHa+k3URLgR0Bvcfl5Ls63KepGUKmiW/0m77nFev7xBt4xq6bXUDzie9u zPbQ== X-Received: by 10.15.32.73 with SMTP id z49mr26102531eeu.27.1390339820774; Tue, 21 Jan 2014 13:30:20 -0800 (PST) Received: from dhcppc1 (dsl-trebrasgw2-58c0d8-67.dhcp.inet.fi. [88.192.216.67]) by mx.google.com with ESMTPSA id v1sm19177766eef.9.2014.01.21.13.30.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jan 2014 13:30:20 -0800 (PST) Date: Tue, 21 Jan 2014 23:30:17 +0200 From: Reinis Danne To: gentoo-science@lists.gentoo.org Subject: Re: [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates Message-ID: <20140121213017.GC13149@dhcppc1> Mail-Followup-To: gentoo-science@lists.gentoo.org References: <1390240392-12173-1-git-send-email-rei4dan@gmail.com> <20140121192641.GB13149@dhcppc1> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-science@lists.gentoo.org Reply-to: gentoo-science@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Archives-Salt: 598d726d-8157-4761-b0ad-6fa25b5c1c6d X-Archives-Hash: d508d15166cf09fec0f0a6f3ca0e4e0f On Tue, Jan 21, 2014 at 12:04:43PM -0800, Sébastien Fabbro wrote: > On Tue, Jan 21, 2014 at 11:26 AM, Reinis Danne wrote: > > > > * given the number of bugs, we should keep the linking to the reference > > > names libraries, so we could eselect providers without re-compiling all > > > reverse dependencies. We could do this in the open sourced providers by > > > changing the soname of the libraries we compile, and in the binary ones > > > (mkl,amcl...) with a link script generated library. > > > > Yes, this is ok and AFAICT it is like that now in the overlay. > > > > > It is not. Let's take blas for example. Install openblas and > blas-reference, then eselect blas reference. Then install lapack-reference, > then remove blas-reference. You will have to re-install lapack-reference, > because of a missing reference to librefblas.so. If openblas had the > libblas.so soname and link, you would not have to. I'm actually not sure > whether it is a side effect of our as-needed policy. > > We need to change all blas ebuilds to make sure they have the same soname, > and add to alternatives_for blas the libraries to link. For blas-reference, > eigen, atlas and openblas, this is just a matter of a link flag. For acml > and mkl, this is trickier, thus the gen_usr_ldscript from toolchain-funcs > eclass idea. If the ldscript stuff is not much overhead, we could apply it > to all. > > Sebastien Ok, that is different issue. The question is whether we want, e.g., eselect blas be build time only or also runtime setting. If we use provider specific sonames, then the program will use whatever provider was selected at build time even if different provider is set afterwards. Thus it is build time only setting, with the caveat that package has to be rebuilt if selected provider is removed (preserved-libs should catch this). ⬑ This is how it is now in the overlay. If we provide generic sonames for alternatives (symlink or ldscript), then program should use whichever provider is currently selected. Thus it is runtime setting, with the caveat that all packages can use only currently selected provider (user has to keep track of selected provider). Symlinks can be provided with the existing alternatives-2.eclass if ebuilds choose to do so. Only change for generic pc file would be not to point to selected provider's pc file, but to give settings for generic libs (which is symlink to currently set). In this case generic pc file generation should be added to eclass? Is there any reason why it has not been used? I don't know how often people actually do use specific providers with different applications or how often they switch between them? As long as there are no programs with different preferred providers, the generic libs would be ok. But if there are such programs, then provider specific libs should be used. This could already be done by picking provider specific pc file (and optional USE-flags for providers in ebuilds). AFAIK, benchmarking is the only use for generic libs (no need to reinstall for every provider) and provider selection rarely changes otherwise. Are there examples of opposite? Could this be different for different alternatives (blas, cblas, lapack, ...)? Reinis