This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]