On 10/24/2013 04:16 PM, [email protected] wrote: > Hi! >>>> diff --git a/testcases/kernel/syscalls/ipc/msgctl/Makefile >>>> b/testcases/kernel/syscalls/ipc/msgctl/Makefile >>>> index f467389..ae61b51 100644 >>>> --- a/testcases/kernel/syscalls/ipc/msgctl/Makefile >>>> +++ b/testcases/kernel/syscalls/ipc/msgctl/Makefile >>>> @@ -18,6 +18,15 @@ >>>> >>>> top_srcdir ?= ../../../../.. >>>> >>>> +FILTER_OUT_MAKE_TARGETS := libmsgctl >>>> + >>>> include $(top_srcdir)/include/mk/testcases.mk >>>> include $(abs_srcdir)/../Makefile.inc >>>> include $(top_srcdir)/include/mk/generic_leaf_target.mk >>>> + >>>> +SRCS ?= $(wildcard $(abs_srcdir)/*.c) >>>> +OBJS := $(notdir $(patsubst %.c,%.o,$(SRCS))) >>>> +.INTERMEDIATE: $(OBJS) >>>> + >>>> +$(MAKE_TARGETS): %: %.o libmsgctl.o >>>> +libmsgctl.o: libmsgctl.h >>>> diff --git a/testcases/kernel/syscalls/ipc/msgctl/libmsgctl.c >>>> b/testcases/kernel/syscalls/ipc/msgctl/libmsgctl.c >>>> new file mode 100644 >>>> index 0000000..fa77b56 >>> This is too hacky what about building .a library instead as it's done in >>> testcases/kernel/mem/lib ? >>> >>> I've looked into the lib.mk and it looks like you don't even have to put >>> the lib in the separate directory if you set LIBSRC in the corresponding >>> Makefile. >> Cyril, could you show an example of doing this (placing test case >> sources and static libraries sources in the same directory), please? >> >> I tried to do what you said but couldn't manage it :( >> >> I used this Makefile: >> >> top_srcdir ?= ../../../../.. >> >> LIBSRCS := $(abs_srcdir)/libmsgctl.c >> INTERNAL_LIB := libmsgctl.a >> >> include $(top_srcdir)/include/mk/testcases.mk >> include $(abs_srcdir)/../Makefile.inc >> include $(top_srcdir)/include/mk/generic_leaf_target.mk >> include $(top_srcdir)/include/mk/lib.mk >> >> And got error: >> ../../../../../include/mk/lib.mk:66: warning: overriding commands for >> target `../lib/libipc.a' >> /home/stas/ltp/testcases/kernel/syscalls/ipc/msgctl/../Makefile.inc:34: >> warning: ignoring old commands for target `../lib/libipc.a' >> make: Circular ../lib/libipc.a <- ../lib/libipc.a dependency dropped. >> if [ -z "../lib" ] ; then \ >> echo "Cowardly refusing to create empty archive"; \ >> exit 1; \ >> fi >> ar -rc "../lib/libipc.a" ../lib >> ar: ../lib/libipc.a: Error reading ../lib: Is a directory >> make: *** [../lib/libipc.a] Error 1 > Ah, there is the include $(abs_srcdir)/../Makefile.inc that sets LIB > to ../lib/libipc.a which breaks the lib.mk as there now there are two > rules for making the library. One that runs make in ../lib/ from the > Makefile.inc and second in lib.mk. Renaming the LIB to LIBIPC in > Makefile.inc fixes this one. > >> And I think that I found an another issue we should overcome - lib.mk >> defines MAKE_TARGETS: >> >> MAKE_TARGETS := $(LIB) >> >> generic_leaf_target.mk also does it. >> >> So It should not be trivial to include both files (lib.mk and >> generic_leaf_target.mk) into one Makefile. >> I suppose that in that case we have to implicitly define MAKE_TARGETS in >> our Makefile. > Now this one is more complicated, but solvable. > > First of all we need to change the part in lib.mk to > > MAKE_TARGETS += $(LIB) > > Then define MAKE_TARGETS explicitly in the Makefile (we need that anyway > for lib: tests dependency) and add LDFLAGS and LDLIBS. The full Makefile > looks like: > > top_srcdir ?= ../../../../.. > include $(top_srcdir)/include/mk/testcases.mk > > LIBSRCS := libmsgctl.c > INTERNAL_LIB := libmsgctl.a > MAKE_TARGETS := $(patsubst %.c,%,$(wildcard msgctl??.c)) > > $(MAKE_TARGETS): $(INTERNAL_LIB) > > LDFLAGS += -L$(abs_builddir) > LDLIBS += -lmsgctl > > include $(abs_srcdir)/../Makefile.inc > include $(top_srcdir)/include/mk/lib.mk > include $(top_srcdir)/include/mk/generic_leaf_target.mk > > See also attached patch with all the changes and check if that works for > you. If so I will commit change to the lib.mk as separate patch and ask > you to include changes in Makefile.inc in your patchset.
Yes, It works. But the compilation is performed as follows: gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -I/home/stas/ltp/testcases/kernel/include -I/home/stas/ltp/testcases/kernel/syscalls/ipc/msgctl/../lib -I../../../../../include -I../../../../../include -I../../../../../include -I../../../../../include -L/home/stas/ltp/testcases/kernel/syscalls/ipc/msgctl -L/home/stas/ltp/testcases/kernel/syscalls/ipc/msgctl/../lib -L../../../../../lib -L../../../../../lib msgctl01.c libmsgctl.a -lltp -lmsgctl -lipc -o msgctl01 So gcc 'links' msgctl01.c and libmsgctl.a at once (and additionally is passed -lmsgctl option). How do you think, maybe introduce my favourite .INTERMEDIATE target into Makefile? :) Like this: MAKE_TARGET_OBJS := $(addsuffix .o,$(MAKE_TARGETS)) .INTERMEDIATE: $(MAKE_TARGET_OBJS) $(MAKE_TARGET_OBJS): $(INTERNAL_LIB) #$(MAKE_TARGETS): $(INTERNAL_LIB) With this option the compilation is as follows: gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -I/home/stas/ltp/testcases/kernel/include -I/home/stas/ltp/testcases/kernel/syscalls/ipc/msgctl/../lib -I../../../../../include -I../../../../../include -I../../../../../include -I../../../../../include -c -o msgctl01.o msgctl01.c gcc -L/home/stas/ltp/testcases/kernel/syscalls/ipc/msgctl -L/home/stas/ltp/testcases/kernel/syscalls/ipc/msgctl/../lib -L../../../../../lib -L../../../../../lib msgctl01.o -lltp -lmsgctl -lipc -o msgctl01 I can't find any reasonable arguments for this approach. Just feels that it's more 'correct'. But, anyway, you proposal works for me. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
