From: Stefan Puiu <hidden> Date: 2016-02-24 02:24:49
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.
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? 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.
Thanks,
Stefan.
From: Thomas Monjalon <hidden> Date: 2016-02-24 09:28:03
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.
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.
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? Is there any point in
trying to use the mk files from my outside project?
I would say no, especially when the rest of your buildsystem is around automake (or cmake or...). Pktgen relies on the dpdk make infrastructure but even that gets into all sorts of trouble with it.
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.
It would be nice yes, but instead of some custom make-thing, I'd prefer a pkg-config file for the purpose. Adding a pkg-config file has been suggested in the past a few times but nobody has stepped up to do it.
- Panu -
From: Stefan Puiu <hidden> Date: 2016-02-24 16:43:38
On Wed, Feb 24, 2016 at 3:26 AM, Thomas Monjalon
[off-list ref] wrote:
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?
Yes, everything would be perfect if the O_TO_EXE part was used. As far
as I can tell, that's not how automake works.
You just set bin_programs, <prog>_SOURCES, <prog>_CFLAGS and then it
generates the Makefile code to build your stuff, which is different
from the above thing; it also uses LDFLAGS, which it treats as a user
variable. In 1.7.1, LDFLAGS is prefixed properly. In 2.2, it's not
prefixed, so the build system ends up calling gcc with linker options.
I'm not implying this is something that should be fixed in the DPDK; I
was just trying to see how others handle this.
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.
I'm not very familiar with pkgconfig, but if it can supply some *FLAGS
to build against, then it sounds good. I've worked on a project where
we built with scons, so including mk files wasn't much of an option.
Thanks,
Stefan.