On Fri, Apr 18, 2014 at 01:23:19PM +0200, Thomas Monjalon wrote: > Hi Neil, > > 2014-04-16 09:51, Neil Horman: > > The shared libraries built with the current makefile set produce static > > libraries rather than actual shared objects. This is due to several missing > > options that are required to correctly build shared objects using ld, as > > well as a mis-specified -share option (which should be -shared). Switching > > to the use of CC rather than LD and fixing the -shared option corrects > > these problems and builds the DSOs correctly. > > > > Signed-off-by: Neil Horman <nhorman at tuxdriver.com> > [...] > > --- a/mk/rte.lib.mk > > +++ b/mk/rte.lib.mk > [...] > > +ifeq ($(LINK_USING_CC),1) > > +# Override the definition of LD here, since we're linking with CC > > +LD := $(CC) > > +endif > [...] > > -O_TO_S = $(LD) $(CPU_LDFLAGS) -z muldefs -share $(OBJS-y) -o $(LIB) > > +O_TO_S = $(LD) $(CPU_LDFLAGS) -z muldefs -shared $(OBJS-y) -o $(LIB) > > I think that CPU_LDFLAGS should be prefixed with -Wl, in case of CC linking. > So blindly assigning CC to LD variable seems a bad idea. > Other makefiles have different O_TO_S commands depending of LINK_USING_CC. > I'm not so sure about that. Or more specifically, I wonder if some more rework isn't needed here. I say that because, while what you say makes sense in terms of formatting the CPU_FLAGS variable for use with CC, the only current use of CPU_LDFLAGS set -melf_i386, which IIRC is a gcc flag, not meant to be passed to LD. I can change the makefile to completely rewrite the comand based on LINK_USING_CC, but it seems to me that CPU_LDFLAGS should not be passed in the use of the LD case.
thoughts? Neil > > --- a/mk/rte.sharelib.mk > > +++ b/mk/rte.sharelib.mk > [...] > > -O_TO_S = $(LD) $(CPU_LDFLAGS) -share $(OBJS) -o > > $(RTE_OUTPUT)/lib/$(LIB_ONE) > > +O_TO_S = $(LD) $(CPU_LDFLAGS) -shared $(OBJS) -o > > $(RTE_OUTPUT)/lib/$(LIB_ONE) > > Why not using CC here whether LINK_USING_CC is enabled? > > Feel free to send a v3 ;) > -- > Thomas >
