On 09/27/2011 10:22 PM, Steven M. Schweda wrote: > It's still early, but here are the initial complaints... > > "lib/snprintf.c" now ignores HAVE_SNPRINTF. In previous wget > versions, I could compile "snprintf.c" and not get a redundant > snprintf() if HAVE_SNPRINTF was defined ("%LINK-W-MULDEF, symbol > DECC$TXSNPRINTF multiply defined"). I can supply a conditional jacket > for "snprintf.c", but should I need to (now)?
lib/snprintf.c is imported directly from outside (from gnulib), so there's not going to be a lot of control exercised over it from a wget-developer perspective. I'm sure if it came to it, some sort of patch-application phase could be added, but I imagine that Giuseppe would be resistant to such a thing until it were truly necessary. Gnulib in general doesn't use HAVE_FOO as the sole determiner of whether to use something. It will happily supply its own snprintf if it thinks for even one second that the system's snprintf isn't perfect. Which mostly means, doesn't do exactly everything the latest glibc's does, the way it does it. Whether you actually needed that particular feature or not. But, on the other hand, when it chooses to supply its own, it carefully macros it away so that the real linker name is something different. However, the way it does this (and the way it decides whether to even build sprintf.c in the first place), is embedded in the expected process that the user will use the ./configure script to set up the environment and determine which bits from gnulib to include; doing it any other way (as you're attempting) is bound to be painful. I wonder if it might be worth it to run ./configure under a POSIX-compatible shell thing to produce sane build stuff (assuming other VMSen will be similar enough to use whatever results?), and then include the results in your offering? That violates the philosophy behind autoconf, of course, makes it closer to an Imake thing, but then you're not going to make them use it anyway, so might as well see if you can use it yourself to make life at least a little easier. In this case, the logic that does a rename of snprintf seems to be at the end of "vasnprintf.h" rather than directly in snprintf.c. -- Micah J. Cowan http://micah.cowan.name/