This is the mail archive of the
mailing list for the Cygwin project.
Re: [Problem] mempcpy is missing? (FAQ alert)
Max Bowsher wrote:
No. I'm going to fix memcpy. If it ain't broke, don't mess with it.
memcpy is broken. I'll fix *that*.
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".
#define func1 __autoconf_func1_does_not_link
#define func2 __autoconf_func2_does_not_link
#define func3 __autoconf_func3_does_not_link
Do you really intend to do that?
Nope; I've done it several times. 'course, my solution at those times
was the same as yours: submit a patch to cygwin.din.
Isn't this the first time anyone has reported these problem prototypes
messing up a compile?
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
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
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'.
(NB: I mean breaking a compile that would have otherwise worked, instead of
simply delaying failiure to the link stage).
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...
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html