From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 116112C6A for ; Tue, 27 Jun 2017 15:52:25 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 93657211D9; Tue, 27 Jun 2017 09:52:25 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 27 Jun 2017 09:52:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=zy5uKPzY0+jFtYd 50fd18bcWRca+HBmws/KSSjBL5jI=; b=GVJxjAFCalF8xaqxd7jO3gmW1AJUJRe GA4CUOY0rS3YqSvLy43alS9K5L/+t2XBcniJ+r115xqsvrVZZhB1cZZPOyWttDNU 8xZLTgHTkJ3GZ5y9/61LWDbHQZnCcvNbovvGav2psDEiUGoqbLd4bP2Voa2Sllzy 8zJCpFxZKd64= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=zy5uKPzY0+jFtYd50fd18bcWRca+HBmws/KSSjBL5jI=; b=iZ8y5ltV N4SWl8tK3hBEKekzlqGUHbYl8P7RE5fcy0Tl2vPa38CD80UY5UCPSoUK1HKgIEgk mSMwUCFYsjkSwcoWsrRgbTLdeDSQbMAEGhJCHiNU6v9xSs9rRj2A29pD/XSGFd2Z QVkSx/OwzVdf/674mGxqqsO6ZdrlDGxsj8G/P629m+fnoB9OkqSgxPv0iwLcfFRw NgCOMyD5xRMsDmvYORdaWs2B28HQh+tmV63ibFMp3GpmPkcD8T6HI+kIof4F7jg5 xxWPdY0Yz/HmNGZaJXa9/KEKssVKsbnfWAHfSh6GP0pX0ZrkVZcvaF25IT5HI90P traBiHV/Fj4V0A== X-ME-Sender: X-Sasl-enc: KXpF+dEjPk8yUG73S4Fiwt9lATR82Z46xv0oEbDjZmmo 1498571545 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4CDDC7E429; Tue, 27 Jun 2017 09:52:25 -0400 (EDT) From: Thomas Monjalon To: Luca Boccassi Cc: dev@dpdk.org Date: Tue, 27 Jun 2017 15:52:24 +0200 Message-ID: <2009930.OQrImQK4oz@xps> In-Reply-To: <1498560192.14026.11.camel@brocade.com> References: <20170623181616.16981-1-lboccass@brocade.com> <2558671.pWjLEmoHCY@xps> <1498560192.14026.11.camel@brocade.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 7/8] mk: sort object files when building deps lists X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 13:52:26 -0000 27/06/2017 12:43, Luca Boccassi: > On Tue, 2017-06-27 at 01:20 +0200, Thomas Monjalon wrote: > > 23/06/2017 20:41, lboccass@brocade.com: > > > From: Luca Boccassi > > > > > > In order to achieve reproducible builds, always use the same > > > order when listing object files to build dependencies lists. > > > > > > Signed-off-by: Luca Boccassi > > > --- > > > mk/rte.app.mk | 4 ++-- > > > mk/rte.hostapp.mk | 4 ++-- > > > mk/rte.shared.mk | 4 ++-- > > > 3 files changed, 6 insertions(+), 6 deletions(-) > > > > > > --- a/mk/rte.app.mk > > > +++ b/mk/rte.app.mk > > > @@ -263,8 +263,8 @@ LDLIBS_NAMES += $(patsubst -Wl$(comma)- > > > l%,lib%.a,$(filter -Wl$(comma)-l%,$(LDLIB > > > > > > # list of found libraries files (useful for deps). If not found, > > > the > > > # library is silently ignored and dep won't be checked > > > -LDLIBS_FILES := $(wildcard $(foreach dir,$(LDLIBS_PATH),\ > > > - $(addprefix $(dir)/,$(LDLIBS_NAMES)))) > > > +LDLIBS_FILES := $(sort $(wildcard $(foreach dir,$(LDLIBS_PATH),\ > > > + $(addprefix $(dir)/,$(LDLIBS_NAMES))))) > > > > You cannot sort libraries. > > Check - for instance - this comment above in this file: > > # Eliminate duplicates without sorting, only keep the last > > occurrence > > filter-libs = \ > > Not sure I follow - what's the reason for avoiding to sort the list of > libs to link against? Sorry, the ordering issue is with LDLIBS not LDLIBS_FILES. > > Why sorting them? > > What is random in libraries list? > > The issue is that the output of wildcard is not fully deterministic. It > can depend on the filesystem, and even on the locale settings [1]. > Before GNU Make 3.82 (2009) it used to automatically sort the output, > but that was removed (to make it faster... sigh). [2] It is not a true wildcard here. It is just filtering files which do not exist. I think you do not need this patch for deterministic build.