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.
