How about using static link instead of dynamic loaded dlls?

How about using static link instead of dynamic loaded dlls?

[Robin Hu]

Hi everyone:

   Current CVS NtEmacs snapshot loads libjpeg.dll in runtime. This
   causes a problem while I have some different versions of libjpeg.dll
   in %PATH%, because these versions are not binary compatible. And
   this problems can not be easily get rid of, because NtEmacs tries to
   load this dll via several names, such as libjpeg.dll jpeg-62.dll. We
   are in the hell of dlls now.

   I suggest to use static link instead of dynamic loaded dll files, or
   even more, include source files of these image libraries
   directly. This should be helpful to avoid dll hell, and may also
   helpful to workaround VC's bug in compiling w32fns.c(this bug will
   not re-produced while compiling w32fns.c with intel c compiler, so I
   believe this is a bug of VC itself).

   I've planned to do this, and I'd like to know if this is an
   acceptable idea before I really start doing this.

   robin.hu

Re: How about using static link instead of dynamic loaded dlls?

[Jason Rumney]

Robin Hu <huxw@knight.6test.edu.cn> writes:

> Hi everyone:
> 
>    Current CVS NtEmacs snapshot loads libjpeg.dll in runtime. This
>    causes a problem while I have some different versions of libjpeg.dll
>    in %PATH%

If you explain what problems you are having, we may be able to fix
them.  Linking the image libraries statically might work well for
people like yourself who compile Emacs yourself, but in the Windows
world you are the minority I am afraid, so linking dynamically is
more flexible for binary distribution.

It should be fairly straightforward to produce a patch that allows
either static or dynamic linking as a configure option, but I do not
have time to do this myself.

>    This should be helpful to avoid dll hell, and may also helpful to
>    workaround VC's bug in compiling w32fns.c(this bug will not
>    re-produced while compiling w32fns.c with intel c compiler, so I
>    believe this is a bug of VC itself).

Please explain. It is very rare to find a bug in a compiler these
days. More often it is a particular optimization that a compiler does
that show up a subtle bug in the code.

Re: How about using static link instead of dynamic loaded dlls?

[Mike Woolley]

Jason Rumney <jasonr@gnu.org> writes:

> so linking dynamically is more flexible for binary distribution.

Would it be possible to link in the libraries statically and *not*
require the DLL's at all at run-time?

That would provide the following advantages:

1/ No DLL hell.
2/ User doesn't have to go and download all the dependent libraries.

Of course, the resulting program is bigger, but does that matter
these days?

Cheers,
Mike

Re: How about using static link instead of dynamic loaded dlls?

[Jason Rumney]

Mike Woolley wrote:

> Would it be possible to link in the libraries statically and *not*
> require the DLL's at all at run-time?

> Of course, the resulting program is bigger, but does that matter
> these days?

It is more than that. Linking with third party libraries carries
legal obligations (many of which are self-imposed, as the licenses
of many of the libraries in question are more Public than Free).
I deliberately avoided making any binary distributed by FSF
dependant on those libraries to avoid the need to deal with these
legal issues, but I tried to do so in a way that does not cripple
the binary we distribute if the user choses to download those DLLs
separately from some other source.

I still think that this can be solved without any need for reverting
to static linking if you and any others having problems are prepared
to do some debugging and tell us exactly what is incompatible
between the different versions of DLL you have.

Re: How about using static link instead of dynamic loaded dlls?

[Benjamin Riefenstahl]

Hi Jason,


Jason Rumney <jasonr@gnu.org> writes:
> I deliberately avoided making any binary distributed by FSF
> dependant on those libraries to avoid the need to deal with these
> legal issues, but I tried to do so in a way that does not cripple
> the binary we distribute if the user choses to download those DLLs
> separately from some other source.

Would it be hard to have customizable variables for the DLL names?
Than Mike could just set them to the version that works by using a
complete path name.  Emacs could set the default by searching in $PATH
(as I understand the code internally does it now) and nil could mean,
that the user doesn't want the feature at all.


so long, benny

Re: How about using static link instead of dynamic loaded dlls?

[Robin Hu]

>>>>> "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. These image libraries(libtiff,
    libungif, libxpm, libjpeg, libpng) are also used by GTKWin32 and
    some other gnu softwares which are ported to mswin. Then:

    1/ These dlls are not binary compatible, so I must choose which dll
    file to use when start a program, which means I have to tune my
    %PATH% frequently just to make programs happy.

    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.

    These problems, I think, can not be eliminated without a
    modification to the dll mechanism.

    Jason> Please explain. It is very rare to find a bug in a compiler
    Jason> these days. More often it is a particular optimization that a
    Jason> compiler does that show up a subtle bug in the code.

    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. ;-( 

Re: How about using static link instead of dynamic loaded dlls?

[Jason Rumney]

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.

Re: How about using static link instead of dynamic loaded dlls?

[Juanma Barranquero]

On Thu, 05 Jun 2003 13:06:02 +0100, Robin Hu and Jason Rumney wrote:

> >     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. ;-( 

Don't worry: with MSVC 7.0 it happens in non-optimized builds too. I'm
going to test with 7.1 (aka Visual C++ .NET 2003)

> 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.

We've already discussed this: you can step till png_load, and then bang!
The crash happens inside the DLL, and the data being passed to the call
seems correct... :(

                                                           /L/e/k/t/u

Re: How about using static link instead of dynamic loaded dlls?

[Jason Rumney]

Juanma Barranquero <lektu@terra.es> writes:

> On Thu, 05 Jun 2003 13:06:02 +0100, Robin Hu and Jason Rumney wrote:
> 
> > >     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. ;-( 
> 
> Don't worry: with MSVC 7.0 it happens in non-optimized builds too. I'm
> going to test with 7.1 (aka Visual C++ .NET 2003)
> 
> > 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.
> 
> We've already discussed this: you can step till png_load, and then bang!
> The crash happens inside the DLL, and the data being passed to the call
> seems correct... :(

So get the debug symbols for the DLL. One of the tarballs at
probably gnuwin32.sourceforge.net has them, or you can try compiling
it yourself with mingw32 to see if you can duplicate the crash.

Re: How about using static link instead of dynamic loaded dlls?

[Juanma Barranquero]

On Thu, 05 Jun 2003 21:38:57 +0200, Juanma Barranquero <lektu@terra.es> wrote:

> I'm going to test with 7.1 (aka Visual C++ .NET 2003)

Yes, it crashes too.

I try to load a .PNG file and I get an access violation, and this trace:

 	0000001a()	
>	libpng.dll!png_warning()  + 0x3c	
 	libpng.dll!png_set_read_fn()  + 0x3e	


                                                           /L/e/k/t/u

Re: How about using static link instead of dynamic loaded dlls?

[Juanma Barranquero]

> I try to load a .PNG file and I get an access violation, and this trace:
> 
>  	0000001a()	
> >	libpng.dll!png_warning()  + 0x3c	
>  	libpng.dll!png_set_read_fn()  + 0x3e	

It seems like my_png_error and my_png_warning are being called with
wrong data. I can consistently cause my_png_error to be invoked with
arguments (NULL, NULL).

                                                           /L/e/k/t/u

Re: How about using static link instead of dynamic loaded dlls?

[David Masterson]

>>>>> Robin Hu writes:

>    Current CVS NtEmacs snapshot loads libjpeg.dll in runtime. This
>    causes a problem while I have some different versions of
>    libjpeg.dll in %PATH%, because these versions are not binary
>    compatible. And this problems can not be easily get rid of,
>    because NtEmacs tries to load this dll via several names, such as
>    libjpeg.dll jpeg-62.dll. We are in the hell of dlls now.

Can this be solved by simply wrapping NtEmacs in a BAT script that
adjusts the %PATH% before calling NtEmacs?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA