<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user">
    <title>gmane.comp.gnu.mingw.user</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42096"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42095"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42094"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42093"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42092"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42091"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42090"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42089"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42088"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42087"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42086"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42085"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42084"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42083"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42082"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42081"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42080"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42079"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42078"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42077"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42096">
    <title>Re: All symbols exported from shared library?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42096</link>
    <description>&lt;pre&gt;
 &amp;gt; On 19/05/13 21:36, Stephen Kelly wrote:
 &amp;gt;&amp;gt; Does mingw export everything by default?
 &amp;gt;
 &amp;gt; Yes, if you don't qualify *any* symbol with the dllexport attribute,
 &amp;gt; this is exactly what happens.
 &amp;gt;
 &amp;gt;&amp;gt; Can that be turned off?
 &amp;gt;
 &amp;gt; As soon as you so qualify just *one* symbol, then only those which are
 &amp;gt; qualified with the dllexport attribute will be exposed.
 &amp;gt;

Great, thanks!

Maybe a note could be added to the docs page with that information.

Thanks,

Steve.

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org

This list obs&lt;/pre&gt;</description>
    <dc:creator>Stephen Kelly</dc:creator>
    <dc:date>2013-05-20T07:33:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42095">
    <title>Re: Fixing mingw support in Python's distutils</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42095</link>
    <description>&lt;pre&gt;2013/5/19 Oscar Benjamin &amp;lt;oscar.j.benjamin-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt;



2) I think it has been removed in GCC 4.6.
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/min&lt;/pre&gt;</description>
    <dc:creator>Renato Silva</dc:creator>
    <dc:date>2013-05-20T04:19:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42094">
    <title>Re: Fixing mingw support in Python's distutils</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42094</link>
    <description>&lt;pre&gt;
Thanks for responding.

There are many issues with mingw and Python but the key one that I am
trying to resolve and the only one that I have directly experienced is
the '-mno-cygwin' issue. I see no reference to it there until 6 months
ago:
http://bugs.python.org/issue3871#msg178631

In general I think that in Python there will be a move away from using
distutils that will in the long term provide a better fix for most of
these problems. Until that happens we're stuck using distutils which
has a lot of inertia around applying fixes (probably the reason those
patches were not accepted). However I would like to try and push for a
fix for this particular problem as it thwarts *any* attempt to build
using mingw without (monkey-)patching the Python standard library.


Thanks,
Oscar

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficient&lt;/pre&gt;</description>
    <dc:creator>Oscar Benjamin</dc:creator>
    <dc:date>2013-05-19T23:37:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42093">
    <title>Re: Fixing mingw support in Python's distutils</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42093</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20.05.2013 02:37, Oscar Benjamin wrote:
This is MUCH older than that, see [1].

[1] http://bugs.python.org/issue3871

- -- 
O&amp;lt; ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJRmVwmAAoJEOs4Jb6SI2CwPhoIAOLGcnUE4DJZJUsNNYPh9raq
2tEIa9ezdQh91ltoq0prR8pYHJCNgKKW6hlyOdMtDB/p8AWTTrucrEgOcEAe2Vac
UMp3hYCBg6w1TpVgSBjcCkhsmMrYE6m9IpKTrpy7mWfYtkNeD9F/Nfw/cDmhLOuZ
FUDeqkqTJ4Vb7v8JRtM4h6HrXSeDesEznIbQmmyT4o4toPJakVy8di06MD9sMzrv
EniIZ/eWGQNCkCpMhu3BiuVosSQCiTnK/xHC4KpTwG++RfxMcJcjeVbcmA0AwAoz
CoAnpk/+y9RDfsHJCmLycU6UbfTNyKboKPgUPvsb/W90Fw6kSfik/8SnLwbAWbQ=
=3TnK
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a&lt;/pre&gt;</description>
    <dc:creator>LRN</dc:creator>
    <dc:date>2013-05-19T23:11:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42092">
    <title>Fixing mingw support in Python's distutils</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42092</link>
    <description>&lt;pre&gt;Hi all,

I haven't posted to this list before and I'm not sure if it's the
right place to ask this question. If not then please let me know. I'm
looking for some help in order to resolve a long-standing issue in
using mingw with Python.

Building extension modules for Python with recent versions of mingw
has been broken for some time now. I first encountered the problem
about two years ago and found this SO question
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o
Shortly after that an issue was opened on the Python tracker:
http://bugs.python.org/issue12641
The issue has languished on the tracker for two years since then. As
someone who builds Python extension modules with mingw I have been
manually patching distutils in my own Python installations for some
time now. While this is acceptable for me I'd really like to get this
fixed so that mingw and Python can work together out of the box.

The issue is (as I understand it) caused by t&lt;/pre&gt;</description>
    <dc:creator>Oscar Benjamin</dc:creator>
    <dc:date>2013-05-19T22:37:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42091">
    <title>Re: All symbols exported from shared library?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42091</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20.05.2013 00:40, Pau Garcia i Quiles wrote:
GTK+ also recently switched to explicit symbol visibility (check git
master HEAD). That allowed GTK to completely remove .def files from the
source tree.

- -- 
O&amp;lt; ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJRmVKYAAoJEOs4Jb6SI2CwbfkIALC4+xMBDa7Q/Cx4H+mjaW9E
yR4BSHFrTRNSMQzvQqdWrrmS4ZnMg9wvGnJXSxShrtN34v8i8ZKqtmKvtArQpWTv
lCzXU5xH4sPzULYvMgMGklzwweeFZc7otp+IV0pqtLKGRIDkQDT4tn+fXOqFqHDb
Je5BnSI+306DGYrHpjrSYyNTMvu22UypVDBeUGoPUMmj6svqOC5IIl84WxATU5+u
sPienzYyrtxrWSPyTwiMH1nqT1TBRYa6EbuJCgFtDRDV/wgTuSLyI1AnzBwW03IY
omxjuOe5avAuyYohDXrNFwKpPfITP6ktXhkRX5cohcRozn0OkRbfQ5QZ5eLLdUo=
=d+dI
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily a&lt;/pre&gt;</description>
    <dc:creator>LRN</dc:creator>
    <dc:date>2013-05-19T22:30:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42090">
    <title>Re: All symbols exported from shared library?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42090</link>
    <description>&lt;pre&gt;Hi,

Check this:

http://gcc.gnu.org/wiki/Visibility

The KDE export headers already implement such logic, using one of them as
the reference would be a good idea :-)


On Sun, May 19, 2013 at 10:36 PM, Stephen Kelly &amp;lt;steveire-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:




&lt;/pre&gt;</description>
    <dc:creator>Pau Garcia i Quiles</dc:creator>
    <dc:date>2013-05-19T20:40:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42089">
    <title>Re: All symbols exported from shared library?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42089</link>
    <description>&lt;pre&gt;
Yes, if you don't qualify *any* symbol with the dllexport attribute, 
this is exactly what happens.


As soon as you so qualify just *one* symbol, then only those which are 
qualified with the dllexport attribute will be exposed.

&lt;/pre&gt;</description>
    <dc:creator>Keith Marshall</dc:creator>
    <dc:date>2013-05-19T20:51:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42088">
    <title>All symbols exported from shared library?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42088</link>
    <description>&lt;pre&gt;Hi there,

After reading

  http://www.mingw.org/wiki/sampleDLL

I tried to create a dll and use it, cross compiling on ubuntu. I simplified
the example code somewhat.


$ cat lib.h

#ifdef BUILDING_EXAMPLE_DLL
#define EXAMPLE_DLL __declspec(dllexport)
#else
#define EXAMPLE_DLL __declspec(dllimport)
#endif

int myveryeasymethod(void);

$ cat lib.c

#include "lib.h"

int myveryeasymethod(void)
{ return 42; }

$ cat main.c

#include &amp;lt;stdio.h&amp;gt;

#include "lib.h"

int main()
{
   printf("HELLO %d\n", myveryeasymethod());
   return 0;
}

$ i686-w64-mingw32-gcc-4.6 -c lib.c

$ i686-w64-mingw32-gcc-4.6  -shared -o example_dll.dll lib.o -Wl,--out-
implib,libexample_dll.a

$ i686-w64-mingw32-gcc-4.6  -c main.c

$ i686-w64-mingw32-gcc-4.6  -o example.exe main.o example_dll.dll

$ wine example.exe
HELLO 42


Note that I did not actually dllexport the symbol from the library, so I
expect linking errors when building the executable, and I expect it not to
run.

Does mingw export everything by default? Can that be turned o&lt;/pre&gt;</description>
    <dc:creator>Stephen Kelly</dc:creator>
    <dc:date>2013-05-19T20:36:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42087">
    <title>Re: What version of MSVCRT.DLL do you have?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42087</link>
    <description>&lt;pre&gt;
Thanks for the information.  That is what I thought it would be but
wanted to be sure.

&lt;/pre&gt;</description>
    <dc:creator>Earnie Boyd</dc:creator>
    <dc:date>2013-05-19T20:01:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42086">
    <title>Re: What version of MSVCRT.DLL do you have?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42086</link>
    <description>&lt;pre&gt;
$MSVCRT=`echo $WINDIR | sed -e 's.\\\\./.g'`/system32/msvcrt.dll
$MAJ=`objdump -x $MSVCRT | grep MajorLinkerVersion | awk '{print ($2 * 100)}'`
$MIN=`objdump -x $MSVCRT | grep MinorLinkerVersion | awk '{print $2}'`
$echo $MAJ' '$MIN | awk '{print $1 + $2}'
800
$uname -a
MINGW32_NT-6.0 TWINKY 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys
$

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the l&lt;/pre&gt;</description>
    <dc:creator>Lee</dc:creator>
    <dc:date>2013-05-19T16:18:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42085">
    <title>Re: What version of MSVCRT.DLL do you have?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42085</link>
    <description>&lt;pre&gt;
Actually I need someone to give me the value for Vista.

~~~~~
#!/bin/sh

MSVCRT=`echo $WINDIR | sed -e 's.\\\\./.g'`/system32/msvcrt.dll
MAJ=`objdump -x $MSVCRT | grep MajorLinkerVersion | awk '{print ($2 * 100)}'`
MIN=`objdump -x $MSVCRT | grep MinorLinkerVersion | awk '{print $2}'`
echo $MAJ' '$MIN | awk '{print $1 + $2}'
~~~~~

&lt;/pre&gt;</description>
    <dc:creator>Earnie Boyd</dc:creator>
    <dc:date>2013-05-19T15:50:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42084">
    <title>Re: Guess return value</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42084</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19.05.2013 19:23, Eli Zaretskii wrote:
This ensures that libgcc is the last library to be unloaded. This puts
more weight behind the idea of unloading dlls in a correct order. That
said, i still don't understand what is happening, and why doing
particular things helps.

Maybe. I don't know what its on-load and on-unload handlers do.
Apparently, they do something - otherwise on-unload handler would not
have been crashing on us.

I would expect that bad things may happen.

If you loaded libgcc_s_dw2-1.dll, and then load, say, libz-1.dll, which
also depends on libgcc_s_dw2-1.dll, then that dll won't be loaded twice,
only its reference count will increase. Same with unloading.

No, if it's always libgcc_s_dw2. If some dlls depend on, say,
libgcc_s_sjlj, then i have no idea what will happen, but i would expect
it to be bad. Ask gcc devs.

libgcc may be a non-optional dependency for some code. It's not evil.
Just dw2 exception handling in libgcc is a bit buggy.

- &lt;/pre&gt;</description>
    <dc:creator>LRN</dc:creator>
    <dc:date>2013-05-19T15:46:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42083">
    <title>Re: Guess return value</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42083</link>
    <description>&lt;pre&gt;
I found a way to avoid the crash, but since I don't really understand
the reasons for the crash, I cannot be sure that the workaround is
solid.

It goes like this:

 . at program startup, load libgcc_s_dw2-1.dll via LoadLibrary; store
   the handle to it somewhere

 . let Emacs work as usual, loading any DLLs it needs and recording
   them

 . when Emacs is about to shut down, unload all the DLLs with explicit
   FreeLibrary calls, and finally unload libgcc_s_dw2-1.dll

This makes sure libgcc_s_dw2-1.dll remains loaded even when the DLLs
that depend on it unload, because the main module holds a handle on
it.

Question: is there any danger in loading libgcc_s_dw2-1.dll?  What if
the program already has a different libgcc DLL, or will load it ad
result of loading some other DLL? won't that cause run-time trouble?

In any case, this is so kludgey that I'm not sure I will put the
necessary code into Emacs.  It might be easier to tell users to
install DLLs that don't depend on that evil thingy.

----------------&lt;/pre&gt;</description>
    <dc:creator>Eli Zaretskii</dc:creator>
    <dc:date>2013-05-19T15:23:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42082">
    <title>Re: Guess return value</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42082</link>
    <description>&lt;pre&gt;
Thanks.  This means we don't really know whether unloading the DLLs
with FreeLibrary is at all a solution, since the only two confirmed
solutions carefully sidestep the issue altogether...

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or un&lt;/pre&gt;</description>
    <dc:creator>Eli Zaretskii</dc:creator>
    <dc:date>2013-05-18T19:05:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42081">
    <title>Re: Guess return value</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42081</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18.05.2013 22:18, Eli Zaretskii wrote:

No, sorry. You'll have to ask gcc devs.


I switched to a toolchain built with sjlj.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJRl8coAAoJEOs4Jb6SI2Cw6L8IAIjkBwMnfTKIauLLIoRzG1G0
1lVwOEKQz6cwwmEqzy0H1IIHfnFTNmk4OA9J6s5c1AZa4oc84pNZZ9JfoDSKKRXA
kjtXb2GDeuQpH1iaikClqFkJ6/4Rr0VEBMplUnlnVD6V7MgiNn2NlRX9/p0HIfTE
tTREU0/e+q2bbtdPdO5tyOcGdEGLCnpQ9R6u+I+hvW4FZkrarbWuoEPUvfunNgpF
ruZv/eSNgFpezOzUBvy/5RcVsOZLujh+2fVc7hnKH3i61F3DmN+pEzXwMlqLhB1B
Os/AT83oennKtiicieNQTdAYBovklLm69KRim3yY7ZI0p4E47SSQxwOxYwm4F24=
=/4mv
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a f&lt;/pre&gt;</description>
    <dc:creator>LRN</dc:creator>
    <dc:date>2013-05-18T18:23:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42080">
    <title>Re: Guess return value</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42080</link>
    <description>&lt;pre&gt;
It's not exactly easy, but I could try, if there are no other ideas.

Do you happen to know more details than what you already wrote about
what exactly is that __deregister_frame_info call trying to do?  I
guess it's somehow related to support of exceptions across DLLs, and
that is why it is being called whenever any DLL unloads.  But what are
the details?  Those details might give a hint to why it crashes and
how to avoid that.

Also, in the case you described in the original thread, the one that
led you to this discovery, did you actually succeed in preventing the
crash by manually unloading some library, or did you just switch to a
libintl that didn't depend on libgcc?

Thanks.

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unif&lt;/pre&gt;</description>
    <dc:creator>Eli Zaretskii</dc:creator>
    <dc:date>2013-05-18T18:18:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42079">
    <title>Re: What version of MSVCRT.DLL do you have?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42079</link>
    <description>&lt;pre&gt;
I think 100 is enough.  We never saw the minor version that is more
than 10.


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request-5NWGOfr&lt;/pre&gt;</description>
    <dc:creator>Eli Zaretskii</dc:creator>
    <dc:date>2013-05-18T18:07:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42078">
    <title>Re: Guess return value</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42078</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18.05.2013 21:01, Eli Zaretskii wrote:

Yeah, i've read the thread briefly. Patch has lots of emacsisms and
lispisms, so i just glossed over it.


Nope. The whole thing is highly esoteric.
Have you tried unloading the libraries in correct order (that is, in
reverse to the order they were loaded in)? Other than that i really have
no clue.

It might help if you get a debug build of libgcc to actually see what's
happening. I didn't do that, so i don't know, but maybe it's possible to
fix.

- -- 
O&amp;lt; ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJRl8AvAAoJEOs4Jb6SI2Cwse0IAJEncZI+tUQyFwLxZVm/otMN
yc0ANyk5FiVE1ha9dUk6Fik3x5RAMSyOcBT7zi9M0vfZwkEs9EvORML7/s9CQvjm
JiuDRd71hjSdUBJhem7AOsav3hXUH53dTDhkUobwsFKZ8w4XbpQWhpsGRPw4fDij
5PgR/xMNRu5dwN/5zyN7xPveOQ2UVMotVF+tFzxgMSwfXpDv2WDiU1KGOLD0VLT8
58dO3KGJcvIm8/sTaXblg48drkioaDDBVM/5jbWZXbIZz/aJdWSEJA05U7DtnwAL
uhuv+VG4CVCwtEIP9YmAJHLLsenjm&lt;/pre&gt;</description>
    <dc:creator>LRN</dc:creator>
    <dc:date>2013-05-18T17:53:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42077">
    <title>Re: What version of MSVCRT.DLL do you have?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42077</link>
    <description>&lt;pre&gt;Thanks for everyone's input.  I think I have enough information.

&lt;/pre&gt;</description>
    <dc:creator>Earnie Boyd</dc:creator>
    <dc:date>2013-05-18T17:49:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42076">
    <title>Re: What version of MSVCRT.DLL do you have?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42076</link>
    <description>&lt;pre&gt;
The one I know off hand are the stat structures and depending on the
MSVCRT whether or not certain data types such as 32bit time_t.


Thanks for that bit of information.  It sounds as if 710 would be a
safe default.  Those with less can define MSVCRT_VERSION before the
configure script executes.


I just checked that and they are the same.  Do you think times 100 is
enough for the major version or should I go for 1000?

&lt;/pre&gt;</description>
    <dc:creator>Earnie Boyd</dc:creator>
    <dc:date>2013-05-18T17:48:37</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.gnu.mingw.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gnu.mingw.user</link>
  </textinput>
</rdf:RDF>
