On Mon, Dec 19, 2022 at 10:02:42AM -0700, jim.cromie@xxxxxxxxx wrote: > On Mon, Dec 19, 2022 at 9:37 AM <jim.cromie@xxxxxxxxx> wrote: > > > > Id like to build 2 modules (with different names) > > from a single source file, with 2nd being dependent > > on the 1st. > > > > Specifically, Ive got: > > lib/test_dynamic_debug.c > > > > I want > > A: lib/test_dynamic_debug.ko > > B: lib/test_dynamic_debug_submod.ko > > > > I expect that the code just needs an #ifdef #else #endif > > block to clearly put the dependor & dependee elements > > next to each other. > > > > My question is how to do this in the Makefile ? > > this does most of it > > > > --- a/lib/Makefile > > +++ b/lib/Makefile > > @@ -78,7 +78,8 @@ obj-$(CONFIG_TEST_SORT) += test_sort.o > > obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o > > obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o > > obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o > > -obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o > > +obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o > > test_dynamic_debug_submod.o > > +CFLAGS_test_dynamic_debug_submod.o += -DTEST_DYNAMIC_DEBUG_SUBMOD > > obj-$(CONFIG_TEST_PRINTF) += test_printf.o > > > > but how do I tell it the 2nd target ? > > more to the point, this doesnt work (nor do permutations), I miss something: > > +($obj)/test_dynamic_debug_submod.o: ($obj)/test_dynamic_debug.c Pleaase don't do that :( If you _REALLY_ need to do this, then just #include your .c file into two other .c files. And keep everything in your #included .c file static to make sure you don't have duplicate global symbols. Otherwise it is impossible for the same .o to be linked into two different modules (or into the kernel image itself) as there will be duplicate global symbols (as that .c file had to have something global for you to be able to call into it.) But step back, what is the problem that you really want to solve here that you feel somehow a single .c file built twice would be correct? Especially with code in lib/ that should not be needed at all as you are building "library" functions that only get included if they are actually used in the large kernel image. thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
