Charles Wilson wrote: > Christopher Faylor wrote: > >> >> Of course we're going to fix cygwin. I just checked in a fix. >> While I assume this will probably be the end of it since no one will >> go to the effort of trying to fix libintl's configury and, if they >> did, there would probably be no official response anyway, the >> complete and correct fix is to modify libintl. Then people using >> cygwin 1.3.10 - 1.3.20 could benefit too. > > No, I'm going to fix gettext, thankyouverymuch.
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? > the thing that scares > me, is I like to keep gettext, in particular, synced up with the > official version. the reason is because gettextize is used to install > the actual source code into a target package. By changing the code on > cygwin, anyone maintaining a package on cygwin will generate different > dist tarballs than if they were maintaining it on linux. Badness. > > So, I dunno if I should fold the change into our distribution and then > push it to Bruno, or push it to Bruno and simply update cygwin's > version when Bruno releases 0.11.6 Isn't this the first time anyone has reported these problem prototypes messing up a compile? (NB: I mean breaking a compile that would have otherwise worked, instead of simply delaying failiure to the link stage). Max. -- 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/
