unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jason Rumney <jasonr@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: How about using static link instead of dynamic loaded dlls?
Date: Thu, 05 Jun 2003 13:06:02 +0100	[thread overview]
Message-ID: <3EDF322A.4050807@gnu.org> (raw)
In-Reply-To: <uadcw4ws1.fsf@knight.6test.edu.cn>

Robin Hu wrote:
>>>>>>"Jason" == Jason Rumney <jasonr@gnu.org> 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.

  reply	other threads:[~2003-06-05 12:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-05  3:21 How about using static link instead of dynamic loaded dlls? Robin Hu
2003-06-05  6:53 ` Jason Rumney
2003-06-05  9:05   ` Mike Woolley
2003-06-05  9:51     ` Jason Rumney
2003-06-05 12:28       ` Benjamin Riefenstahl
2003-06-05 10:57   ` Robin Hu
2003-06-05 12:06     ` Jason Rumney [this message]
2003-06-05 19:38       ` Juanma Barranquero
2003-06-05 21:26         ` Jason Rumney
2003-06-05 21:29         ` Juanma Barranquero
2003-06-05 21:52           ` Juanma Barranquero
2003-06-05 17:11 ` David Masterson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EDF322A.4050807@gnu.org \
    --to=jasonr@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).