Question: Where do mingw version conflicts enter?

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

Question: Where do mingw version conflicts enter?

Greg Jung
I am trying to build a mingw-org platform, and I am tempted to bring in some library dependencies
from a mingw-w64 distribution I have.  These will be installed in /mingw/opt/ and kept separate, as well
as any packages I build.  All of these are built with gcc 4.8.1, win32, dwarf2 ( if that makes any difference,
since they are mostly C libraries and not C++).

I know I'm playing with fire ... am I likely to get burned?
  Specifically, are these libraries likely to call on mingw-w64 CRT and encounter conflicts when linked with
mainly minw-org CRT? 

Is there a way to discover a mingw dependency in a binary file?

Regards, 
Greg


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
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: Question: Where do mingw version conflicts enter?

Earnie Boyd
On 12/6/2015 5:51 PM, Greg Jung wrote:
> I am trying to build a mingw-org platform, and I am tempted to bring in
> some library dependencies
> from a mingw-w64 distribution I have.  These will be installed in
> /mingw/opt/ and kept separate, as well
> as any packages I build.  All of these are built with gcc 4.8.1, win32,
> dwarf2 ( if that makes any difference,
> since they are mostly C libraries and not C++).
>
> I know I'm playing with fire ... am I likely to get burned?

Maybe, maybe not.  It is yet to be seen.

>   Specifically, are these libraries likely to call on mingw-w64 CRT and
> encounter conflicts when linked with
> mainly minw-org CRT?
>

Since both use MSVCRT.DLL then the CRT is the same.  Just stay away from
threading you'll probably incur penalties if you need to use threads.

> Is there a way to discover a mingw dependency in a binary file?
>

DependencyWalker?

--
Earnie

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
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: Question: Where do mingw version conflicts enter?

Eli Zaretskii
> From: Earnie <[hidden email]>
> Date: Mon, 7 Dec 2015 08:38:50 -0500
>
> > Is there a way to discover a mingw dependency in a binary file?
>
> DependencyWalker?

Yes.  Alternatively, objdump from Binutils.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
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: Question: Where do mingw version conflicts enter?

Greg Jung


On Mon, Dec 7, 2015 at 8:01 AM, Eli Zaretskii <[hidden email]> wrote:
> From: Earnie <[hidden email]>
> Date: Mon, 7 Dec 2015 08:38:50 -0500
>
> > Is there a way to discover a mingw dependency in a binary file?
>
> DependencyWalker?

Yes.  Alternatively, objdump from Binutils.

ldd (using msys2) was most useful as a dependency check.

I suppose I'm still wildly ignorant about what difference it makes, if mingw is either 3.2 or 4.0.
They each have different header files - I know that - and these will be used to interface
to the same MSVCRT.dll.  Assuming they are both bug-free w.r.t. the use I will put them to, 
the .dll's are self-contained with identical interfacing --- there is no mingw-XXX.dll used,
so mix & match w.r.t. mingw versions seems ok (?)

Of course more caution is needed when mixing GCC flavors and versions.  When the threading
is invoked in the library - widget libraries, for instance.


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
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: Question: Where do mingw version conflicts enter?

Eli Zaretskii
> Date: Mon, 7 Dec 2015 22:28:07 -0800
> From: Greg Jung <[hidden email]>
>
> I suppose I'm still wildly ignorant about what difference it makes, if mingw is
> either 3.2 or 4.0.
> They each have different header files - I know that - and these will be used to
> interface
> to the same MSVCRT.dll. Assuming they are both bug-free w.r.t. the use I will
> put them to,
> the .dll's are self-contained with identical interfacing --- there is no
> mingw-XXX.dll used,
> so mix & match w.r.t. mingw versions seems ok (?)

The differences that will bite are, AFAIK:

 . different versions of functions that come from libmingwex
 . different defaults regarding time_t and functions that accept or
   return that type
 . different signature of readdir
 . subtle differences in how the startup code expands widlcards

The default version of MSVCRT.DLL might also be different (for
MinGW64), you had better checked.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
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: Question: Where do mingw version conflicts enter?

Greg Jung
The differences that will bite are, AFAIK:

 . different versions of functions that come from libmingwex
 . different defaults regarding time_t and functions that accept or
   return that type
 . different signature of readdir
 . subtle differences in how the startup code expands widlcards

OK and I'm finding a major difference, you may think its too obvious to mention,
the threads support libraries go from pthreadGC2, pthreadGCE2 for mingw-org
 to libwinpthread for mingw-w64.  I hadn't realized that for even both "win-dwarf"
they would use different thread libraries.  And, libwinpthread appears to also
service the posix thread model  for mingw-w64, also.

On Tue, Dec 8, 2015 at 8:13 AM, Eli Zaretskii <[hidden email]> wrote:
> Date: Mon, 7 Dec 2015 22:28:07 -0800
> From: Greg Jung <[hidden email]>
>
> I suppose I'm still wildly ignorant about what difference it makes, if mingw is
> either 3.2 or 4.0.
> They each have different header files - I know that - and these will be used to
> interface
> to the same MSVCRT.dll. Assuming they are both bug-free w.r.t. the use I will
> put them to,
> the .dll's are self-contained with identical interfacing --- there is no
> mingw-XXX.dll used,
> so mix & match w.r.t. mingw versions seems ok (?)

The differences that will bite are, AFAIK:

 . different versions of functions that come from libmingwex
 . different defaults regarding time_t and functions that accept or
   return that type
 . different signature of readdir
 . subtle differences in how the startup code expands widlcards

The default version of MSVCRT.DLL might also be different (for
MinGW64), you had better checked.


------------------------------------------------------------------------------

_______________________________________________
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