From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 6CFC52C13 for <dev@dpdk.org>; Wed, 28 Jun 2017 16:37:29 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B31BC20B4C; Wed, 28 Jun 2017 10:37:28 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 28 Jun 2017 10:37: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=hzomgQBGjsCYaes MeT4PSvtTGNizk8H5BYibvRq3BEA=; b=a+RFbgflstA3dqP+C5bozQKQ/EJcZNy NKvldKPJ5nJmeNqH+6mJPXagDndknyytDPle8JB/LN3GZPsv1VKsZuwRTSLibTCM 6/182TUQy6WbBLZWhkN1LrsfJk5dtXbSsfqf4JI9xqhx81w+6gvZ9IjvymIE6gbN lJuXP3Yqwt6Y= 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=hzomgQBGjsCYaesMeT4PSvtTGNizk8H5BYibvRq3BEA=; b=K1MMujYG YecUffysYVfX9DXNARtGaNLhfxKdfZm7nEHuLnGhjXq3CDHfeIB0B223hAb/Pz8R kiBjqBy3Q6lEzhOavZMow9GMyYfqWMlx+vfgHO2WBuzb/59I86SrfYjpps1HT3Qo u3SW1NRU6iYpGmzHUlad1UF8SbD7fdwTxjxhf63PTfLlU7uu2ARmCVGIsWRwFtGm J5SYrTs22QHL/9bu7eUnktRzZRP6YOiI1JCV0s6SY0VdkDewVVjb//3ev3xns6EZ hgCvTG/v6j9kbyBwwFQ4T8d/anpMu+xd8S1FfqFPdR6hX9/kCS1uvMwU42Gbmhnh c4R1MPs6CvfHKg== X-ME-Sender: <xms:KL9TWT4csso_PyGPwgh1eDldcmBE6P1v-5HEjOZLd2CFzZjrdha20Q> X-Sasl-enc: Kl+HzNhNYMBZ7sxo68yYd7GSr6IHbb9dOoP+RqHzqdeF 1498660648 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 688C67E51B; Wed, 28 Jun 2017 10:37:28 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Luca Boccassi <lboccass@brocade.com> Cc: dev@dpdk.org Date: Wed, 28 Jun 2017 16:37:27 +0200 Message-ID: <1711733.oN2V1mqmzG@xps> In-Reply-To: <1498658859.21465.7.camel@brocade.com> References: <20170623181616.16981-1-lboccass@brocade.com> <42831069.yGv8R2R7xR@xps> <1498658859.21465.7.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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 28 Jun 2017 14:37:29 -0000 28/06/2017 16:07, Luca Boccassi: > On Tue, 2017-06-27 at 18:14 +0200, Thomas Monjalon wrote: > > 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 <luca.boccassi@gmail.com> > > > > > > > > > > > > > > In order to achieve reproducible builds, always use the > > > > > > > same > > > > > > > order when listing object files to build dependencies > > > > > > > lists. > > > > > > > > > > > > > > Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com> > > > > > > > --- > > > > > > > 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 thought that these lists are used to determine which files to > recompile - and incidentally, in which order as they are passed in this > snippet in rte.compile-pre.mk: > > .SECONDEXPANSION: > %.o: %.c $$(wildcard $$(dep_$$@)) $$(DEP_$$(@)) FORCE > @[ -d $(dir $@) ] || mkdir -p $(dir $@) > $(if $(D),\ > @echo -n "$< -> $@ " ; \ > echo -n "file_missing=$(call boolean,$(file_missing)) " ; \ > echo -n "cmdline_changed=$(call boolean,$(call cmdline_changed,$(C_TO_O))) " ; \ > echo -n "depfile_missing=$(call boolean,$(depfile_missing)) " ; \ > echo "depfile_newer=$(call boolean,$(depfile_newer))") > $(if $(or \ > $(file_missing),\ > $(call cmdline_changed,$(C_TO_O)),\ > $(depfile_missing),\ > $(depfile_newer)),\ > $(C_TO_O_DO)) > > Did I get that wrong? (It is a bit convoluted :-P ) LDLIBS_FILES are just used to link the executable AFAIK. The libraries are built in separate recursive make calls. > But nevertheless, I've finally found the root cause for the "wandering > header" - when building the libraries, CFLAGS lists > -I$(RTE_OUTDIR)/include first and then -I$(SRCDIR) last. There is a > race, and sometimes when GCC is called the public header has already > been installed in RTE_OUTDIR and sometimes it has not. This causes the > instability, and causes the expansion of __FILE__ and the directory > listing in the DWARF objects to randomly list the full path to either > RTE_OUTDIR/include or SRCDIR for each library. > > By always passing -I$(SRCDIR) first this instability is solved. Good news.