> From: Paul Smith <psm...@gnu.org> > Cc: bug-make@gnu.org > Date: Mon, 29 Apr 2013 13:59:16 -0400 > > > 1. Doesn't the FSF frown upon capability to load _any_ dynamic > > objects? I think they like the GCC method whereby each extension > > is required to define a symbol with a certain name > > (plugin_is_GPL_compatible in GCC), which is tested at load time, > > before the dynamic object is allowed to be loaded. > > Hm. I guess the concern is that someone will introduce a proprietary > "plug-in"?
Yes. > > 2. The fact that the dynamic object's file extension (.so) is exposed > > to the Makefile is unfortunate, because it will hurt portability of > > Makefiles: the extension on Windows is .dll. Can we omit the > > extension and append it internally? > > Yes, that should be possible. My concern is that, at least on UNIX, the > rules for this are complex and I don't want to reimplement the runtime > linker :-). Maybe something like, first try the path as given and if > that fails, try adding arch-specific extensions? No, much simpler: _always_ append _a_single_ arch-specific extension, and try loading that. We should document that extension; using the one that is used by default by the compiler for producing shared libraries should be good enough, I think. > The other problem here is that we want to allow rebuilding of dynamic > objects then re-exec'ing make... if we're trying different extensions > THAT can be a real problem... what order do we do this in? Again, let's use only one extension. .so on Unix, .dll on Windows. Same as the linker does when you say -lFOO. > > 3. I suggest to extend the search for dynamic object to a > > Make-specific directory (${prefix}/share/make/), before falling > > back to the "system-specific path". Or maybe even not fall back to > > any system-specific defaults, because those are generally set for > > shared libraries, not for plugins. (You do NOT want to know where > > Windows will look for shared libraries.) > > I'm not sure about having a make-specific directory. It's not so easy > to do in UNIX--we'd have to modify the LD_LIBRARY_PATH env. var. I > suppose. ??? I thought dlopen will gladly use an absolute file name, without looking at LD_LIBRARY_PATH. Was I wrong? > Also we don't really have a precedent of a "make-specific" directory > like that. Gawk puts them into ${prefix}/lib/gawk. > > . I suggest to request that the buffers for expansions and > > evaluation by gmk_expand and gmk_eval be provided by the caller. > > It is not safe (and not very convenient) to return buffers > > allocated internally by these functions, because the dynamic > > object might be compiled/linked with an incompatible > > implementation of memory allocation routines. > > I don't see how this can work easily. We have no idea how large the > buffer will be until after we complete the expansion/eval. The only way > this could work is to use the snprintf() model where we do the expansion > as now, and if it's too small we return the expected length and they'd > have to re-invoke with a larger buffer. Yes, that's what I had in mind. > I think we should go with this for now. Hopefully users that do have a > problem will find a way to make this work. At least on Windows, it can be a real problem, because the libraries with which a shared object was linked are hardcoded into it, and there's more than one way of allocating memory. How about a callback for allocating memory? Then Make could call that callback and get memory that the extension could free. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make