bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems


From: Steven M. Schweda
Subject: Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems
Date: Wed, 28 Sep 2011 08:39:30 -0500 (CDT)

From: Micah Cowan <address@hidden>

> 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?

   Not really practical here.

> 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.

   Sadly, the whole GNU autoconf mess relies on having too much of the
whole GNU infrastructure available to make it practical here.  (And
manually editing a "config.h" produced elsewhere gets more annoying
every time its size doubles, and half its old content gets revamped.)

> 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.

   Those aren't the droids you're looking for.  Try "lib/stdio.in.h"
(which I also try very hard to ignore).

   It appears that I can do the following in my "config.h_vms":
      /* #undef HAVE_SNPRINTF */
      #define snprintf rpl_snprintf
and just use the replacement snprintf() always.

   That leaves the other reported problems ("src/connect.c",
"src/init.c"), plus a couple of still unexplained %SYSTEM-F-ACCVIO
disasters to investigate.  But it's a start.

------------------------------------------------------------------------

   Steven M. Schweda               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547



reply via email to

[Prev in Thread] Current Thread [Next in Thread]