From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Problem with library images on Windows (again) Date: Fri, 20 May 2005 18:29:06 +0200 Message-ID: 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> <01c55d4a$Blat.v2.4$8e2e76e0@zahav.net.il> Reply-To: Juanma Barranquero NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1116606864 9643 80.91.229.2 (20 May 2005 16:34:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 May 2005 16:34:24 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 20 18:34:18 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DZAR4-0003i2-QL for ged-emacs-devel@m.gmane.org; Fri, 20 May 2005 18:33:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DZATw-0007Gn-0b for ged-emacs-devel@m.gmane.org; Fri, 20 May 2005 12:36:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DZASp-0005kR-86 for emacs-devel@gnu.org; Fri, 20 May 2005 12:35:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DZASk-0005hO-LB for emacs-devel@gnu.org; Fri, 20 May 2005 12:35:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DZASj-0005Yf-RR for emacs-devel@gnu.org; Fri, 20 May 2005 12:35:01 -0400 Original-Received: from [64.233.184.194] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DZAVU-0003Ip-Nq for emacs-devel@gnu.org; Fri, 20 May 2005 12:37:52 -0400 Original-Received: by wproxy.gmail.com with SMTP id 50so1220424wri for ; Fri, 20 May 2005 09:29:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UrwOlvoHEZN65O64t+JJMJUtDvQpdYlyhe492P4lIXOo3EmWoicLduN/RwohYSfNWZX/c92DglQ+oblPT+xYGdhUErUyBm6dr4JZt1UwuylLlqZHbTnKsN0BNC1raQCQoWsV1BBdgIwDJsUhJOR32eJmQitbc1+J3feRHJoot4Y= Original-Received: by 10.54.50.46 with SMTP id x46mr1874114wrx; Fri, 20 May 2005 09:29:06 -0700 (PDT) Original-Received: by 10.54.82.6 with HTTP; Fri, 20 May 2005 09:29:06 -0700 (PDT) Original-To: emacs-devel@gnu.org In-Reply-To: <01c55d4a$Blat.v2.4$8e2e76e0@zahav.net.il> Content-Disposition: inline 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:37397 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37397 > 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. Yes, in general, for static linking (either with static libraries, or with stubs to dynamic ones). But in this case, MSVC is not compiling/liking statically against any function as defined in the header. There are no TIFF functions, as far as it knows, just a bunch of variables of type FARPROC that we're assigning and calling, so whether there's FAR CDECL TIFFOpen(...); or FARPROC TIFFOpen(...); on the header should be irrelevant. MSVC knows nothing about TIFFOpen; it just knows there's a variable fn_TIFFOpen which gets initialized with a call to GetProcAddress() and called afterwards. And it's the type of fn_TIFFOpen which counts. > 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? Perhaps Jason's right and the bug is just not noticeable. Think of this: if lookup_image didn't use a temporary variable that gets assigned to a register and accidentally clobbered by tiff_load, we wouldn't see the problem with MSVC either. > 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. Well, I hoped that the Win32 version would use the more common convention for DLL exports on Windows (that is, pascal). But it doesn't. --=20 /L/e/k/t/u