From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH 7/8] numactl/Makefile - Generalize Makefile .so Version
Date: Tue, 28 Apr 2009 18:46:16 +0200
Message-ID: <20090428164616.GN27382@one.firstfloor.org>
References: <20090428163621.24945.95516.sendpatchset@localhost.localdomain> <20090428163702.24945.41315.sendpatchset@localhost.localdomain>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20090428163702.24945.41315.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Cliff Wickman <cpi@sgi.com>, Kornilios Kourtis <kkourt@cslab.ece.ntua.gr>, Brice Goglin <Brice.Goglin@inria.fr>, linux-numa@vger.kernel.org, eric.whitney@hp.com

On Tue, Apr 28, 2009 at 12:37:02PM -0400, Lee Schermerhorn wrote:
> [PATCH 07/08] Generalize Makefile .so Version
> 
> Against:  numactl-2.0.3-rc2
> 
> When building "upstream" libnuma on a system with, e.g., a distro-supplied
> numactl package installed, I find it useful to build a different version of
> libnuma.so, so that both versions of the library can co-exist.  

Sorry I don't think that's a good idea. If that ever escapes from
your system we have a binary incompatibility mess, which was 
always one of the goals of libnuma to avoid.

I just use LD_LIBRARY_PATH for testing newer libnumas. It's not too
bad.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.