From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 21864214A for ; Fri, 10 Jun 2016 17:18:26 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id v199so153148841wmv.0 for ; Fri, 10 Jun 2016 08:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=c6BCq/JE/2C8zY4ACgcC0AZ0r6AM6Ioa71iLmaY1nzs=; b=GRx1P8isQlxlHvuE6YluycBuVdp2ov2PgqFyFfmdyDm6vAi0cJO4fc5v0tV+oqp7co CUa9KBGRwVv5MOItVpUb2WJyXzQT2NPxDD2fQo+rK/mRklb++NYBR20tuvlKFwCdOVLY eNPt3moi1DEaCLmbAjzKKrLIbDv+HPSN/JMtTLb5y51DfldDToDRf08n8zFPbfOYPOON P0wQt/FDmxQEFkXUYBYGYyWUk6XaV88Ct2BB/mdrr906A6Sh00mFLE2/Sv/wUzogU5Rk 5yGfmq0X8rTgli9lb3eFuFcLToPqyroYrYfNs4Bw36iunsogs90ZBe8mP8Uf9rFI+ug/ 8L6A== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=c6BCq/JE/2C8zY4ACgcC0AZ0r6AM6Ioa71iLmaY1nzs=; b=KiyvZHRWfWSmgWW+A4pFhywWmdEmSH6I2Wvcnp4zpVXk6n0AVgGq7LQbn8G2G6r//t iUUDbD6MuiMmNDqksiJFhg0tA8l5iTIycDJ+LO18Yf/kZYebg3qJuFmALO51cnvwJxRL bJr/AGYAsNsYxfvPAgwJ/QOmSKk4gNszq9UkrnGuZnHRcZoittIWatcMza6EqIiN0N3U MZdCSEj/wpfC8TYMFgXIJkljeJxEZzNRup3t3pMjVjV1oCEQRB0KlLJN3I8bAE8fhzyQ fY17SNwV5QmXjp5rgfWWn2j8f0vysSbJY0GQd6mB8qZknWiyPIN7vIvMgeAg1fdggNqR 9fyg== X-Gm-Message-State: ALyK8tKIfyWybM0k9rPwE1y0Q8aUd2b35LpkwNq4ZYHIPtEA1eEOTOGTUR4aQ8Iv/LkSKxXN X-Received: by 10.194.103.4 with SMTP id fs4mr3034530wjb.10.1465571905898; Fri, 10 Jun 2016 08:18:25 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id c62sm13383019wmd.1.2016.06.10.08.18.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 08:18:25 -0700 (PDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org Date: Fri, 10 Jun 2016 17:18:24 +0200 Message-ID: <4132294.2uBzABCNq8@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <575AD6DE.9080907@intel.com> References: <1464367686-3475-1-git-send-email-ferruh.yigit@intel.com> <1465564749-1405-7-git-send-email-thomas.monjalon@6wind.com> <575AD6DE.9080907@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 6/6] mk: reduce scope of whole-archive static linking 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, 10 Jun 2016 15:18:26 -0000 2016-06-10 16:03, Ferruh Yigit: > On 6/10/2016 2:19 PM, Thomas Monjalon wrote: > > From: Ferruh Yigit > > > > The --whole-archive argument is only required for plugins (drivers) > > and libraries used by these plugins. > > Currently it covers all libraries. > > Reducing the scope of this argument slightly reduce final application size > > when statically linked. > > > > Signed-off-by: Ferruh Yigit > > Signed-off-by: Thomas Monjalon > > --- > > Technically the scope of --whole-archive should be PMDs, wider scope > required because of unresolved references, but I think this is not good > workaround. > > If libraries ordered as suggested before: pmd->librte->external, won't > need to extend scope of parameter > > Still some applications will have problem for now, because of cyclic > dependency of librte_eal and librte_mempool, which seems targeted to fix. > > So, instead of adding --whole-archive as workaround that efffects whole > binaries, I am for adding workaround for effected application. I would prefer keeping a small workaround in rte.app.mk instead of in the application makefile. We must be careful with applications which may break because of our changes. This is the kind of issue that they won't fix quickly. > The be effected this problem, an application should have direct calls to > librte_eal, but shouldn't have any calls to librte_mempool, I think this > rare case, that is why only a unit test application effected. And when > dependency issue removed we can fix this. > > To be able to apply workaround per application, LDFLAGS should be set in > a way to commented previous patch.