From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by dpdk.org (Postfix) with ESMTP id E2C78E82 for ; Fri, 3 Oct 2014 09:08:41 +0200 (CEST) Received: by mail-wi0-f177.google.com with SMTP id fb4so1191659wid.4 for ; Fri, 03 Oct 2014 00:15:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=3IK97tSr5ej1NnAkCtAl2E9oaKdfLgNW06IdH4bUkpk=; b=k0kmotBVbuTJAlBhPfqkj7xag92O2opj8YrbYqDGdMos+5kBzlOg6hsFc9UEPyQm/T W1WJnL9JDdsTHJgxj7+crEuEtVi0eYQ5QZMbgQxo0D+3bmMy6qaYQ+mNYPQYyrZ75Im0 04P+MVOevwtwH0qcKlQfzhsHIbRKTec4Fgse1mH25sp3fMKBFOmZfq0iCZMuWxybHf06 ah1ldDj/l2eVTJJ7XfTX9fsFHpmaLvDPsQONf5J85X5HDA7Ar3FzEDSLe+fcjDZS6XZL CjqfteRPbHAuLGAukLQwmWkJKz2G8AHUF75/AOS09V9+50AKEQnD9cAkNAc5BTXIExRM H/Zg== X-Gm-Message-State: ALoCoQmQAMbTQtRCjqv5nszYULsGKxDLg16bNOljrcBPk7LSnsos28MSzINvd2RA3r5Y82xZfBY9 X-Received: by 10.194.134.201 with SMTP id pm9mr4904744wjb.130.1412320535039; Fri, 03 Oct 2014 00:15:35 -0700 (PDT) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id be1sm1128034wib.4.2014.10.03.00.15.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Oct 2014 00:15:34 -0700 (PDT) From: Thomas Monjalon To: Sergio Gonzalez Monroy Date: Fri, 03 Oct 2014 09:15:20 +0200 Message-ID: <2041475.WSUx3LgNfR@xps13> Organization: 6WIND User-Agent: KMail/4.13.3 (Linux/3.15.8-1-ARCH; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20141002200420.GB29590@mhcomputing.net> References: <1412265386-26291-1-git-send-email-sergio.gonzalez.monroy@intel.com> <20141002172634.GE4900@hmsreliant.think-freely.org> <20141002200420.GB29590@mhcomputing.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 07:08:42 -0000 2014-10-02 13:04, Matthew Hall: > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote: > > Just out of curiosity, whats the impetus behind a single shared library here? > > Is it just to ease application linking operations? If so, it almost seems to me > > that we should abandon the individual linking method and just use this as the > > default output (and do simmilarly for the static linking build) > > Not clear if you wrote "single shared library" on purpose instead of "single > static library". But for me the objective of COMBINE_LIBS usage would be > getting a "single static library" for my app, which just works, and eliminates > need of start-group, end-group, weird library ordering issues, etc. I'm not > interested personally in a "shared library" because it'd run slower. > > Personally my preference would be to do both the single libs and multiple libs > in static format by default. Disk space is cheap, let's maximize user freedom > and flexibility. But shared lib, since it performs less well, should be > discouraged by default, although allowed if needed... some people prefer it > because it's easier to patch security vulns if you can replace a buggy library > for all the code on a system. We need to simplify build options. So I'm fine to remove COMBINE_LIBS option to always enable it. About making only one single static library, I think it's a good idea if it brings a real code simplification. So the conclusion is to nack this patchset in favor of above changes. Sergio, comments? -- Thomas