Charles Wilson wrote: > The allocsa module includes eealloc.m4 in its filelist -- but it doesn't > "depend" on the eealloc module --
Right. > this allows the LGPL allocsa module to > avoid bringing in the GPL eealloc.h, so as not to run afoul of GPL. The license question is secondary. The primary goal here is not to define inline functions in the header files unless necessary. > If eealloc.m4's contributions to configure cause config.h to #define > malloc/realloc as rpl_malloc/rpl_realloc, those symbols do not > necessarily exist -- because allocsa doesn't depend on the > malloc/realloc modules. eealloc.m4 doesn't #define malloc/realloc. It only defines indicators MALLOC_0_IS_NONNULL, REALLOC_0_IS_NONNULL describing malloc's/realloc's behaviour. If you got malloc/realloc #defined, it is certainly because you used the modules 'malloc'/'realloc'. > Since all these (allocsa, malloc, realloc) modules are LGPL, I suggest > that the allocsa module should add a dependency on the malloc and > realloc modules. No. The point of m4/eemalloc.m4 is precisely to allow optimizing code for glibc platforms, without penalizing non-glibc platforms through extra function calls for malloc/realloc throughout the package. And I don't understand your argumentation about LGPL vs. GPL, since there is no license problem in the 'allocsa' module in the first place. Bruno
