From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: How about using static link instead of dynamic loaded dlls? Date: Thu, 05 Jun 2003 13:06:02 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <3EDF322A.4050807@gnu.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1054816546 28632 80.91.224.249 (5 Jun 2003 12:35:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Jun 2003 12:35:46 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Jun 05 14:35:44 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19Nty3-0007RO-00 for ; Thu, 05 Jun 2003 14:35:43 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19NuG6-00009z-00 for ; Thu, 05 Jun 2003 14:54:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Ntyf-0004Nv-FB for emacs-devel@quimby.gnus.org; Thu, 05 Jun 2003 08:36:21 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NtWL-00026l-Bi for emacs-devel@gnu.org; Thu, 05 Jun 2003 08:07:05 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NtVz-00024I-29 for emacs-devel@gnu.org; Thu, 05 Jun 2003 08:06:44 -0400 Original-Received: from [209.61.173.204] (helo=integrasp.com) by monty-python.gnu.org with smtp (Exim 4.20) id 19NtV4-00020S-DO for emacs-devel@gnu.org; Thu, 05 Jun 2003 08:05:46 -0400 Original-Received: (qmail 11476 invoked from network); 5 Jun 2003 12:00:05 -0000 Original-Received: from host217-37-167-241.in-addr.btopenworld.com (HELO ntserver.altio.com) (217.37.167.241) by 66.216.96.43 with SMTP; 5 Jun 2003 12:00:05 -0000 Original-Received: from gnu.org (ALTIOJR [192.168.111.42]) by ntserver.altio.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L60A2KF5; Thu, 5 Jun 2003 13:05:54 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en Original-To: Robin Hu In-Reply-To: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14759 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14759 Robin Hu wrote: >>>>>>"Jason" == Jason Rumney writes: > > > Jason> If you explain what problems you are having, we may be able > Jason> to fix them. Linking the image libraries statically might > Jason> work well for people like yourself who compile Emacs > Jason> yourself, but in the Windows world you are the minority I am > Jason> afraid, so linking dynamically is more flexible for binary > Jason> distribution. > > Well. The problems I have are really problems of lacking of > version control for dll files. There is version control for DLL's, we just need to know which versions don't work so we can avoid using them. We can also perform tests on the presence of functions in the DLLs if the version information is insufficient. > 2/ Dlls compiled by gcc may not cooperate well with programs > compiled by msvc. When I used libjpeg from > sf.net/projects/gnuwin32, Emacs compiled by msvc failed to open > jpeg files. This may be a struct alignment issue, as I think it only occurs with certain optimization settings of MSVC. Hopefully the library developers provided a way for us to detect this. > While compiling with msvc with optimization turned on, Emacs will > emit an access vilation exception while load a tiff file or a png > file. I believe the problem is something related to lookup_image(), > but debug an optimized program is really hard. ;-( Why is it hard? You should be able to get at least some idea of where it is going wrong my single stepping through lookup_image. Maybe some of the underlying machine instructions are not what you would expect from looking at the current line, but that should not stop you from getting a general idea of what is happening.