Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <41084193.60206@nycap.rr.com> Date: Wed, 28 Jul 2004 20:15:15 -0400 From: Mathieu Malaterre Reply-To: mathieu AT malaterre DOT com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Charles Wilson CC: cygwin AT cygwin DOT com Subject: Re: INT32: jmorecfg.h References: <4105AB1C DOT 8060006 AT nycap DOT rr DOT com> <20040727150250 DOT GC16364 AT trixie DOT casa DOT cgf DOT cx> <41073BD1 DOT 3060707 AT cwilson DOT fastmail DOT fm> In-Reply-To: <41073BD1.3060707@cwilson.fastmail.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Note-from-DJ: This may be spam Charles Wilson wrote: > Christopher Faylor wrote: > >> On Tue, Jul 27, 2004 at 10:01:08AM +0100, Dave Korn wrote: >> >>> I remember hitting this problem with a cygwin build of libjpeg once. >>> The correct answer is probably that jmorecfg.h shouldn't arbitrarily >>> define INT32 globally without first performing an autoconf test to see >>> if there's something in the system includes that already provides it, >>> isn't it? >> >> >> >> Yes. Just adding more and more ifdef guards around the INT32 definition >> is not the way to go. > > > Unfortunately, the ijg group does not distribute the autoconf source for > libjpeg's configure script. It's on my todo list to really truly > autoconfiscate libjpeg (and libtiff) -- which will make things like this > easier. But it's not a very high priority. > > Nor am I all that worked up about this INT32 issue. jmorecfg.h is > present in all builds of libjpeg; I don't understand why INT32 is > causing a problem *only* on cygwin. It seems that you should be seeing > the problem on all platforms, or none. Since your package is showing > this behavior only on cygwin, I suspect something wacky in (a) your > cygwin environment, or (b) the procedure/configury you're using to build > on cygwin (e.g. mixing native and cygwin headers). > > Given that, I'm not going to rush out and fix this right away, because I > only have bad choices: (1) add yet another #ifdef hack, or (2) spend a > week teasing out and reverse-engineering the autoconfigury source files... Alright, Here is what we did to work around this problem instead of directly include jpeglib.h we do: /* Work-around for a conflict between windows.h and jpeglib.h in cygwin. If ADDRESS_TAG_BIT is defined then BaseTsd.h has been included and INT32 has been defined with a typedef, so we must define XMD_H to prevent the jpeg header from defining it again. */ # if defined(__CYGWIN__) && defined(ADDRESS_TAG_BIT) && !defined(XMD_H) # define XMD_H # define VTK_JPEG_XMD_H # endif # include # include # if defined(VTK_JPEG_XMD_H) # undef VTK_JPEG_XMD_H # undef XMD_H # endif http://vtk.org/cgi-bin/viewcvs.cgi/Utilities/vtk_jpeg.h?r1=1.1&r2=1.2&root=VTK The whole problem was that one can't do: #include #include And according to Christopher, this is "not designed to work well.". Thus I don't believe the mistake is in VTK. My guess is if we don't see in other plateform is because they -luckily- don't use any typedef INT32. HTH Mathieu -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/