Mail Archives: cygwin/2003/02/15/18:25:18
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/
- Raw text -