public inbox for gentoo-science@lists.gentoo.org
 help / color / mirror / Atom feed
From: "François Bissey" <fbissey@slingshot.co.nz>
To: gentoo-science@lists.gentoo.org
Subject: Re: [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates
Date: Wed, 22 Jan 2014 10:26:48 +1300	[thread overview]
Message-ID: <d6ce20df8d6e320502ed24eeebcefc53@slingshot.co.nz> (raw)
In-Reply-To: <52DEE4C4.9010108@gentoo.org>

On 2014-01-22 10:21, justin wrote:
> On 21/01/14 18:04, Sébastien Fabbro 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.
> 
> I don't get this point. Why do we need to play around with sonames?
> Doesn't this bring more problems and maintainer burden then letting the
> consumer recompile reverse dependencies? Are the libs all ABI 
> compatible?
> 
All libs are supposed to be ABI compatible. For soname look at my 
previous post.
If you want to interchange libblas on the fly you need to have the same 
soname
for the library.

Francois


      reply	other threads:[~2014-01-21 21:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-20 17:53 [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates Reinis Danne
2014-01-20 17:53 ` [gentoo-science] [PATCH 01/10] alternatives-2.eclass: Update copyright Reinis Danne
2014-01-20 17:53 ` [gentoo-science] [PATCH 02/10] alternatives-2.eclass: Remove unused variables Reinis Danne
2014-01-20 17:53 ` [gentoo-science] [PATCH 03/10] alternatives-2.eclass: Move EXPORT_FUNCTIONS to top Reinis Danne
2014-01-20 17:53 ` [gentoo-science] [PATCH 04/10] alternatives-2.eclass: Remove commented-out code Reinis Danne
2014-01-20 17:53 ` [gentoo-science] [PATCH 05/10] alternatives-2.eclass: Put commonly used path in local variable Reinis Danne
2014-01-20 17:53 ` [gentoo-science] [PATCH 06/10] alternatives-2.eclass: Fix eclass name in comments Reinis Danne
2014-01-20 17:53 ` [gentoo-science] [PATCH 07/10] alternatives-2.eclass: Add EAPI check Reinis Danne
2014-01-20 17:53 ` [gentoo-science] [PATCH 08/10] alternatives-2.eclass: Add documentation comments Reinis Danne
2014-01-20 17:53 ` [gentoo-science] [PATCH 09/10] alternatives-2.eclass: Minor comment changes Reinis Danne
2014-01-20 17:53 ` [gentoo-science] [PATCH 10/10] alternatives-2.eclass: Use consistent quoting Reinis Danne
2014-01-21  6:51 ` [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates justin
2014-01-21 18:32   ` Reinis Danne
2014-01-21 17:04 ` Sébastien Fabbro
2014-01-21 19:26   ` Reinis Danne
2014-01-21 20:04     ` Sébastien Fabbro
2014-01-21 20:35       ` François Bissey
2014-01-21 21:30       ` Reinis Danne
2014-01-21 22:46         ` Sébastien Fabbro
2014-01-22  7:13           ` justin
2014-01-21 21:21   ` justin
2014-01-21 21:26     ` François Bissey [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d6ce20df8d6e320502ed24eeebcefc53@slingshot.co.nz \
    --to=fbissey@slingshot.co.nz \
    --cc=gentoo-science@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox