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 2716F2C08 for ; Tue, 27 Jun 2017 18:14:29 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CC064214DF; Tue, 27 Jun 2017 12:14:28 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 27 Jun 2017 12:14:28 -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=YTaroQZ662e9q4U Em+gij+HorjCPBkYzA8KESJSGzE0=; b=FOtuvdk397+PaLDAKNQqVICgUATLLKu t/6mah3COJMV9ggF19Rg+Cx6IuHUE/ZE5VjH2S41BOVCHaQeWmPE4gM0Aduf9AEr lNTDVGkkjW90dC8NNTSKE9UIH/gMmBkG0XlkSy7N4kJp+5wWl6owAEs38553nRNM T6GpvhpMbYP0= 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=YTaroQZ662e9q4UEm+gij+HorjCPBkYzA8KESJSGzE0=; b=UoKMOapV XYNenzBV/ieAXphmS3Ltg65rxrfTMEfksIxQadG5+cxkrJxLK5E/SRd7jMK9DO2b E0Naloaq5QbHJFSQ0MWAZjN6/Hff76XEmIEkF9qiGKYJCJuQsrhL5YRnPL39b0s2 IbPp2Amqa079mORWjcjQAgBB08WYIG0HjEHKzpEroaP1GSYffnariRw1mO2nMSZD Mf4A46lapXTT2PHZnKQhxJKCXs4uV7ZLJeLmvDhrDXvjnN6JQgabYZUjfOCrxALi +3g/HjBf97CV12ARIs7XfljdIZbhFtH8DKa7VKQ3TrFsU08rgvfMY+v7ah7uoXCs BRN0OWWTWvXglw== X-ME-Sender: X-Sasl-enc: P0Dlee+4/neJAd57icbzPcpw5/8qwIFLdvNQ1iW3nto9 1498580068 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 871A47E70C; Tue, 27 Jun 2017 12:14:28 -0400 (EDT) From: Thomas Monjalon To: Luca Boccassi Cc: dev@dpdk.org Date: Tue, 27 Jun 2017 18:14:27 +0200 Message-ID: <42831069.yGv8R2R7xR@xps> In-Reply-To: <1498575098.16925.5.camel@brocade.com> References: <20170623181616.16981-1-lboccass@brocade.com> <2009930.OQrImQK4oz@xps> <1498575098.16925.5.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 16:14:29 -0000 27/06/2017 16:51, Luca Boccassi: > On Tue, 2017-06-27 at 15:52 +0200, Thomas Monjalon wrote: > > 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. > > But then those lists are passed down in the .SECONDEXPANSION rule > right? I do not follow you. Please explain what is the benefit of the patch in the next version. > I am trying to find out an alternative solution. The problem to solve > is that the build system picks the public headers path (which is > embedded in the object files as notation and in the debug symbol) from > a seemingly random location between the make install path and the > source path (build/include/rte_foo.h vs lib/librte_foo/rte_foo.h) and > this makes the build not reproducible. > > Nonetheless, while I work more on the last 4 patches, could you please > have a look and eventually take patch 3 and 4? They are needed to > respectively have a deterministic list of files in the libdpdk.so > linker script and a list of source files in one of the example > documentation files. I think it's better to consider and apply the whole series making a reproducible build. The rule is to avoid splitting series without good reason, so tracking patches is easier.