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 45EDF138247 for ; Tue, 21 Jan 2014 20:04:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 65FB5E0F69; Tue, 21 Jan 2014 20:04:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AC412E0F66 for ; Tue, 21 Jan 2014 20:04:45 +0000 (UTC) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: bicatali) by smtp.gentoo.org (Postfix) with ESMTPSA id C71CA33FA8B for ; Tue, 21 Jan 2014 20:04:44 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id c10so11863221igq.0 for ; Tue, 21 Jan 2014 12:04:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=2LUnawVeXKHzT0uR0vErcgJb3qqcUgPQhT0MF6xgWmk=; b=LfWJbse6qNvzRfAOxr0lFega2//F/x+qdbeoo3SbO+xKi6dNwb7a+WasMxN6q7U0ij O75dvbHqwHymUsv64b9evoNc02hwSaSfgJz8UPId7Mw8mhC7p+Aszs2mt+9CL4hoqvgd GZttIbryi8OUWxRTgbMoCXk58+sy3LxB4cWLF0HZqbp7y0mhHGGsOPA8OouYDIUKBqiO oSuF12YatOZufgnMV9kB+3YEvn/UQpHAU0GgmOiRvOWgffcfCZdg0fb3WFWudKTK5IN3 Q6RkoT/cKbAp6iHODkHDM3MgOn8kN9/LO97FMkDAoXdKsfbMZgrArwAeCMOMu8bO9d+q CNow== 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 X-Received: by 10.50.66.180 with SMTP id g20mr19556114igt.29.1390334683340; Tue, 21 Jan 2014 12:04:43 -0800 (PST) Received: by 10.64.89.41 with HTTP; Tue, 21 Jan 2014 12:04:43 -0800 (PST) In-Reply-To: <20140121192641.GB13149@dhcppc1> References: <1390240392-12173-1-git-send-email-rei4dan@gmail.com> <20140121192641.GB13149@dhcppc1> Date: Tue, 21 Jan 2014 12:04:43 -0800 Message-ID: Subject: Re: [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates From: =?UTF-8?Q?S=C3=A9bastien_Fabbro?= To: gentoo-science@lists.gentoo.org Content-Type: multipart/alternative; boundary=047d7bdc14e8ebc0c704f0808427 X-Archives-Salt: 2571f9da-c817-4972-9644-6775ec7e2c15 X-Archives-Hash: d3ec041a48ffd91e1ecf0acf37883758 --047d7bdc14e8ebc0c704f0808427 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 21, 2014 at 11:26 AM, Reinis Danne wrote: > > How the eselect module creation could work? Something like this? > > ~# eselect module create blas > ~# eselect blas add atlas importance src dest [src dest [..]] > ... > ~# eselect blas remove atlas > ~# eselect delete blas > That is the idea. Last one should be "eselect module delete blas". > > * 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 --047d7bdc14e8ebc0c704f0808427 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 21, 2014 at 11:26 AM, Reinis Danne <rei4dan= @gmail.com> wrote:

How the eselect module creation could work? Something like this?

~# eselect module create blas
~# eselect blas add atlas importance src dest [src dest [..]]
...
~# eselect blas remove atlas
~# eselect delete blas
=C2=A0

That is the idea. Last one should be "eselect module delete bla= s".
=C2=A0
> * given the number of bugs, we should keep the linking to the referenc= e
> names libraries, so we could eselect providers without re-compiling al= l
> reverse dependencies. We could do this in the open sourced providers b= y
> changing the soname of the libraries we compile, and in the binary one= s
> (mkl,amcl...) with a link script generated library.

Yes, this is ok and AFAICT it is like that now in the overlay.

=C2=A0
It is not. Let's take blas= for example. Install openblas and blas-reference, then eselect blas refere= nce. Then install lapack-reference, then remove blas-reference. You will ha= ve to re-install lapack-reference, because of a missing reference to libref= blas.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.
=C2=A0
We need to change all blas ebuilds to mak= e sure they have the same soname, and add to alternatives_for blas the libr= aries 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_u= sr_ldscript from toolchain-funcs eclass idea. If the ldscript stuff is not = much overhead, we could apply it to all.

Sebastien

<= /div>
--047d7bdc14e8ebc0c704f0808427--