libstdc++-6.dll seg fault.

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

libstdc++-6.dll seg fault.

Sean Sill
Hello,

  I'm trying to build Open Lighting Architecture for mingw on Windows 7 64bit.

It depends on google protobufs, and I had a problem similar to this:

So I removed the libstdc++.dll.a from /mingw/bin/ and it solved it.

My main application builds fine but when I run make check most if not all tests fail with the same pop up. "Application failed to start 00xc0000005" When I look with gdb I get this backtrace

http://pastebin.com/JWKM17dP

and here's a look at make check output


None of the solutions offered in the stack overflow fix the problem. It seems to be run time. I can check the path and /mingw/bin is the first place it should look for libstdc++.dll but it seems to come from c:\windows\SysWOW64 first

Any help would be greatly appreciated.

Thanks,
Sean Sill
Electronic Systems Consultant/Contractor
Electrical and Computer Engineering Alumni from
Missouri University of Science and Technology(Missouri S&T)

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Eli Zaretskii
> Date: Sun, 7 Dec 2014 13:23:54 -0500
> From: Sean Sill <[hidden email]>
>
> I'm trying to build Open Lighting Architecture for mingw on Windows 7 64bit.
>
> It depends on google protobufs, and I had a problem similar to this:
> http://stackoverflow.com/questions/6404636/libstdc-6-dll-not-found
>
> So I removed the libstdc++.dll.a from /mingw/bin/ and it solved it.

The right solution would be to use the -static-libstdc++ switch to
GCC.

> My main application builds fine but when I run make check most if not all tests
> fail with the same pop up. "Application failed to start 00xc0000005" When I
> look with gdb I get this backtrace
>
> http://pastebin.com/JWKM17dP
>
> and here's a look at make check output
>
> http://pastebin.com/Tq138BLV

Which parts of your application depend on libstdc++ DLL?  Run the
dependency checker to find out, or use 'objdump -x | fgrep "DLL Name:"'.

> None of the solutions offered in the stack overflow fix the problem. It seems
> to be run time. I can check the path and /mingw/bin is the first place it
> should look for libstdc++.dll but it seems to come from c:\windows\SysWOW64
> first

Why is there a libstdc++-6.dll in your SysWOW64?  Which package
installed it there, and why?  You should never have MinGW-related DLLs
in system directories.  Never.

Anyway, you seem to have a bit of a DLL hell on your hands, and you
need to sort it out.  Probably several incompatible versions of
libstdc++-6.dll or some such.  Check their dates and sizes to see
which are newer.

As to why the application loads the DLL from c:\windows\SysWOW64,
although the MinGW's bin directory comes first on Path: it's most
probably because the DLL that depends on it also lives in SysWOW64.
Windows looks in the same directory where a dependent module came from
before searching the Path.  See the description here for the details:

  http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Sean Sill
I'm trying the steps you sent. I swear I already tried it with -static-libstdc++ but I'll carefully make sure it gets added correctly.

As for the syswow libstdc++-6.dll, I work in many environments, and a few of them have installers and are mingw based. They may have installed it somehow.

I may just blow away my system and start over.

On Sun, Dec 7, 2014 at 3:08 PM, Eli Zaretskii <[hidden email]> wrote:
> Date: Sun, 7 Dec 2014 13:23:54 -0500
> From: Sean Sill <[hidden email]>
>
> I'm trying to build Open Lighting Architecture for mingw on Windows 7 64bit.
>
> It depends on google protobufs, and I had a problem similar to this:
> http://stackoverflow.com/questions/6404636/libstdc-6-dll-not-found
>
> So I removed the libstdc++.dll.a from /mingw/bin/ and it solved it.

The right solution would be to use the -static-libstdc++ switch to
GCC.

> My main application builds fine but when I run make check most if not all tests
> fail with the same pop up. "Application failed to start 00xc0000005" When I
> look with gdb I get this backtrace
>
> http://pastebin.com/JWKM17dP
>
> and here's a look at make check output
>
> http://pastebin.com/Tq138BLV

Which parts of your application depend on libstdc++ DLL?  Run the
dependency checker to find out, or use 'objdump -x | fgrep "DLL Name:"'.

> None of the solutions offered in the stack overflow fix the problem. It seems
> to be run time. I can check the path and /mingw/bin is the first place it
> should look for libstdc++.dll but it seems to come from c:\windows\SysWOW64
> first

Why is there a libstdc++-6.dll in your SysWOW64?  Which package
installed it there, and why?  You should never have MinGW-related DLLs
in system directories.  Never.

Anyway, you seem to have a bit of a DLL hell on your hands, and you
need to sort it out.  Probably several incompatible versions of
libstdc++-6.dll or some such.  Check their dates and sizes to see
which are newer.

As to why the application loads the DLL from c:\windows\SysWOW64,
although the MinGW's bin directory comes first on Path: it's most
probably because the DLL that depends on it also lives in SysWOW64.
Windows looks in the same directory where a dependent module came from
before searching the Path.  See the description here for the details:

  http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe



--
Sean Sill
Electronic Systems Consultant/Contractor
Electrical and Computer Engineering Alumni from
Missouri University of Science and Technology(Missouri S&T)

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Sean Sill
I did try adding -static-libstdc++ and -statc-libgcc but the error was still happening. 

So I've renam the offending libstdc++-6.dll in SysWOW64. That seems to have fixed it. I'll most likely discover later what needed the .dll.

I'll mark this one [SOLVED]

Thanks so much Eli! I think I just needed a reality check.

On Sun, Dec 7, 2014 at 6:19 PM, Sean Sill <[hidden email]> wrote:
I'm trying the steps you sent. I swear I already tried it with -static-libstdc++ but I'll carefully make sure it gets added correctly.

As for the syswow libstdc++-6.dll, I work in many environments, and a few of them have installers and are mingw based. They may have installed it somehow.

I may just blow away my system and start over.

On Sun, Dec 7, 2014 at 3:08 PM, Eli Zaretskii <[hidden email]> wrote:
> Date: Sun, 7 Dec 2014 13:23:54 -0500
> From: Sean Sill <[hidden email]>
>
> I'm trying to build Open Lighting Architecture for mingw on Windows 7 64bit.
>
> It depends on google protobufs, and I had a problem similar to this:
> http://stackoverflow.com/questions/6404636/libstdc-6-dll-not-found
>
> So I removed the libstdc++.dll.a from /mingw/bin/ and it solved it.

The right solution would be to use the -static-libstdc++ switch to
GCC.

> My main application builds fine but when I run make check most if not all tests
> fail with the same pop up. "Application failed to start 00xc0000005" When I
> look with gdb I get this backtrace
>
> http://pastebin.com/JWKM17dP
>
> and here's a look at make check output
>
> http://pastebin.com/Tq138BLV

Which parts of your application depend on libstdc++ DLL?  Run the
dependency checker to find out, or use 'objdump -x | fgrep "DLL Name:"'.

> None of the solutions offered in the stack overflow fix the problem. It seems
> to be run time. I can check the path and /mingw/bin is the first place it
> should look for libstdc++.dll but it seems to come from c:\windows\SysWOW64
> first

Why is there a libstdc++-6.dll in your SysWOW64?  Which package
installed it there, and why?  You should never have MinGW-related DLLs
in system directories.  Never.

Anyway, you seem to have a bit of a DLL hell on your hands, and you
need to sort it out.  Probably several incompatible versions of
libstdc++-6.dll or some such.  Check their dates and sizes to see
which are newer.

As to why the application loads the DLL from c:\windows\SysWOW64,
although the MinGW's bin directory comes first on Path: it's most
probably because the DLL that depends on it also lives in SysWOW64.
Windows looks in the same directory where a dependent module came from
before searching the Path.  See the description here for the details:

  http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe



--
Sean Sill
Electronic Systems Consultant/Contractor
Electrical and Computer Engineering Alumni from
Missouri University of Science and Technology(Missouri S&T)



--
Sean Sill
Electronic Systems Consultant/Contractor
Electrical and Computer Engineering Alumni from
Missouri University of Science and Technology(Missouri S&T)

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Yongwei Wu
In reply to this post by Eli Zaretskii
On 8 December 2014 at 04:08, Eli Zaretskii <[hidden email]> wrote:

>
> > Date: Sun, 7 Dec 2014 13:23:54 -0500
> > From: Sean Sill <[hidden email]>
> >
> > I'm trying to build Open Lighting Architecture for mingw on Windows 7 64bit.
> >
> > It depends on google protobufs, and I had a problem similar to this:
> > http://stackoverflow.com/questions/6404636/libstdc-6-dll-not-found
> >
> > So I removed the libstdc++.dll.a from /mingw/bin/ and it solved it.
>
> The right solution would be to use the -static-libstdc++ switch to
> GCC.

I think the name libstdc++.dll is also a little problematic, as it
hides the ABI and runtime differences. The Cygwin DLL name
cygstdc++-6.dll is better, but even mgwstdc++.dll will not be good
enough, as there is the SJLJ/DW2 difference and winthread/pthread
difference on Windows. However, I would think naming MinGW DLLs mgw* a
good start, as the official MinGW distribution is consistent on the
variants I mentioned. People using MinGW variants should give their
DLLs a different prefix.

My 2 cents.

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Eli Zaretskii
> Date: Tue, 9 Dec 2014 17:30:10 +0800
> From: Yongwei Wu <[hidden email]>
>
> On 8 December 2014 at 04:08, Eli Zaretskii <[hidden email]> wrote:
> >
> > > Date: Sun, 7 Dec 2014 13:23:54 -0500
> > > From: Sean Sill <[hidden email]>
> > >
> > > I'm trying to build Open Lighting Architecture for mingw on Windows 7 64bit.
> > >
> > > It depends on google protobufs, and I had a problem similar to this:
> > > http://stackoverflow.com/questions/6404636/libstdc-6-dll-not-found
> > >
> > > So I removed the libstdc++.dll.a from /mingw/bin/ and it solved it.
> >
> > The right solution would be to use the -static-libstdc++ switch to
> > GCC.
>
> I think the name libstdc++.dll is also a little problematic, as it
> hides the ABI and runtime differences. The Cygwin DLL name
> cygstdc++-6.dll is better

You are confusing the name of the DLL with the name of its import
library.  The former is called libstdc++-6.dll in MinGW; the latter is
libstdc++.dll.a, and has no version in its name.  There's no reason to
have a version in the import library's name, because you are supposed
to develop against a single version at a time.  The DLLs, OTOH, can
and should have versions, because different programs can depend on
different versions.

So I think everything is OK in that department on the OP's machine,
as well as in MinGW.

> but even mgwstdc++.dll will not be good enough, as there is the
> SJLJ/DW2 difference and winthread/pthread difference on
> Windows. However, I would think naming MinGW DLLs mgw* a good start,
> as the official MinGW distribution is consistent on the variants I
> mentioned. People using MinGW variants should give their DLLs a
> different prefix.

Whoever mixes MinGW and MinGW64 programs on his/her machine is playing
with fire.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Yongwei Wu
(Wrongly replied to only Eli previously.)

On 10 December 2014 at 00:32, Eli Zaretskii <[hidden email]> wrote:

>> Date: Tue, 9 Dec 2014 17:30:10 +0800
>> From: Yongwei Wu <[hidden email]>
>>
>> I think the name libstdc++.dll is also a little problematic, as it
>> hides the ABI and runtime differences. The Cygwin DLL name
>> cygstdc++-6.dll is better
>
> You are confusing the name of the DLL with the name of its import
> library.  The former is called libstdc++-6.dll in MinGW; the latter is
> libstdc++.dll.a, and has no version in its name.  There's no reason to
> have a version in the import library's name, because you are supposed
> to develop against a single version at a time.  The DLLs, OTOH, can
> and should have versions, because different programs can depend on
> different versions.

No, I was not. I cared only about the DLLs, but not the import
libraries (your misunderstanding might be caused by my typo: I missed
"-6" once). A stray import library does not cause harm, unless one put
into the MinGW directory. I do not suppose people would be doing that.

>> but even mgwstdc++.dll will not be good enough, as there is the
>> SJLJ/DW2 difference and winthread/pthread difference on
>> Windows. However, I would think naming MinGW DLLs mgw* a good start,
>> as the official MinGW distribution is consistent on the variants I
>> mentioned. People using MinGW variants should give their DLLs a
>> different prefix.
>
> Whoever mixes MinGW and MinGW64 programs on his/her machine is playing
> with fire.

Even if I did not install them both, some programs might come with a
libstdc++-6.dll from the MinGW version he used. The disaster would
then follow either because the installation path is added to the
system PATH or user PATH, or because libstdc++-6.dll is copied to a
system directory (as the OP encountered).

I do have two conflicting libstdc++-6.dll on our my system (though
only one in the system path). It would be better if we avoided it
proactively.

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Emanuel Falkenauer
Hello,

Apologies for breaking in, but I take a slight offence at the following
statement:

> Whoever mixes MinGW and MinGW64 programs on his/her machine is playing with fire.

Most of us here are programmers and I reckon that many (if not most) of
us write programs for third parties, like us. Due to the extremely
various environments of our clients, we simply MUST "mix MinGW and
MinGW64 programs on [our] machine[s]": we have no choice!
To illustrate, one of our huge clients simply won't upgrade from Java
6.24 32 bits in foreseeable future (for "security reasons", I guess),
while others are on Java 7 64 bits since ages - any DLL with JNA we
produce MUST therefore be available in both bitnesses.

Now "playing with fire" it was indeed, to set up everything to be able
to make (and run) both versions without problems... but it should not
have been.

On 11-Dec-14 04:56, Yongwei Wu wrote:

> (Wrongly replied to only Eli previously.)
>
> On 10 December 2014 at 00:32, Eli Zaretskii <[hidden email]> wrote:
>>> Date: Tue, 9 Dec 2014 17:30:10 +0800
>>> From: Yongwei Wu <[hidden email]>
>>>
>>> I think the name libstdc++.dll is also a little problematic, as it
>>> hides the ABI and runtime differences. The Cygwin DLL name
>>> cygstdc++-6.dll is better
>> You are confusing the name of the DLL with the name of its import
>> library.  The former is called libstdc++-6.dll in MinGW; the latter is
>> libstdc++.dll.a, and has no version in its name.  There's no reason to
>> have a version in the import library's name, because you are supposed
>> to develop against a single version at a time.  The DLLs, OTOH, can
>> and should have versions, because different programs can depend on
>> different versions.
> No, I was not. I cared only about the DLLs, but not the import
> libraries (your misunderstanding might be caused by my typo: I missed
> "-6" once). A stray import library does not cause harm, unless one put
> into the MinGW directory. I do not suppose people would be doing that.
>
>>> but even mgwstdc++.dll will not be good enough, as there is the
>>> SJLJ/DW2 difference and winthread/pthread difference on
>>> Windows. However, I would think naming MinGW DLLs mgw* a good start,
>>> as the official MinGW distribution is consistent on the variants I
>>> mentioned. People using MinGW variants should give their DLLs a
>>> different prefix.
>> Whoever mixes MinGW and MinGW64 programs on his/her machine is playing
>> with fire.
> Even if I did not install them both, some programs might come with a
> libstdc++-6.dll from the MinGW version he used. The disaster would
> then follow either because the installation path is added to the
> system PATH or user PATH, or because libstdc++-6.dll is copied to a
> system directory (as the OP encountered).
>
> I do have two conflicting libstdc++-6.dll on our my system (though
> only one in the system path). It would be better if we avoided it
> proactively.
>
> --
> Wu Yongwei
> URL: http://wyw.dcweb.cn/
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> 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:[hidden email]?subject=unsubscribe


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Eli Zaretskii
> Date: Fri, 12 Dec 2014 03:15:39 +0100
> From: Emanuel Falkenauer <[hidden email]>
>
> Apologies for breaking in, but I take a slight offence at the following
> statement:
>
> > Whoever mixes MinGW and MinGW64 programs on his/her machine is playing with fire.

If I sounded like I thought it was illegal or worthy of capital
punishment, I hereby apologize.  It was a colorful way of saying
"kids, don't try that at home", nothing more.

> Most of us here are programmers and I reckon that many (if not most) of
> us write programs for third parties, like us. Due to the extremely
> various environments of our clients, we simply MUST "mix MinGW and
> MinGW64 programs on [our] machine[s]": we have no choice!
> To illustrate, one of our huge clients simply won't upgrade from Java
> 6.24 32 bits in foreseeable future (for "security reasons", I guess),
> while others are on Java 7 64 bits since ages - any DLL with JNA we
> produce MUST therefore be available in both bitnesses.
>
> Now "playing with fire" it was indeed, to set up everything to be able
> to make (and run) both versions without problems...

That's exactly what I meant.  You've got to do what you've got to do,
but you should also know what kind of trouble you are getting yourself
in.

> but it should not have been.

I don't think there's a hope of this ever becoming easier.  You cannot
easily mix incompatible runtimes in the same session, on any machine
and OS.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Yongwei Wu
On 12 December 2014 at 16:11, Eli Zaretskii <[hidden email]> wrote:

>> Now "playing with fire" it was indeed, to set up everything to be able
>> to make (and run) both versions without problems...
>
> That's exactly what I meant.  You've got to do what you've got to do,
> but you should also know what kind of trouble you are getting yourself
> in.
>
>> but it should not have been.
>
> I don't think there's a hope of this ever becoming easier.  You cannot
> easily mix incompatible runtimes in the same session, on any machine
> and OS.

Some runtimes are not supposed to be mixed in the same process, but
they should be able to exist safely on the same machine. We only need
to name them better. That is the intention of the library prefix.

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Emanuel Falkenauer
I do concur with Wu (my sincere apologies if you prefer Yongwei!):

On 13-Dec-14 03:38, Yongwei Wu wrote:
> On 12 December 2014 at 16:11, Eli Zaretskii <[hidden email]> wrote:
>>> Now "playing with fire" it was indeed, to set up everything to be able
>>> to make (and run) both versions without problems...
>> That's exactly what I meant.  You've got to do what you've got to do,
>> but you should also know what kind of trouble you are getting yourself
>> in.

Well the thing is that it was "playing with fire" to have the two
bitnesses of *MinGW* cohabitate... but all flavours of OUR dlls (i.e.
our output) are named differently - precisely in order to avoid loading
the wrong one. ;-)

>>
>>> but it should not have been.
>> I don't think there's a hope of this ever becoming easier.  You cannot
>> easily mix incompatible runtimes in the same session, on any machine
>> and OS.
> Some runtimes are not supposed to be mixed in the same process, but
> they should be able to exist safely on the same machine. We only need
> to name them better. That is the intention of the library prefix.
>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Eli Zaretskii
In reply to this post by Yongwei Wu
> Date: Sat, 13 Dec 2014 10:38:23 +0800
> From: Yongwei Wu <[hidden email]>
>
> > I don't think there's a hope of this ever becoming easier.  You cannot
> > easily mix incompatible runtimes in the same session, on any machine
> > and OS.
>
> Some runtimes are not supposed to be mixed in the same process, but
> they should be able to exist safely on the same machine. We only need
> to name them better. That is the intention of the library prefix.

I don't think this is practically achievable.  There are several
GNU-based Windows toolchains with subtle changes, each one supported
by a group of volunteers.  You expect from those people too high level
of coordination.

E.g., take the simplest thing: producing a port of some Free Software
library -- do you expect me to hack its Makefile's just to make sure
the DLLs have some predefined prefix?  That's a nuisance on top of an
already uphill battle I need to fight just to have that library built
and get past all the tests.  And who and how would decide which prefix
to use for each project?

Impractical.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Eli Zaretskii
In reply to this post by Emanuel Falkenauer
> Date: Sat, 13 Dec 2014 04:15:28 +0100
> From: Emanuel Falkenauer <[hidden email]>
>
> I do concur with Wu (my sincere apologies if you prefer Yongwei!):
>
> On 13-Dec-14 03:38, Yongwei Wu wrote:
> > On 12 December 2014 at 16:11, Eli Zaretskii <[hidden email]> wrote:
> >>> Now "playing with fire" it was indeed, to set up everything to be able
> >>> to make (and run) both versions without problems...
> >> That's exactly what I meant.  You've got to do what you've got to do,
> >> but you should also know what kind of trouble you are getting yourself
> >> in.
>
> Well the thing is that it was "playing with fire" to have the two
> bitnesses of *MinGW* cohabitate... but all flavours of OUR dlls (i.e.
> our output) are named differently - precisely in order to avoid loading
> the wrong one. ;-)

Which means you need to rebuild all of the DLLs you rely upon to name
them differently.  That's not a practical thing to expect of the MinGW
users.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Yongwei Wu
On 13 December 2014 at 16:18, Eli Zaretskii <[hidden email]> wrote:
>> Well the thing is that it was "playing with fire" to have the two
>> bitnesses of *MinGW* cohabitate... but all flavours of OUR dlls (i.e.
>> our output) are named differently - precisely in order to avoid loading
>> the wrong one. ;-)
>
> Which means you need to rebuild all of the DLLs you rely upon to name
> them differently.  That's not a practical thing to expect of the MinGW
> users.

I actually suggest that MinGW distribute DLLs with a unified prefix
like mwd (mingw dwarf2). I am not expecting anything from the normal
users.

Best regards,

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Eli Zaretskii
> Date: Sat, 13 Dec 2014 21:49:20 +0800
> From: Yongwei Wu <[hidden email]>
>
> On 13 December 2014 at 16:18, Eli Zaretskii <[hidden email]> wrote:
> >> Well the thing is that it was "playing with fire" to have the two
> >> bitnesses of *MinGW* cohabitate... but all flavours of OUR dlls (i.e.
> >> our output) are named differently - precisely in order to avoid loading
> >> the wrong one. ;-)
> >
> > Which means you need to rebuild all of the DLLs you rely upon to name
> > them differently.  That's not a practical thing to expect of the MinGW
> > users.
>
> I actually suggest that MinGW distribute DLLs with a unified prefix
> like mwd (mingw dwarf2). I am not expecting anything from the normal
> users.

But many important libraries are not distributed by mingw.org, they
come from other sources, like GTK, GnuWin32, ezwinports, etc.  So this
is not a safe solution, either.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Greg Jung
In reply to this post by Sean Sill

> From: Yongwei Wu <[hidden email]>

>I do have two conflicting libstdc++-6.dll on our my system (though
>only one in the system path). It would be better if we avoided it
>proactively.

The situation should firstly be better exposed so that a novice user will be aware of
 the complications involved.  

For any given .dll to be used in a program, there are 4 flavors of (exception, thread) combos
possible and a mixture of different ones is likely to be trouble at some point.
 Add to this, 64- or 32-bit making eight  possible for running a 64-bit system.
I don;t think a centralized library repository is feasible (unless you can buy into the SysWOW protocol);
 a path modification for any given program seems to be more appropriate.  

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: libstdc++-6.dll seg fault.

Chris Johns
In reply to this post by Eli Zaretskii
On 13/12/2014 7:16 pm, Eli Zaretskii wrote:

>> Date: Sat, 13 Dec 2014 10:38:23 +0800
>> From: Yongwei Wu <[hidden email]>
>>
>>> I don't think there's a hope of this ever becoming easier.  You cannot
>>> easily mix incompatible runtimes in the same session, on any machine
>>> and OS.
>>
>> Some runtimes are not supposed to be mixed in the same process, but
>> they should be able to exist safely on the same machine. We only need
>> to name them better. That is the intention of the library prefix.
>
> I don't think this is practically achievable.  There are several
> GNU-based Windows toolchains with subtle changes, each one supported
> by a group of volunteers.  You expect from those people too high level
> of coordination.
>
> E.g., take the simplest thing: producing a port of some Free Software
> library -- do you expect me to hack its Makefile's just to make sure
> the DLLs have some predefined prefix?  That's a nuisance on top of an
> already uphill battle I need to fight just to have that library built
> and get past all the tests.  And who and how would decide which prefix
> to use for each project?
>
> Impractical.
>

I agree.

And Mingw has not helped with basic library names such as libz (or is it
zlib) ...

https://bugzilla.redhat.com/show_bug.cgi?id=630522

We avoid that specific issue these days by asking gcc to build zlib when
cross-compiling.

Chris

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe