From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: Problem with library images on Windows (again) Date: Fri, 20 May 2005 17:44:16 +0300 Message-ID: <01c55d4a$Blat.v2.4$8e2e76e0@zahav.net.il> References: <01c55c26$Blat.v2.4$0ef86680@zahav.net.il> <01c55ca5$Blat.v2.4$dd149500@zahav.net.il> <01c55d0c$Blat.v2.4$8d418800@zahav.net.il> <428DB8F3.3070108@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1116601060 18343 80.91.229.2 (20 May 2005 14:57:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 May 2005 14:57:40 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 20 16:57:38 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DZ8uj-0004v2-2W for ged-emacs-devel@m.gmane.org; Fri, 20 May 2005 16:55:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DZ8xa-0005EP-Fm for ged-emacs-devel@m.gmane.org; Fri, 20 May 2005 10:58:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DZ8wA-0004N4-Kv for emacs-devel@gnu.org; Fri, 20 May 2005 10:57:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DZ8w3-0004Fb-Pz for emacs-devel@gnu.org; Fri, 20 May 2005 10:57:15 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DZ8w1-00047e-1A for emacs-devel@gnu.org; Fri, 20 May 2005 10:57:09 -0400 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DZ8vq-00004s-Dk for emacs-devel@gnu.org; Fri, 20 May 2005 10:56:58 -0400 Original-Received: from zaretski (IGLD-83-130-247-87.inter.net.il [83.130.247.87]) by romy.inter.net.il (MOS 3.5.8-GR) with ESMTP id BGY89177 (AUTH halo1); Fri, 20 May 2005 17:47:45 +0300 (IDT) Original-To: Juanma Barranquero X-Mailer: emacs 22.0.50 (via feedmail 8 I) and Blat ver 2.4 In-reply-to: (message from Juanma Barranquero on Fri, 20 May 2005 12:42:09 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:37392 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37392 > Date: Fri, 20 May 2005 12:42:09 +0200 > From: Juanma Barranquero > > Unless I'm wrong, the issue is not how the functions are defined on > the headers, because we don't statically link against the functions, > but how are they compiled in the library and how do we define the > fn_XXX pointers to them. It's the issue with both: the prototypes in the header files should be consistent with how the functions were compiled, since those prototypes are the only way for the compiler to know how the functions were compiled. If it doesn't know that, it might produce wrong code. > In this case, the GnuWin32 TIFF 3.7.2 > libraries seem to be compiled to use C calling conventions, but we > declare pointers to them with DEF_IMGLIB_FN, which says unequivocally > that they're FARPROC (i.e, "pascal"). That seems to be the problem. What I still don't get is how come the same declaration that uses FARPROC works for the MinGW build? Can you figure this out? If we know this, we could fix the DEF_IMGLIB_FN macro so that it does TRT for both compilers, e.g., by using __MINGW__ condition. > The TIFF page in gnuwin32.sourceforge.net says: > > "The GnuWin32 distribution comes in two versions. The ordinary version > uses the standard Unix equivalents, such as fopen and read, for input > and output, the other version (Tiff-win32) uses the Win32 API > functions, such as CreateFile and ReadFile, for input and output. The > ordinary version (Tiff) is more suitable for porting Unix programs, > the Win32-API version is more suitable for writing Win32 programs." This doesn't say anything about the calling conventions, just about the inner workings of the functions. So I'm not surprised that both versions have the same effect.