Re: CVS psmith make: Whoops; configure wasn't looking for memmove.

[Soren A]

"Paul D. Smith" <address@hidden> wrote in
news:address@hidden: 

> %% Soren A <soren_andersenMuNGeMe6#[)address@hidden> writes:
> 
>   sa> Yes, and because of that, build on Win32-ish was failing; but
>   also sa> you need to have configure check for bcopy(), because
>   bcopy() sa> isn't there on Win32- Gnu-ish platforms (I have been told
>   it is sa> part of GlibC, but Cygwin, etc are based on Newlib, not
>   GlibC). 
> 
> I don't understand this.  If bcopy() isn't there and memmove() is
> (which wasn't being checked but now will be) then the code in make.h
> as-is works.
> 
> Doesn't it?

It really doesn't. As I think you know, I started a couple of weeks ago
working with the source for rc1 (patched as I keep mentioning -- the
patch which you acknowledged in Message-ID:
<address@hidden>); I first
built on Cygwin, then started on MinGW. 

I am trying to reprise this in detail because you are right on several
counts (due to my lack of expertize and knowledgeability -- which is why
i have been hoping other folks would take up this job ;-). But apparently 
not getting the whole picture yet on others.

On Cygwin, bcopy() doesn't present a problem. In fact this is because the
Cygwin system headers define bcopy() as a macro (in fact using
memmove(), that is, the macro resolves to a call to memmove()). 

On MinGW, I got link time errors due to all the bcopy() instances being
undefined references. When I gained the understanding of which gcc (cpp)
flags to use when compiling to catch undefined functions, it showed that
there is no bcopy() whatsoever in MinGW. It is not defined as a macro nor
existant as a real function. 

>   sa> A part of <make.h> needs to be rewritten because it appears that
>   sa> at some point an ad-hoc (?) addition was made to try to deal with
>   sa> lack of bcopy(), but was done not properly, by getting into
>   sa> configure and making the needed changes there.
> 
> I looked at the diffs (thanks) and this is the only one in make.h:
> 
>   -# if defined(HAVE_MEMMOVE) && !defined(bcopy)
>   +# if ! defined(HAVE_BCOPY)
>    #  define bcopy(s, d, n)    memmove ((d), (s), (n))
>    # endif
> 
> I don't think this is correct--or at least not more correct than the
> current behavior.

Yes, as i wrote above, this is a point you are quite correct on. I did a
lousy job of re-writing the macro. However, now that you've looked for
yourself I think you can see that it DOES need to be re-written. The old
way: [as you wrote] 
> The current behavior says "if we have memmove() and bcopy() is not a
> macro (because some systems define it as a macro and in that case if we
> redefine it we will get an error) then define bcopy() as a macro that
> invokes memmove()".

Somehow that just isn't working. Somehow, and i don't understand why --
and if it's a bug in cpp then it is SO far out of my league -- checking
for bcopy() being NOT a macro isn't enough. The case on MinGW, where it
is NOT a macro and NOT defined as a real function -- where it simply
doesn't exist in any form -- is not being taken care of the old way.

> I believe this is correct, even on MINGW systems.

Empirically not correct, even if it is in theory. Because the build broke
until i fixed it, even if my fix as you see it now isn't suitably
portable outside the MinGW context. 

> Your change says "if configure can't find a bcopy(), then define it to
> be memmove()".
> 
> I think the only practical difference (except for weird cases where
> configure can't find bcopy() but it does end up being defined as a
> macro in the actual build, where your change would fail--but I doubt
> that would happen in real life) is that the original prefers memmove()
> if it exists, and your change prefers bcopy() if it exists.

You've completely lost me. Either you are wrong now or I am completely
not understanding how to read a C macro statement. Or your wording is
sufficiently different from your intention that I am being confused by
it. 

I'll have to rephrase my understanding of what you just wrote above as
well as my understanding of what that macro statement says. The latter
first: 

The new macro statement says, to me: "if *configure* finds that bcopy()
is not present, then define bcopy() as a macro that resolves to a call to
memmove() [with the function parameters suitably rearranged]." My change
doesn't prefer bcopy(), it defines bcopy() as a macro that resolves to
memmove(). 

As for the former, your "weird case" is what I cannot understand. This
section of make.h is the only place where we get to determine what the
compiler will think bcopy() means for the build; I don't understand why
you'd phrase it as if the build were something external to the parsing of
this header. 

I think that guard macros to make sure that bcopy() hasn't already been
redefined as something macro-ish would be appropriate (in case somebody
adds something in the future that doesn't exist now); what is quite
clear, though, regardless, is that the old way broke on MinGW. 

Because your wording seems to imply surprise that there was a problem
here, I'll remind you that the mainline GNU make sources are not what
MinGW or Cygwin users have been using (for years), as you mentioned to me
recently; I believe that my change is basically just a copy-and-paste of
what the old-ish MinGW make port i have repeatedly referred to did. So
this isn't a new problem but one that you never heard about because the
code you maintain isn't the same code the users of this|ese platform|s
have been using -- the code base has been forked for a long time and now
we are embarking on resolving that? 

I'll write a new macro block for this issue and make a new diff in the
next couple of days -- it will have to be a compound macro statement i am
sure because the simple ones (either old or new) probably are
insufficient. What will help is to be sure that from now on, bcopy() will
be handled by the config.h system and memmove() will too. To be clear,
that means that there will be macros HAVE_MEMMOVE and HAVE_BCOPY defined
if these functions are present on the host system. I'll count on it.
Neither was being checked for in rc1. My mistake is that i did not cause
configure to check for MEMMOVE too (because it is ISO C, no?) in the
changes I made that are in the present package patch you looked at. To
not do so was a short-cut. 

The larger issue here is that although you may have thought that the
existing Autotools-based build configuration setup files for 'make' was
sufficient for all platforms for any significant numbers of 'make' users,
it in fact was not for these Gnu-ish MS-Win32 platforms (platforms that
now have a Bourne-compatible shell and GNU toolsuite sufficient to run
'configure' scripts -- this is a relatively new development on MinGW).
However, the only core C library function that appeared as a problem to
me was bcopy() so when this gets taken care of a whole category of
portability issues will (likely) be done with and other things can be
focused on. There are MANY more build-configuration issues to be
resolved, Earnie Boyd has written about some of that separately. 

  Best,
    Soren A