> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, December 16, 2014 11:43 PM > > 2014-12-16 19:48, Thomas Monjalon: > > 2014-10-28 15:48, Sergio Gonzalez Monroy: > > > If we set EXTRA_CFLAGS=-O0, build fails with following error: > > > > > > /usr/bin/ld: test: hidden symbol `mknod' in > > > /usr/lib64/libc_nonshared.a(mknod.oS) is referenced by DSO > > > > > > Fix: link combined shared lib using CC if LINK_USING_CC is enabled. > > > > > > Signed-off-by: Sergio Gonzalez Monroy > > > <sergio.gonzalez.monroy at intel.com> > > > --- > > > mk/rte.lib.mk | 1 - > > > mk/rte.sharelib.mk | 12 +++++++++++- > > [...] > > > --- a/mk/rte.lib.mk > > > +++ b/mk/rte.lib.mk > > > @@ -63,7 +63,6 @@ ifeq ($(LINK_USING_CC),1) # Override the > > > definition of LD here, since we're linking with CC LD := $(CC) > > > LD_MULDEFS := $(call linkerprefix,-z$(comma)muldefs) -CPU_LDFLAGS := > > > $(call linkerprefix,$(CPU_LDFLAGS)) endif > > > > Why are you removing this line? > Hi Thomas,
Basically the problem is when CPU_LDFLAGS has a value, which in the currently only happens if we set CPU_LDFLAGS in the command line or build i686 (setting CPU_LDFLAGS=-melf_i386). In those cases, given the way the makefiles are being included, CPU_LDFLAGS is being 'linkerprefixed' twice, resulting in build error. Removing that line avoided the second linker prefix of the CPU_LDFLAGS (note that we reset the original var instead of using a different var name). There probably is a better way but I could not see an straightforward fix for it. I planned to improve the current build system (already sent an RFC) and was waiting until 1.8 release to resume the work on it. Thanks, Sergio > If it's really needed, it could be another patch. > > > > --- a/mk/rte.sharelib.mk > > > +++ b/mk/rte.sharelib.mk > > [...] > > Acked-by: Thomas Monjalon <thomas.monjalon at 6wind.com> > > Applied without the change to rte.lib.mk. > > Thanks > -- > Thomas
