Re: [Problem] mempcpy is missing? (FAQ alert)

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Max Bowsher wrote:

> Fix how? Unless I'm very much confused, this would require configure to
> create 2 new headers, containing lines like those below for every function
> that was in a header but did not link, AND then wrapping every include of
> system headers in every source file with #include "begin-system-madness.h"
> ... #include "end-system-madness.h".
>
> Example begin-system-madness.h:
> #define func1 __autoconf_func1_does_not_link
> #define func2 __autoconf_func2_does_not_link
> #define func3 __autoconf_func3_does_not_link
>
> Example end-system-madness.h:
> #undef func1
> #undef func2
> #undef func3
>
>
> Do you really intend to do that?
No.  I'm going to fix memcpy.  If it ain't broke, don't mess with it. 
memcpy is broken.  I'll fix *that*.

> Isn't this the first time anyone has reported these problem prototypes
> messing up a compile?
Nope; I've done it several times.  'course, my solution at those times 
was the same as yours: submit a patch to cygwin.din.

And really, it's hard to blame most packages for simply assuming that if 
(e.g.) memcpy.h exists then Well Of COURSE memcpy() is available.

Slightly more paranoid maintainers might simply die during configure if 
memcpy() can't be found.  Only the truly obsessed-with-portability would 
provide alternate implementations (bcopy?) if memcpy() wasn't found, but 
memcpy.h was.

Face it, most platforms *aren't that strange*.  We are.  Most platforms 
do NOT have mismatch between their headers and their kernel -- even 
other newlib platforms.  We do, because of the DLL issues.

For other newlib platforms (e.g. embedded systems?) if the header 
declares the function, then the function is there.  'Nuff said.  If it 
isn't declared, then it isn't in the kernel -- but the developer 
probably needs it -- and it's just as easy to code it up and submit it 
to newlib, or code it up and keep a local compat lib, or code it up and 
incorporate it into your project's code, as it is to worry about arcane 
"if this but not that" configuration issues -- because you'd STILL have 
to provide some sort of alternate implementation.

Remember, most folks who work with embedded systems -- newlib's largest 
area of application IMO besides cygwin -- don't "port" stuff for fun. 
They need to compile a product, on a specific target (and usually not 27 
different targets).

> (NB: I mean breaking a compile that would have otherwise worked, instead of
> simply delaying failiure to the link stage).
Oh, well, I dunno about that.  My failures were at link time -- although 
I did run into something similar once when I was using 
AC_REPLACE_FUNC()...e.g. "provide fallback if not found'.

I'd just as soon avoid all of the synchronization issues between 
cygwin-gettext and Bruno-gettext...we *are* currently very different 
thanks to the libtoolization with CVS libtool.  Because libtool-1.5 is 
due RSN, I was hoping to push our changes upstream and return to baseline...

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/