From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id E95D52BA1 for ; Wed, 24 Feb 2016 10:28:03 +0100 (CET) Received: by mail-wm0-f50.google.com with SMTP id g62so261679336wme.1 for ; Wed, 24 Feb 2016 01:28:03 -0800 (PST) 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:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=8fIRy5PtpwZIa0wRNwaIPO1AzL1qA8mllb1lhUZD78o=; b=L91tvGckE0t7h2X/ZCHRTTB3XNnIocBkcKh+SycJpgRKSn81GxgEFxFoi0ayD+VwWv RBHGN8+4u/yhdeiFmDjkEZx8VhsmoxaaZYnHayR/4IZ3MYfN0+Up3B9Pqhnndcghuhwv tysF8VV7r7JcCOPT4ChtOFcydkFyvtbIHSePf2xkQWXS9OB1tfEI2kNUh7ab8vVWS5cj h1xBwNZEZ2dOZeq3QVwHVaVaRHij0Fmzve4tNRohrUspStaI4a+5LsKGPg8FkUA3j4QH A5dm9/z9dCbQdeH+TgK6mUT3IT/aYcS0BBD0kzzzkTRfrTbht4Z3SyEAyYHfebjWWKTv 6ZLw== 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=8fIRy5PtpwZIa0wRNwaIPO1AzL1qA8mllb1lhUZD78o=; b=YQm2pZC7y2UjAjNs9RNY4be9+uSqWbFWM7KKiEB2gVObBMlcVWUm0+nL1d8PY918KA Xz6tEwT/0by+S5iVK4FI1NySkiiqBjli3agC6Qyy5Ckxz64vzQgnRpHWt0AaCgCd8E8M U6Q5Obls0gr+4wHW0wTjlgniiuZYLR3GchwpPXfZcQmBpOOgU16UF/AeyWIo52RXsZU3 7ZDVloUVrrKQNi06rA+h+57ZZXMoI1mHGpVIAyC+4Ub03BafLnY216+Cl2VjTdtYHrvu w0qf+//e1XvZnFZP1UveQpoarsxlUo+m16uI9UIC6q+8Gu+wHVdrB0ZM8WHwZOa2yBO+ hrxQ== X-Gm-Message-State: AG10YOTrbcAXgc/hgDsVXv3YbilqY9H9oKHrafHIoOdv9gYkQlbBLN1CgrAIJBAhJzZ7upe8 X-Received: by 10.194.90.229 with SMTP id bz5mr42328501wjb.143.1456306083778; Wed, 24 Feb 2016 01:28:03 -0800 (PST) Received: from xps13.localnet (171.36.101.84.rev.sfr.net. [84.101.36.171]) by smtp.gmail.com with ESMTPSA id ls5sm2019716wjb.33.2016.02.24.01.28.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 01:28:03 -0800 (PST) From: Thomas Monjalon To: Stefan Puiu Date: Wed, 24 Feb 2016 10:26:30 +0100 Message-ID: <7557103.ADgOLz8lG7@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] including rte.app.mk from a Makefile.am 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: Wed, 24 Feb 2016 09:28:04 -0000 Hi, 2016-02-23 20:24, Stefan Puiu: > Hi, > > I'm working on a Linux project that uses the DPDK and (unfornately, > IMO) automake; so we have a Makefile.am where we include rte.extapp.mk > and rte.vars.mk from the DPDK, add LDLIBS to the linker > > However, I've tried building against DPDK 2.2 and I'm getting linker > errors about options like '--no-as-needed', '--whole-archive' etc not > being recognized. Basically, we use libtool to link the binary, which > behind the scenes ends up calling gcc to link the binary, and gcc > doesn't know how to read linker options - they need to be prefixed > with '-Wl,..'. I've traced this to this part of rte.app.mk: > > === DPDK 1.7.1 > ifeq ($(LINK_USING_CC),1) > LDLIBS := $(call linkerprefix,$(LDLIBS)) > LDFLAGS := $(call linkerprefix,$(LDFLAGS)) > > === DPDK 2.2 (since DPDK 1.8, AFAICT) > ifeq ($(LINK_USING_CC),1) > O_TO_EXE = $(CC) $(CFLAGS) $(LDFLAGS_$(@)) \ > -Wl,-Map=$(@).map,--cref -o $@ $(OBJS-y) $(call > linkerprefix,$(LDFLAGS)) \ > $(EXTRA_LDFLAGS) $(call linkerprefix,$(LDLIBS)) > > Notice on 1.7.1 LDFLAGS gets the -Wl, prefix if linking with gcc; for > 2.2, that doesn't happen anymore - note O_TO_EXE calls linkerprefix > explicitly for LDLIBS and LDFLAGS. > > The change that removed the LDLIBS/LDFLAGS setting is 3c6a14f6, which > ironically says "mk: fix link with CC" in the title. Yes it is prefixed when used instead of assignment. In 2.2, it is better fixed: ifeq ($(LINK_USING_CC),1) override EXTRA_LDFLAGS := $(call linkerprefix,$(EXTRA_LDFLAGS)) O_TO_EXE = $(CC) $(CFLAGS) $(LDFLAGS_$(@)) \ -Wl,-Map=$(@).map,--cref -o $@ $(OBJS-y) $(call linkerprefix,$(LDFLAGS)) \ $(EXTRA_LDFLAGS) $(call linkerprefix,$(LDLIBS)) So everything is properly prefixed. Could you please better describe your issue? Is $(LINK_USING_CC) true in your case? > I've tried working around this, but apparently automake doesn't give > you too much control of what you can do; overriding LDFLAGS with > $(call linkerprefix,$(LDFLAGS) in Makefile.am doesn't work. Since > LDFLAGS is treated as a user variable by automake, it's tricky to > override it. > > Now my question is: is this supposed to work? Yes and I still don't understand what is your issue. Are you really using 2.2? > Is there any point in > trying to use the mk files from my outside project? I noticed dpdk-ovs > doesn't seem to bother with that, and just builds one library to link > against. I guess it's useful to pick up the defines that the DPDK was > built against, so inline functions in headers are properly picked up. > Are there people using the DPDK from projects using automake? > > IMO, It would be nice if you could extract the CPPFLAGS/LDFLAGS etc > from the DPDK without including the mk files - maybe by running > something like 'make showvars' or something like that in the DPDK dir. > Then external projects could integrate those in their build system > without too much extra baggage. Yes, mk/rte.app.mk is primarily used by internal apps. If an external app don't want to use the DPDK makefiles, it should be possible to use pkgconfig on DPDK. I hadn't time yet to write a patch for pkgconfig support, so any contribution is welcome.