emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Any posibility get non-dw2 libiconv2-dll and libintl-8.dll for gnutl


From: Eli Zaretskii
Subject: Re: Any posibility get non-dw2 libiconv2-dll and libintl-8.dll for gnutls/libxml2 emacs-compatible
Date: Tue, 21 May 2013 19:45:07 +0300

> Date: Tue, 21 May 2013 08:52:42 +0200
> From: Miguel Ruiz <address@hidden>
> 
> Based on
> 
> http://gcc.gnu.org/wiki/WindowsGCCImprovements

The small print near the end of that page says "last edited
2011-03-23".  So this is more than 2 years old now, and clearly
outdated, as the name of the libgcc_s_dw2-1.dll tells you (that "dw2"
part does stand for DWARF 2").

> I am not aware of the very internals of emacs, but, as a conservative
> behaviour, I build my w32 emacs production binaries with tdm-gcc-4.7.1-2
> (MinGW/sjlj) (http://tdm-gcc.tdragon.net/) and the crashes have completely
> disappeared.

I'm glad you solved your problem, but that cannot be the solution for
everyone else.  There are at least 3 different chains of GCC and
related tools ported to Windows; supporting only one of them, and not
the main one at that, cannot be good enough.  FWIW, that's the first
time I heard from anyone that they build Emacs with TDM; most use the
tools provided by mingw.org, and a few reported they use MinGW64
tools.  I have nothing against supporting TDM as well, but forcing
users to use only that is a non-starter.

> I follow the recent mails to the list and to gcc list (
> http://gcc.gnu.org/ml/gcc/2013-05/msg00180.html) about the problems in
> relation to libgcc_s_dw2-1.dll.

If you follow that, you already know that there are no firm
conclusions reached in that discussion yet.  Until the upstream GCC
maintainers say their definitive word on this, raising the issue here
is not very useful.

> At this moment
> 
> - libiconv-2.dll (in gnutls-3.0.9-w32-bin.zip)
> - libintl-8.dll  (in gnutls-3.0.9-w32-bin.zip)
> 
> - libiconv-2.dll (in libxml2-2.7.8-w32-bin.zip)
> 
> depend on libgcc_s_dw2-1.dll

That's not true, at least not with the GnuTLS and libxml2 distros from
my ports (on http://sourceforge.net/projects/ezwinports/files/).  I'm
quite sure that if you have those dependencies, you got libintl and
libiconv from some other place, not from those zip files.  Please
double check.  With the DLLs that I provided in the zip files, there's
no dependency on libgcc DLL, and no crashes at all.  (I will never
ever produce any port that depends on libgcc as a shared library, for
reasons that have nothing to do with the issue at hand here.)

> Is there any possibility that you provide the gnutls and libxml2 packages,
> and by extension, the named libraries, based on non-dw2 binaries, i.e.,
> built with a non-dw2 compiler like
> tdm-gcc-4.7.1-2, for example, as I do in a regular basis with emacs builds?

Sorry, but I will only use one toolchain, and currently that is the
toolchain distributed by mingw.org.  I cannot afford to have more than
one development environment, and I cannot invest more effort I already
do in porting optional libraries.  Moreover, since the problem with
libgcc_s_dw2-1.dll doesn't happen with my ports, I see no reason to
switch to TDM toolchain in the first place.

The problem which I'm trying to solve, and which prompted me to start
a discussion on the GCC list, is that I'd like this to work with any
GCC-based toolchain.  So switching to TDM, even if I wanted to, is not
the solution at all.

Eventually, with help from the GCC maintainers, we will crack this
problem, and find how to solve it.  I really suggest that people wait
for a little bit more; in the meantime, as already written in the
other thread here that raised the issue, using the DLLs from my ports
is a much easier work-around than switching to a completely different
development environment.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]