mingw-users Mailing List for MinGW - Minimalist GNU for Windows

Hi,

Thank you for this guess.

In fact, things seems much more messier than that. Indeed, the umatelasticity2_* symbols disapear if linked with the umatelasticity_* symbols into the final dll. They are many of them, as listed below. Most of them are exported data (unsigned short, etc...) and only one is a function : umatelasticity2.

As said before, without linking with umatelasticity_* everything is ok. Seems like a name conflict as you suggested.

But after several try and guess, I realised that umatelasticity2 used another symbol from the same dll (and umatelasticity not). If I remove the corresponding function call, I can link umatelasticity* and umatelasticty2* without trouble. This is hardly understandable as most the umatelasticity2_* symbols are not functions.

After hours of effort, I did not manage to get a simple test case. It does seem that the whole tool-chain has to be taken into account (cmake+mingw+specific flags...) and my project is far to big to reasonnably ask
someone look at it....


Table [Ordinal/Nom de pointeur]
	[   0] ELASTICITY_F77
	[   1] ELASTICITY_FRST_F77
	[   2] ELASTICITY_LOG1D_F77
	[   3] ELASTICITY_MALLS_F77
	[   4] ELASTICITY_SS_F77
	[   5] Elasticity
	[   6] Elasticity_frst
	[   7] Elasticity_log1D
	[   8] Elasticity_malls
	[   9] Elasticity_ss
	[  10] UMATELASTICITY_F77
	[  11] UMATELASTICITY_FRST_F77
	[  12] UMATELASTICITY_LOG1D_F77
	[  13] UMATELASTICITY_MALLS_F77
	[  14] UMATELASTICITY_SS_F77
	[  15] umatelasticity
	[  16] umatelasticity_BehaviourType
	[  17] umatelasticity_ElasticSymmetryType
	[  18] umatelasticity_ExternalStateVariables
	[  19] umatelasticity_Interface
	[  20] umatelasticity_InternalStateVariables
	[  21] umatelasticity_InternalStateVariablesTypes
	[  22] umatelasticity_MaterialProperties
	[  23] umatelasticity_ModellingHypotheses
	[  24] umatelasticity_PlaneStress_ExternalStateVariables
	[  25] umatelasticity_PlaneStress_InternalStateVariables
	[  26] umatelasticity_PlaneStress_InternalStateVariablesTypes
	[  27] umatelasticity_PlaneStress_MaterialProperties
	[  28] umatelasticity_PlaneStress_UsableInPurelyImplicitResolution
	[  29] umatelasticity_PlaneStress_nExternalStateVariables
	[  30] umatelasticity_PlaneStress_nInternalStateVariables
	[  31] umatelasticity_PlaneStress_nMaterialProperties
	[  32] umatelasticity_PlaneStress_requiresStiffnessTensor
	[  33] umatelasticity_PlaneStress_requiresThermalExpansionCoefficientTensor
	[  34] umatelasticity_SymmetryType
	[  35] umatelasticity_UsableInPurelyImplicitResolution
	[  36] umatelasticity_UsesGenericPlaneStressAlgorithm
	[  37] umatelasticity_frst
	[  38] umatelasticity_frst_BehaviourType
	[  39] umatelasticity_frst_ElasticSymmetryType
	[  40] umatelasticity_frst_ExternalStateVariables
	[  41] umatelasticity_frst_Interface
	[  42] umatelasticity_frst_InternalStateVariables
	[  43] umatelasticity_frst_InternalStateVariablesTypes
	[  44] umatelasticity_frst_MaterialProperties
	[  45] umatelasticity_frst_ModellingHypotheses
	[  46] umatelasticity_frst_PlaneStress_ExternalStateVariables
	[  47] umatelasticity_frst_PlaneStress_InternalStateVariables
	[  48] umatelasticity_frst_PlaneStress_InternalStateVariablesTypes
	[  49] umatelasticity_frst_PlaneStress_MaterialProperties
	[  50] umatelasticity_frst_PlaneStress_UsableInPurelyImplicitResolution
	[  51] umatelasticity_frst_PlaneStress_nExternalStateVariables
	[  52] umatelasticity_frst_PlaneStress_nInternalStateVariables
	[  53] umatelasticity_frst_PlaneStress_nMaterialProperties
	[  54] umatelasticity_frst_PlaneStress_requiresStiffnessTensor
	[  55] umatelasticity_frst_PlaneStress_requiresThermalExpansionCoefficientTensor
	[  56] umatelasticity_frst_SymmetryType
	[  57] umatelasticity_frst_UsableInPurelyImplicitResolution
	[  58] umatelasticity_frst_UsesGenericPlaneStressAlgorithm
	[  59] umatelasticity_frst_nExternalStateVariables
	[  60] umatelasticity_frst_nInternalStateVariables
	[  61] umatelasticity_frst_nMaterialProperties
	[  62] umatelasticity_frst_nModellingHypotheses
	[  63] umatelasticity_frst_requiresStiffnessTensor
	[  64] umatelasticity_frst_requiresThermalExpansionCoefficientTensor
	[  65] umatelasticity_frst_src
	[  66] umatelasticity_log1d
	[  67] umatelasticity_log1d_BehaviourType
	[  68] umatelasticity_log1d_ElasticSymmetryType
	[  69] umatelasticity_log1d_ExternalStateVariables
	[  70] umatelasticity_log1d_Interface
	[  71] umatelasticity_log1d_InternalStateVariables
	[  72] umatelasticity_log1d_InternalStateVariablesTypes
	[  73] umatelasticity_log1d_MaterialProperties
	[  74] umatelasticity_log1d_ModellingHypotheses
	[  75] umatelasticity_log1d_PlaneStress_ExternalStateVariables
	[  76] umatelasticity_log1d_PlaneStress_InternalStateVariables
	[  77] umatelasticity_log1d_PlaneStress_InternalStateVariablesTypes
	[  78] umatelasticity_log1d_PlaneStress_MaterialProperties
	[  79] umatelasticity_log1d_PlaneStress_UsableInPurelyImplicitResolution
	[  80] umatelasticity_log1d_PlaneStress_nExternalStateVariables
	[  81] umatelasticity_log1d_PlaneStress_nInternalStateVariables
	[  82] umatelasticity_log1d_PlaneStress_nMaterialProperties
	[  83] umatelasticity_log1d_PlaneStress_requiresStiffnessTensor
	[  84] umatelasticity_log1d_PlaneStress_requiresThermalExpansionCoefficientTensor
	[  85] umatelasticity_log1d_SymmetryType
	[  86] umatelasticity_log1d_UsableInPurelyImplicitResolution
	[  87] umatelasticity_log1d_UsesGenericPlaneStressAlgorithm
	[  88] umatelasticity_log1d_nExternalStateVariables
	[  89] umatelasticity_log1d_nInternalStateVariables
	[  90] umatelasticity_log1d_nMaterialProperties
	[  91] umatelasticity_log1d_nModellingHypotheses
	[  92] umatelasticity_log1d_requiresStiffnessTensor
	[  93] umatelasticity_log1d_requiresThermalExpansionCoefficientTensor
	[  94] umatelasticity_log1d_src
	[  95] umatelasticity_malls
	[  96] umatelasticity_malls_BehaviourType
	[  97] umatelasticity_malls_ElasticSymmetryType
	[  98] umatelasticity_malls_ExternalStateVariables
	[  99] umatelasticity_malls_Interface
	[ 100] umatelasticity_malls_InternalStateVariables
	[ 101] umatelasticity_malls_InternalStateVariablesTypes
	[ 102] umatelasticity_malls_MaterialProperties
	[ 103] umatelasticity_malls_ModellingHypotheses
	[ 104] umatelasticity_malls_PlaneStress_ExternalStateVariables
	[ 105] umatelasticity_malls_PlaneStress_InternalStateVariables
	[ 106] umatelasticity_malls_PlaneStress_InternalStateVariablesTypes
	[ 107] umatelasticity_malls_PlaneStress_MaterialProperties
	[ 108] umatelasticity_malls_PlaneStress_UsableInPurelyImplicitResolution
	[ 109] umatelasticity_malls_PlaneStress_nExternalStateVariables
	[ 110] umatelasticity_malls_PlaneStress_nInternalStateVariables
	[ 111] umatelasticity_malls_PlaneStress_nMaterialProperties
	[ 112] umatelasticity_malls_PlaneStress_requiresStiffnessTensor
	[ 113] umatelasticity_malls_PlaneStress_requiresThermalExpansionCoefficientTensor
	[ 114] umatelasticity_malls_SymmetryType
	[ 115] umatelasticity_malls_UsableInPurelyImplicitResolution
	[ 116] umatelasticity_malls_UsesGenericPlaneStressAlgorithm
	[ 117] umatelasticity_malls_nExternalStateVariables
	[ 118] umatelasticity_malls_nInternalStateVariables
	[ 119] umatelasticity_malls_nMaterialProperties
	[ 120] umatelasticity_malls_nModellingHypotheses
	[ 121] umatelasticity_malls_requiresStiffnessTensor
	[ 122] umatelasticity_malls_requiresThermalExpansionCoefficientTensor
	[ 123] umatelasticity_malls_src
	[ 124] umatelasticity_nExternalStateVariables
	[ 125] umatelasticity_nInternalStateVariables
	[ 126] umatelasticity_nMaterialProperties
	[ 127] umatelasticity_nModellingHypotheses
	[ 128] umatelasticity_requiresStiffnessTensor
	[ 129] umatelasticity_requiresThermalExpansionCoefficientTensor
	[ 130] umatelasticity_src
	[ 131] umatelasticity_ss
	[ 132] umatelasticity_ss_BehaviourType
	[ 133] umatelasticity_ss_ElasticSymmetryType
	[ 134] umatelasticity_ss_ExternalStateVariables
	[ 135] umatelasticity_ss_Interface
	[ 136] umatelasticity_ss_InternalStateVariables
	[ 137] umatelasticity_ss_InternalStateVariablesTypes
	[ 138] umatelasticity_ss_MaterialProperties
	[ 139] umatelasticity_ss_ModellingHypotheses
	[ 140] umatelasticity_ss_PlaneStress_ExternalStateVariables
	[ 141] umatelasticity_ss_PlaneStress_InternalStateVariables
	[ 142] umatelasticity_ss_PlaneStress_InternalStateVariablesTypes
	[ 143] umatelasticity_ss_PlaneStress_MaterialProperties
	[ 144] umatelasticity_ss_PlaneStress_UsableInPurelyImplicitResolution
	[ 145] umatelasticity_ss_PlaneStress_nExternalStateVariables
	[ 146] umatelasticity_ss_PlaneStress_nInternalStateVariables
	[ 147] umatelasticity_ss_PlaneStress_nMaterialProperties
	[ 148] umatelasticity_ss_PlaneStress_requiresStiffnessTensor
	[ 149] umatelasticity_ss_PlaneStress_requiresThermalExpansionCoefficientTensor
	[ 150] umatelasticity_ss_SymmetryType
	[ 151] umatelasticity_ss_UsableInPurelyImplicitResolution
	[ 152] umatelasticity_ss_UsesGenericPlaneStressAlgorithm
	[ 153] umatelasticity_ss_nExternalStateVariables
	[ 154] umatelasticity_ss_nInternalStateVariables
	[ 155] umatelasticity_ss_nMaterialProperties
	[ 156] umatelasticity_ss_nModellingHypotheses
	[ 157] umatelasticity_ss_requiresStiffnessTensor
	[ 158] umatelasticity_ss_requiresThermalExpansionCoefficientTensor
	[ 159] umatelasticity_ss_src


----- Mail original -----
De: "Peter Rockett" <p.r...@sh...>
À: min...@li...
Envoyé: Lundi 29 Juin 2015 21:34:45
Objet: Re: [Mingw-users] GetProcAdress can't find a symbol in a mingw generated library

On 29/06/15 17:12, hel...@fr... wrote:
> It seems that I have got confused by my different tests. Indeed, the symbols umatelasticity2_BehaviourType does not seem to be exported if umatelasticit_BehaviourType is declared.
>
> Any ideas ?

A random guess: Is there any limit on the length of the names of 
exported symbols such that they are not considered as unique? Your two 
symbols differ after the 14th character, which seems an odd limit. But 
if the symbols are decorated or name-mangled, that might push the 
lengths over 16 characters, which seems a more likely limit (if one 
exists). Easy test: What happens when you (radically) change the name of 
the second symbol?

P.

>
> Sincerly,
>
> Helfer Thomas
>
> ----- Mail original -----
> De: hel...@fr...
> À: min...@li...
> Envoyé: Lundi 29 Juin 2015 16:05:21
> Objet: [Mingw-users] GetProcAdress can't find a symbol in a mingw	generated library
>
> Hi,
>
> my name is Thomas Helfer. I am working on a code generator named mfront (http:/tfel.sourceforge.net). I mostly work on POSIX systems and have few experience with windows development (no one is perfect).
>
> I have found an interesting trouble while porting my software using MinGW. If my dll contains two exported symbols named umatelasticty_BehaviourType and umatelasticity2_BehaviourType, then I can not use GetProcAdress on the second symbol (missing symbols error message) and of course I can call it on the first one without trouble. Tools like dlldepends, objdump does not show any significant difference between those two symbols.
>
> Things get more interesting if I remove the source defining the first symbol. In this case, everything works fine.
>
> If needed, I can send a copy of the dll or any details if required to go further.
>
> However, I though those first hints may help someone to the solution to my problem.
>
> Thank for any help,
>
> Sincerly,
>
> Helfer Thomas
>
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors
> network devices and physical & virtual servers, alerts via email & sms
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> 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:min...@li...?subject=unsubscribe
>
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors
> network devices and physical & virtual servers, alerts via email & sms
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> 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:min...@li...?subject=unsubscribe


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
MinGW-users mailing list
Min...@li...

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:min...@li...?subject=unsubscribe

On 29/06/15 17:12, hel...@fr... wrote:
> It seems that I have got confused by my different tests. Indeed, the symbols umatelasticity2_BehaviourType does not seem to be exported if umatelasticit_BehaviourType is declared.
>
> Any ideas ?

A random guess: Is there any limit on the length of the names of 
exported symbols such that they are not considered as unique? Your two 
symbols differ after the 14th character, which seems an odd limit. But 
if the symbols are decorated or name-mangled, that might push the 
lengths over 16 characters, which seems a more likely limit (if one 
exists). Easy test: What happens when you (radically) change the name of 
the second symbol?

P.

>
> Sincerly,
>
> Helfer Thomas
>
> ----- Mail original -----
> De: hel...@fr...
> À: min...@li...
> Envoyé: Lundi 29 Juin 2015 16:05:21
> Objet: [Mingw-users] GetProcAdress can't find a symbol in a mingw	generated library
>
> Hi,
>
> my name is Thomas Helfer. I am working on a code generator named mfront (http:/tfel.sourceforge.net). I mostly work on POSIX systems and have few experience with windows development (no one is perfect).
>
> I have found an interesting trouble while porting my software using MinGW. If my dll contains two exported symbols named umatelasticty_BehaviourType and umatelasticity2_BehaviourType, then I can not use GetProcAdress on the second symbol (missing symbols error message) and of course I can call it on the first one without trouble. Tools like dlldepends, objdump does not show any significant difference between those two symbols.
>
> Things get more interesting if I remove the source defining the first symbol. In this case, everything works fine.
>
> If needed, I can send a copy of the dll or any details if required to go further.
>
> However, I though those first hints may help someone to the solution to my problem.
>
> Thank for any help,
>
> Sincerly,
>
> Helfer Thomas
>
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors
> network devices and physical & virtual servers, alerts via email & sms
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> 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:min...@li...?subject=unsubscribe
>
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors
> network devices and physical & virtual servers, alerts via email & sms
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> 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:min...@li...?subject=unsubscribe

It seems that I have got confused by my different tests. Indeed, the symbols umatelasticity2_BehaviourType does not seem to be exported if umatelasticit_BehaviourType is declared.

Any ideas ?

Sincerly,

Helfer Thomas

----- Mail original -----
De: hel...@fr...
À: min...@li...
Envoyé: Lundi 29 Juin 2015 16:05:21
Objet: [Mingw-users] GetProcAdress can't find a symbol in a mingw	generated library

Hi,

my name is Thomas Helfer. I am working on a code generator named mfront (http:/tfel.sourceforge.net). I mostly work on POSIX systems and have few experience with windows development (no one is perfect).

I have found an interesting trouble while porting my software using MinGW. If my dll contains two exported symbols named umatelasticty_BehaviourType and umatelasticity2_BehaviourType, then I can not use GetProcAdress on the second symbol (missing symbols error message) and of course I can call it on the first one without trouble. Tools like dlldepends, objdump does not show any significant difference between those two symbols.

Things get more interesting if I remove the source defining the first symbol. In this case, everything works fine.

If needed, I can send a copy of the dll or any details if required to go further.

However, I though those first hints may help someone to the solution to my problem.

Thank for any help,

Sincerly,

Helfer Thomas

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
MinGW-users mailing list
Min...@li...

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:min...@li...?subject=unsubscribe

Hi,

my name is Thomas Helfer. I am working on a code generator named mfront (http:/tfel.sourceforge.net). I mostly work on POSIX systems and have few experience with windows development (no one is perfect).

I have found an interesting trouble while porting my software using MinGW. If my dll contains two exported symbols named umatelasticty_BehaviourType and umatelasticity2_BehaviourType, then I can not use GetProcAdress on the second symbol (missing symbols error message) and of course I can call it on the first one without trouble. Tools like dlldepends, objdump does not show any significant difference between those two symbols.

Things get more interesting if I remove the source defining the first symbol. In this case, everything works fine.

If needed, I can send a copy of the dll or any details if required to go further.

However, I though those first hints may help someone to the solution to my problem.

Thank for any help,

Sincerly,

Helfer Thomas

On 6/26/2015 7:37 AM, Earnie wrote:
>> From: John E. / TDM
>>
>> http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-
>> gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/
>>
>> Pretty sure SourceForge was intentional about it.
>>
> So from this article and the links it provides I discover that the GIMP-WIN project file delivery wasn't using SF.
> SF decided to mirror the new project downloads for the old account.

Actually, Jernej Simončič (a 3rd-party developer who built GIMP binaries 
for Windows) made the decision to use SF as a mirror.

> Only mirrored projects get the adware installer by default.
> We are not a mirrored project so we get no adware wrapped installer.

Actually, it's projects that the SourceForge editor(s) view as being 
abandoned that got the adware installer. Active projects can, for now, 
choose to use or not use it on an opt-in basis.

I see it as being pretty distasteful to have SourceForge monetizing 
abandoned repositories without the explicit consent of the authors - 
even if the license those authors chose allows it, I would prefer 
SourceForge to take the high ground.

-John E. / TDM

> From: John E. / TDM 
> 
> http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-
> gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/
> 
> Pretty sure SourceForge was intentional about it.
> 

So from this article and the links it provides I discover that the GIMP-WIN project file delivery wasn't using SF.
SF decided to mirror the new project downloads for the old account.
Only mirrored projects get the adware installer by default.
We are not a mirrored project so we get no adware wrapped installer.

Also sf.net/p/gimp-win now redirects to the official gimp.org page.

--
Earnie

> Date: Thu, 25 Jun 2015 15:08:48 +0400
> From: Адель Хафизова
> 	<ade...@gm...>
> 
> I tried building pthreads statically with
> make clean GC-static
> The result was the same: libpthread.a produced with this build when linked
> without -static gives pthreadGC2.dll dependency, with -static option it doesn't
> link. Could you please give a general overview what to do to make this work?

Please provide the details regarding "with -static option it doesn't
link".  What happens if you try?  If there are error messages, please
show them.

Thanks everyone for the discussion.
Still there are some issues I misunderstand.
I tried building pthreads statically with
make clean GC-static
The result was the same: libpthread.a produced with this build when linked
without -static gives pthreadGC2.dll dependency, with -static option it
doesn't link. Could you please give a general overview what to do to make
this work?
Are there any other possible solutions except taking this .dll to another
computer (if I got it correctly, I can't just use win32 threads)?

2015-06-24 2:10 GMT+04:00 Sergio NNX <sfh...@ho...>:

> > 1. Do I still need to somehow compile pthread statically? And
> libpthreadGC2.a is not actually a static library? If so, is there an
> updated
> > instruction?
>
> We have been using pthreads statically for some time now without issues.
> We have built several large apps from source and haven't had any problems
> so far. Perhaps you should give it a go.
>
> Cheers.
>



-- 
Best regards,
Adel Khafizova

> From: "John E. / TDM" <td...@td...>
> Date: Wed, 24 Jun 2015 09:40:39 -0600
> 
> On 6/24/2015 8:23 AM, Eli Zaretskii wrote:
> > Btw, which parts of C++ need libgomp?
> 
> To my knowledge, none. If a GCC user specifies -fopenmp (to enable 
> support of OMP directives), it understandably creates a dependency on 
> libgomp (which depends on pthreads), but if -fopenmp is not used I don't 
> think there's any libgomp or pthreads dependency.

Ah, OK.  So the only reason for dependency on pthreadGC2.dll in this
case was that -fopenmp switch, and nothing else.

Thanks.

On 6/24/2015 8:23 AM, Eli Zaretskii wrote:
> Btw, which parts of C++ need libgomp?

To my knowledge, none. If a GCC user specifies -fopenmp (to enable 
support of OMP directives), it understandably creates a dependency on 
libgomp (which depends on pthreads), but if -fopenmp is not used I don't 
think there's any libgomp or pthreads dependency.

-John E. / TDM

> Date: Wed, 24 Jun 2015 05:45:45 +0300
> From: Eli Zaretskii <el...@gn...>
> 
> > From: "John E. / TDM" <td...@td...>
> > Date: Tue, 23 Jun 2015 15:42:28 -0600
> > 
> > > Based on the error messages, I understand that it's libgomp that was
> > > configured to use pthreads, and is the reason why pthreadGC2.dll is
> > > needed, is that right?  IOW, to avoid this problem, one needs to
> > > rebuild libgomp, configuring it to use win32 threads instead (assuming
> > > libgomp supports such a configuration), correct?
> > 
> > Sadly, libgomp won't compile without pthreads.
> 
> Sad indeed.

Btw, which parts of C++ need libgomp?

> From: "John E. / TDM" <td...@td...>
> Date: Tue, 23 Jun 2015 15:42:28 -0600
> 
> > Based on the error messages, I understand that it's libgomp that was
> > configured to use pthreads, and is the reason why pthreadGC2.dll is
> > needed, is that right?  IOW, to avoid this problem, one needs to
> > rebuild libgomp, configuring it to use win32 threads instead (assuming
> > libgomp supports such a configuration), correct?
> 
> Sadly, libgomp won't compile without pthreads.

Sad indeed.

> > Are there any other GCC components that depend on pthreads?
> 
> The C++11 threading/synchronization features (std::thread and friends) 
> require pthreads as well -- for a default native build with the win32 
> threading model, GCC will still successfully build but these features 
> will be unavailable.

I know, but that's irrelevant here, since mingw.org's GCC is built
with native threads (and thus doesn't support std::thread).

> 1. Do I still need to somehow compile pthread statically? And libpthreadGC2.a is not actually a static library? If so, is there an updated 
> instruction?

We have been using pthreads statically for some time now without issues. We have built several large apps from source and haven't had any problems so far. Perhaps you should give it a go.

Cheers.
 		 	   		  

On 6/23/2015 12:28 PM, Eli Zaretskii wrote:
>> From: "Earnie" <ea...@us...>
>> Date: Tue, 23 Jun 2015 14:00:16 -0400
>>
>> The design of the pthread library is such that it must be dynamic.  It is impossible to do otherwise.

Used to be the case, but not anymore - both the pthreads-win32 and the 
winpthreads wrapper libraries can be built statically and will still 
perform all necessary startup task via special callbacks.

Static pthreads will mean you can't safely share pthreads handles across 
the DLL boundary, but that won't matter to the OP who is trying to get 
rid of all DLL dependencies.

>>    The alternative is to use the Windows methods for threading in the package you're building instead of relying on POSIX threading model.
> Based on the error messages, I understand that it's libgomp that was
> configured to use pthreads, and is the reason why pthreadGC2.dll is
> needed, is that right?  IOW, to avoid this problem, one needs to
> rebuild libgomp, configuring it to use win32 threads instead (assuming
> libgomp supports such a configuration), correct?

Sadly, libgomp won't compile without pthreads.

> Are there any other GCC components that depend on pthreads?

The C++11 threading/synchronization features (std::thread and friends) 
require pthreads as well -- for a default native build with the win32 
threading model, GCC will still successfully build but these features 
will be unavailable.

-John E. / TDM

> From: "Earnie" <ea...@us...>
> Date: Tue, 23 Jun 2015 14:00:16 -0400
> 
> > At this point I can't get rid of pthreadGC2.dll. Linking statically either makes no
> > effect (.exe file still needs pthreadGC2.dll) or fails with errors:
> > ln.exe -s `g++ -print-file-name=libgomp.a`
> > g++ openmp.cpp -o openmp.exe -static-libgcc -static-libstdc++ -fopenmp -L.
> > C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0xbfe): undefined
> > reference to `_imp__pthread_attr_init'
> > C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0xc13): undefined
> > reference to _imp__pthread_attr_setdetachstate'
> > C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0x3c): undefined reference
> > to '_imp__pthread_attr_setstacksize'
> > After searching through the mailing list I have come across several possible
> > solutions, but the treads are rather old.
> > My questions are:
> > 1. Do I still need to somehow compile pthread statically? And libpthreadGC2.a is
> > not actually a static library? If so, is there an updated instruction?
> > 2. Are there any other libraries I need to actually make this work? In Linux it is
> > said that pthread needs to be included with libc.a and won't link without it.
> > Thank you in advance.
> 
> The design of the pthread library is such that it must be dynamic.  It is impossible to do otherwise.  The alternative is to use the Windows methods for threading in the package you're building instead of relying on POSIX threading model.

Based on the error messages, I understand that it's libgomp that was
configured to use pthreads, and is the reason why pthreadGC2.dll is
needed, is that right?  IOW, to avoid this problem, one needs to
rebuild libgomp, configuring it to use win32 threads instead (assuming
libgomp supports such a configuration), correct?

Are there any other GCC components that depend on pthreads?

TIA

> From: Адель Хафизова 


> At this point I can't get rid of pthreadGC2.dll. Linking statically either makes no
> effect (.exe file still needs pthreadGC2.dll) or fails with errors:
> ln.exe -s `g++ -print-file-name=libgomp.a`
> g++ openmp.cpp -o openmp.exe -static-libgcc -static-libstdc++ -fopenmp -L.
> C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0xbfe): undefined
> reference to `_imp__pthread_attr_init'
> C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0xc13): undefined
> reference to _imp__pthread_attr_setdetachstate'
> C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0x3c): undefined reference
> to '_imp__pthread_attr_setstacksize'
> After searching through the mailing list I have come across several possible
> solutions, but the treads are rather old.
> My questions are:
> 1. Do I still need to somehow compile pthread statically? And libpthreadGC2.a is
> not actually a static library? If so, is there an updated instruction?
> 2. Are there any other libraries I need to actually make this work? In Linux it is
> said that pthread needs to be included with libc.a and won't link without it.
> Thank you in advance.

The design of the pthread library is such that it must be dynamic.  It is impossible to do otherwise.  The alternative is to use the Windows methods for threading in the package you're building instead of relying on POSIX threading model.

--
Earnie

Hi,
I am trying to build an OpenMP program statically with MinGW32 4.8.1.
Building it dynamically worked fine and I decided to get rid of
dependencies.
objdump -p openmp.exe | grep.exe DLL


DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: msvcrt.dll
DLL Name: libgcc_s_dw2-1.dll
DLL Name: libgomp-1.dll
DLL Name: libstdc++-6.dll

After building with this command

ln.exe -s `g++ -print-file-name=libgomp.a`

g++ openmp.cpp -o openmp.exe -static-libgcc -static-libstdc++ -fopenmp -L.

I got the following set of DLL's

DLL Name: pthreadGC2.dll
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: msvcrt.dll

At this point I can't get rid of pthreadGC2.dll. Linking statically either
makes no effect (.exe file still needs pthreadGC2.dll) or fails with errors:

ln.exe -s `g++ -print-file-name=libgomp.a`

g++ openmp.cpp -o openmp.exe -static-libgcc -static-libstdc++ -fopenmp -L.

C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0xbfe): undefined
reference to `_imp__pthread_attr_init'
C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0xc13): undefined
reference to _imp__pthread_attr_setdetachstate'
C:\for_openmp_test/libgomp.a(env.o):(.text.startup+0x3c): undefined
reference to '_imp__pthread_attr_setstacksize'

After searching through the mailing list I have come across several
possible solutions, but the treads are rather old.
My questions are:

1. Do I still need to somehow compile pthread statically? And
libpthreadGC2.a is not actually a static library? If so, is there an
updated instruction?

2. Are there any other libraries I need to actually make this work? In
Linux it is said that pthread needs to be included with libc.a and won't
link without it.

Thank you in advance.

Keith Marshall wrote:

This is FORTRAN, right?  So VBANUM is passed *by reference*, (or so it
> was for *all* function and subroutine arguments, when I last wrote any
> FORTRAN -- about 15 years ago), yet here...



> ...you declare the interface in VBA, with VBANUM passed *by value*, so
> at the very least, your TIMES2 function will get garbage for its VBANUM
> argument.


Yes, this is Fortran. When I use ByRef (or don't specify) in VBA, it comes
up with a "Bad DLL calling convention" error. I assumed this meant I had
misunderstood something along the way, and so I changed it to ByVal, and it
appeared to work (except, you know, the crashing part). Any idea what else
I've done wrong?

Interestingly, I didn't have this issue with the original Fortran. The only
thing I had set as ByVal was a string, which I understand is necessary. The
rest were left as is, which I believe leaves them as ByRef. That one
crashes too, but it doesn't give me any grief about calling conventions.

Thanks for your reply.

Ben

On 11/06/15 11:22, Ben Firth wrote:
> My simple code is times2.for:
> 
>  FUNCTION TIMES2(VBANUM)

This is FORTRAN, right?  So VBANUM is passed *by reference*, (or so it
was for *all* function and subroutine arguments, when I last wrote any
FORTRAN -- about 15 years ago), yet here...

> Public Declare Function times2 Lib "C:\F\doubling.dll" (ByVal VBANUM
> As Double) As Double

...you declare the interface in VBA, with VBANUM passed *by value*, so
at the very least, your TIMES2 function will get garbage for its VBANUM
argument.

Now, as to why this might crash Excel:

- The value passed will be interpreted as an address; that may or may
  not be an address from which the process is allowed to read, when
  TIMES2 attempts to access what it thinks is the value for VBANUM,
  but if it isn't readable a memory violation (segmentation fault)
  will occur; this crashes the process.

- Even if the false address does represent readable memory, if the[*]
  processor is 32-bit that address occupies only four bytes of stack
  space, but your VBA has pushed eight bytes, (the size of a double).
  Believing that only four bytes are used to pass the VBANUM address,
  when it comes to return, TIMES2 will pop only four bytes off the
  stack, leaving the additional four bytes as a stack misalignment;
  this will almost certainly result in garbage being loaded into the
  instruction pointer, soon after TIMES2's return, and the process
  heads off into the twilight zone, and ultimate oblivion.

[*]: even if *your* processor is 64-bit, the focus of this list is on
compilers which target 32-bit, so *the* processor in question is 32-bit.

-- 
Regards,
Keith.

Hi,

I'm having trouble with some Fortran I've compiled as a DLL. When I call it
via VBA, it crashes Excel instantly. The original Fortran is quite large,
and requires a licence to some of it, so I've thrown together a simple
function. It also crashes, although the crash isn't instant now - it
manages to cycle through the "Excel has stopped working" messages.

I think the original Fortran should work, because if I change the Function
declaration to a Program, replace the function line with a command to write
the value to an output file, and compile as .exe, it works. The same goes
for my simple code.

My simple code is times2.for:

 FUNCTION TIMES2(VBANUM)
 REAL*8:: TIMES2, VBANUM
 !GCC$ ATTRIBUTES DLLEXPORT :: TIMES2
 !GCC$ ATTRIBUTES STDCALL :: TIMES2
 TIMES2 = VBANUM * 2.
 END FUNCTION TIMES2

The minGW commands I used are as follows:

gfortran -fno-underscoring -c times2.for
gfortran -fno-underscoring times2.o -shared -o doubling.dll -Wl,--kill-at

Then the VBA is below:

Public Declare Function times2 Lib "C:\F\doubling.dll" (ByVal VBANUM As
Double) As Double
Sub Twice()
Dim a As Double
a = Cells.Range("A1").Value
Cells.Range("A1").Value = times2(a)
End Sub

Now, I'm OK with VBA, have no experience with DLLs or minGW, and am trying
to recall rudimentary Fortran that I learned 10 years ago, so take it slow,
if you can.

Thanks for reading!
Ben

On 08/06/15 17:56, Eli Zaretskii wrote:
>> From: David Gressett <DGr...@am...>
>> I have removed the - -with-mpc, --with-mpfr, and --with-gmp elements
>> from CONFOPT, which means that you have to have the mpc, mpfr, and
>> gmp libraries installed in your MinGW configuration. I did this because
> 
> You mean, as opposed to having their sources in the GCC tree?

I normally place (symlink) these in-tree, and let them build along with
GCC itself.

> I see you use --enable-threads -- AFAIU this means libstdc++ will be
> devoid of <thread> implementation, is that right?  Did you do this on
> purpose, or just because previous MinGW compilers were built like
> that?

IIRC, Danny Smith, (a former GCC developer who also maintained our
releases up to, and including GCC-3.4.5), always built with this; I
guess we've just stuck with it, as a result of inertia, but there may
well be grounds for reviewing this choice.

>> I have had no success building gcc 5.1.0. The MinGW 3.21 runtime
>> introduced a new function which triggered a bug in the Fortran runtime
>> library. 
> 
> Which function is that?

I guess he's referring to the issue he reported, and I identified here:
http://thread.gmane.org/gmane.comp.gnu.mingw.user/44500/focus=44515

>> Going back to a previous V3 runtime would work around that problem,
>> but it would probably not work around another problem that occurs when
>> the Ada 5.1.0 runtime is built.
> 
> Building Ada requires a previous version of Gnat to be installed,
> doesn't it?

AFAIK, yes.  In fact, building Ada is a real PITA; when building
crossed-native, as I do, it requires a bootstrap of a build-native,
Ada-enabled GCC at identically the same version as the ultimate target,
which is then used to build an Ada-enabled cross-compiler at the same
version, which is then used to complete the crossed-native build.  When
I built GCC-4.8.2, I got as far as successfully building the Linux
hosted, Ada-enabled mingw32 cross-compiler, but never was able to
successfully complete the Ada component for the crossed-native build.

-- 
Regards,
Keith.

On 08/06/15 17:56, Eli Zaretskii wrote:
> Sorry, I think MinGW runtime V4 is a dead end,

I agree.

> because the incompatible way it treated time_t makes it impossible to
> build programs that run on old and new versions of Windows.

Not sure in what way it was "incompatible", but it was just plain
"wrong"; a bit of experimentation suggests that time_t is *always*
32-bit, when using MSVCRT.DLL, so _USE_32BIT_TIME_T is implicit, and
unnecessary, (unless you jump through the hoops to substitute any of the
brain damaged MSVCR80.DLL descendants).

> So I'm sticking with 3.21.1 for the time being, which has all the
> niceties of v4, but none of the problems (now that Keith fixed the
> last couple of them).

Actually, I overlooked one of them that I know of; the inline definition
of hypotf(), in math.h, is broken in a way which causes a G++ compile
which includes it, *and* has __STRICT_ANSI__ defined, to abort.  I
didn't have time to fix it properly, for 3.21.1, but I could have
mitigated the problem in the interim, by returning the cast of hypot()'s
return value, rather than _hypot()'s.

-- 
Regards,
Keith.

> From: David Gressett <DGr...@am...>
> Date: Mon, 8 Jun 2015 11:42:49 -0500
> 
> Here is my package.ini.

Thanks a lot!

> I have removed the - -with-mpc, --with-mpfr, and --with-gmp elements
> from CONFOPT, which means that you have to have the mpc, mpfr, and
> gmp libraries installed in your MinGW configuration. I did this because

You mean, as opposed to having their sources in the GCC tree?

I see you use --enable-threads -- AFAIU this means libstdc++ will be
devoid of <thread> implementation, is that right?  Did you do this on
purpose, or just because previous MinGW compilers were built like
that?

> I have had no success building gcc 5.1.0. The MinGW 3.21 runtime
>  introduced a new function which triggered a bug in the Fortran runtime
> library. 

Which function is that?

>  Going back to a previous V3 runtime would work around that problem,
> but it would probably not work around another problem that occurs when
>  the Ada 5.1.0 runtime is built.

Building Ada requires a previous version of Gnat to be installed,
doesn't it?

> It might be worth your time to focus on fixing the MinGW V4 runtime.

Sorry, I think MinGW runtime V4 is a dead end, because the
incompatible way it treated time_t makes it impossible to build
programs that run on old and new versions of Windows.

So I'm sticking with 3.21.1 for the time being, which has all the
niceties of v4, but none of the problems (now that Keith fixed the
last couple of them).

Thanks again for sharing your experience.

Eli Zaretskii wrote:

>On a (slightly) related topic: since no one seems to volunteer to
>build newer versions of GCC for MinGW, I could try doing that myself
>(the binaries will then be made available from the ezwinports site).
>But I need some help figuring out the prerequisite support packages I
>need to build first, and the optional GCC features to enable/disable.
>Last time I built GCC on any OS was many years ago, and a lot has
>changed since then.

>Keith, I've looked at your script that you used for GCC 4.8.2, but
>there were too many issues there that I couldn't figure out by myself,
>which means I'd need a lot of wading through GCC docs and sources (and
>a lot of Googling), before I make up my mind on these issues.

>Therefore, an annotated list of GCC prerequisites and build options,
>together with issues to consider when deciding whether or not to
>enable/include them in the MinGW build, will be most appreciated.

>Please note that I intend to build GCC natively, using MSYS.

>(In case it's important, I already have the latest Binutils built for
>MinGW, and can build newer versions of them if needed; building
>Binutils for MinGW is easy. Btw, if there's enough demand, I can make
>MinGW 32-bit build of Binutils 2.25 available on ezwinports.)

>TIA to anyone who could share their experiences and advice on this.

I have successfully built a MinGW gcc 4.9.2 with only a few minor 
tweaks to the build structure.  I reported the details on this list, but
that was back when 4.9.2 was just released. My build had a patch
for Ada to fix a bug in the Ada run-time library that only happens
when a 64-bit time_t is used.  This will not really be needed for a
build that uses the MinGW 3.21 runtime, but I am keeping in in my
builds in order to be ready for when a usable version of the MinGW
V4 appears. Here it is, gcc-4.9.2-mingw32.patch:

############################# This is a separator line, not part of the patch
--- gcc-4.9.1/gcc/ada/sysdep.c	2014-01-20 09:23:37 -0600
+++ gcc-4.9.1-patched/gcc/ada/sysdep.c	2014-09-10 09:41:36 -0500
@@ -68,6 +68,11 @@
 #include <time.h>
 #include <errno.h>
 
+#ifdef __MINGW32__
+#include <stdint.h>
+/* This may be useful for platforms other than Windows */
+#endif
+
 #if defined (sun) && defined (__SVR4) && !defined (__vxworks)
 /* The declaration is present in <time.h> but conditionalized
    on a couple of macros we don't define.  */
@@ -626,6 +631,11 @@
 
 #if defined (__MINGW32__)
 
+/* The size of the first argument of __gnat_localtime_tzoff must
+  match the size of the Ada type used by the calling routine. */
+
+typedef intptr_t ada_time_t;
+
 #ifdef CERT
 
 /* For the Cert run times on native Windows we use dummy functions
@@ -650,17 +660,21 @@
 /* Reentrant localtime for Windows. */
 
 extern void
-__gnat_localtime_tzoff (const time_t *, const int *, long *);
+__gnat_localtime_tzoff (const ada_time_t *, const int *, long *);
 
 static const unsigned long long w32_epoch_offset = 11644473600ULL;
 void
-__gnat_localtime_tzoff (const time_t *timer, const int *is_historic, long *off)
+__gnat_localtime_tzoff (const ada_time_t *ada_timer, const int *is_historic, long *off)
 {
+  time_t timer;
+  
   TIME_ZONE_INFORMATION tzi;
 
   BOOL  rtx_active;
   DWORD tzi_status;
 
+  timer = (time_t) *ada_timer;
+  
 #ifdef RTX
   rtx_active = 1;
 #else
@@ -707,7 +721,7 @@
     BOOL status;
 
     /* First convert unix time_t structure to windows FILETIME format.  */
-    utc_time.ull_time = ((unsigned long long) *timer + w32_epoch_offset)
+    utc_time.ull_time = ((unsigned long long) timer + w32_epoch_offset)
                         * 10000000ULL;
 
     /* If GetTimeZoneInformation does not return a value between 0 and 2 then

############################# This is a separator line, not part of the patch

Here is my package.ini. Not that I intended this to be contributed to the MinGW
project, so it does make some references to MinGW SourceForge things
that do not actually exist, but that won't keep you from using it. Note that
I have removed the - -with-mpc, --with-mpfr, and --with-gmp elements
from CONFOPT, which means that you have to have the mpc, mpfr, and
gmp libraries installed in your MinGW configuration. I did this because
the upstream gcc project has defined this as the recommended way to build
gcc, and I wanted to keep variations from such recommendations to a minimum:

##
# @file package.ini
# Copyright 2014 MinGW.org project
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
# 
# The above copyright notice and this permission notice (including the next
# paragraph) shall be included in all copies or substantial portions of the
# Software.
# 
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# This file is part of MinGW Package Maker (mpmkr)
#
# This file is the configuration part of mpmkr and should be modified for your
# package.
#
# This file was modified for the gcc-4.9.2 released file and represents the
# configuration of the distributed binary release found at the project URL of
# http://sf.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.9.2-1/.

# This variable contains the name of the package, e.g. mingwrt.
PKG = gcc

# This variable contains the package version as is shown by the name of the
# package file.
PKGVER = 4.9.2

# This variable contains additional package name data, usually empty. E.G. the
# upstream pthreads-w32 package name is pthreads-w32-2-9-1-release, the PKGEXTRA
# variable is set as PKGEXTRA = -release.
PKGEXTRA =

# This variable gives the archive format for the upstream file name.
PKGEXT = tar.bz2

# This variable gives the URL to find the package name in order to download it
# if necessary.  The $(PKGFILE) is a target in the Makefile and its rules will
# use this variable to attempt to download the file.
PKGURL = http://ftp.gnu.org/gnu/gcc/$(PKG)-$(PKGVER)

# This is the version of the package we wish to provide in package naming.  This
# variable will usually match the $(PKGVER) variable but sometimes the upstream
# package name doesn't contain a consistent naming pattern and we can override
# it here.  E.G. The pthreads-w32 package PKGVER variable is 1-0-0 which is not
# consistent with the MinGW naming pattern so we set MPKGVER = 1.0.0 instead.
MPKGVER = $(PKGVER)

# Set this variable with the package release sequence number. E.G. If I have
# package foo-1.0.0 already delivered as foo-1.0.0-1-mingw32 and I want to
# correct a package issue I would set this to 2 so that the packages are created
# as foo-1.0.0-2-mingw32.
MPKGRLS = 1

# Set this variable for the file extension matching the compression you wish
# to give it.
MPKGEXT = tar.lzma

# Set this variable for the mingw-get package identifier.
MPKGRT = mingw32

# Set this variable with a list of files to add as patches.  The order of the
# list may be important.
#MPATCHES = gcc-4.9.2-mingw32.patch
MPATCHES = 

# Set this variable for the options to the patch program.  It defaults to -p0.
MPATCHOPT =

# Set this variable to the final destination for installation.
PREFIX = /mingw

# Set this variable to the host environment "triplet" string.
HOST = mingw32

# Set this variable to the build environment "triplet" string.
BUILD = mingw32

# Set this variable with the options to the configure script.
CONFOPT = --prefix=$(PREFIX) --host=$(HOST) --build=$(BUILD) --with-arch=i586 --with-tune=generic --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs    --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s

# Set this variable with the files containing license you want copied to
# share/doc/$(PKG)/$(MPKGVER).  The list of files may contain sub-directories
# relative to the $(PACKAGE) directory.  E.G. Libiberty copied into packages
# like binutils and gcc has its own set of license files but libiberty
# is distributed with the base $(PACKAGE).  So include libiberty/COPYING.LIB to
# have it as part of the license file set.
#
core_LIC_FILES = COPYING COPYING.LIB COPYING.RUNTIME COPYING3 COPYING3.LIB gcc/COPYING gcc/COPYING.LIB gcc/COPYING3 gcc/COPYING3.LIB include/COPYING include/COPYING3 libiberty/COPYING.LIB libquadmath/COPYING.LIB libffi/LICENSE zlib/contrib/dotzlib/LICENSE_1_0.txt libsanitizer/LICENSE.TXT

# Set this variable with the files you want copied to
# share/doc/$(PKG)/$(MPKGVER).  The list of files may contain sub-directories
# relative to the $(PACKAGE) directory.  E.G. Libiberty copied into packages
# like binutils and gcc has its own set of documentation files but libiberty
# is distributed with the base $(PACKAGE).  So include libiberty/ChangeLog to
# have it as part of the documentation file set.
#
core_DOC_FILES = ABOUT-NLS ChangeLog* INSTALL/README LAST_UPDATED MAINTAINERS MD5SUMS NEWS README boehm-gc/ChangeLog* boehm-gc/doc/README.* boehm-gc/doc/barrett_diagram config/ChangeLog* contrib/ChangeLog* contrib/reghunt/ChangeLog* contrib/regression/ChangeLog* contrib/regression/README fixincludes/ChangeLog* fixincludes/README* gcc/ABOUT-GCC-NLS gcc/BASE-VER gcc/ChangeLog* gcc/DATESTAMP gcc/DEV-PHASE gcc/FSFChangeLog* gcc/LANGUAGES gcc/ONEWS gcc/README.Portability gcc/c/ChangeLog* gcc/c-family/ChangeLog* gcc/config/README gcc/cp/ChangeLog* gcc/cp/NEWS gcc/lto/ChangeLog* gcc/testsuite/ChangeLog* gcc/testsuite/README* include/ChangeLog* intl/ChangeLog* intl/README intl/VERSION libatomic/ChangeLog* libbacktrace/ChangeLog* libbacktrace/README libcpp/ChangeLog* libdecnumber/ChangeLog* libffi/ChangeLog* libffi/README libgcc/ChangeLog* libgomp/ChangeLog* libiberty/ChangeLog* libiberty/README libquadmath/ChangeLog* libssp/ChangeLog* libsanitizer/ChangeLog* libsanitizer/README.gcc libsanitizer/MERGE lto-plugin/ChangeLog* zlib/ChangeLog* zlib/FAQ zlib/INDEX zlib/README
ada_DOC_FILES = gcc/ada/ChangeLog* gnattools/ChangeLog* libada/ChangeLog* 
fortran_DOC_FILES = gcc/fortran/ChangeLog* libgfortran/ChangeLog* 
objc_DOC_FILES = gcc/objc/ChangeLog* gcc/objcp/ChangeLog* libobjc/ChangeLog* libobjc/README libobjc/THREADS 
cpp_DOC_FILES = libstdc++-v3/ChangeLog* libstdc++-v3/README 

core_HTML_FILES = boehm-gc/*.html INSTALL/*.html

core_INFO_FILES = cpp.info gcc.info cppinternals.info gcc.info gccinstall.info gccint.info libgomp.info libquadmath.info
ada_INFO_FILES = gnat-style.info gnat_rm.info gnat_ugn.info
fortran_INFO_FILES = gfortran.info

core_MAN_FILES = man1/cpp.1 man1/gcc.1 man1/gcov.1 man7/fsf-funding.7 man7/gfdl.7 man7/gpl.7
fortran_MAN_FILES = man1/gfortran.1
cpp_MAN_FILES = man1/g++.1

# If you want to copy the .exe files installed to $(PREFIX)/bin to also contain
# a $(HOST) prefix then set this variable to y or yes. E.G. If you want to copy
# bin/ld.exe to bin/$(HOST)-ld.exe then set this variable to y.
COPY_BIN_TO_HOST = y

# if you want to copy the include/, lib/ and libexec/ directories to a $(HOST)
# directory then set this variable to y or yes.  E.G. We need the mingwrt
# libraries in the $(HOST)/include and $(HOST)/lib to help with cross tooling so
# this variable is set to y.
COPY_LIB_TO_HOST = y


############################# This is a separator line, not part of package.ini


I have had no success building gcc 5.1.0. The MinGW 3.21 runtime
 introduced a new function which triggered a bug in the Fortran runtime
library. 

Keith Marshall suggested a fix for this, but I have not had time to apply it;
 Going back to a previous V3 runtime would work around that problem,
but it would probably not work around another problem that occurs when
 the Ada 5.1.0 runtime is built. I did another build with Fortran disabled,
and the build dropped dead when compiling the Ada run-time library.
Most of that library is written in Ada, but there are a few bits in C. Tne
5.1.0 Ada team seems to have decided to move into the 64-bit world
and getting the build to work with 32-bit  MinGW will require undoing
the 64-bit patches. I have not yet had time to work through the details.

It might be worth your time to focus on fixing the MinGW V4 runtime.
I have been planning to transplant the V3.21 code into the V4 build
structure, but I have not had time to work on it.

On 07/06/15 16:39, Eli Zaretskii wrote:
>>> Is the attached patch sufficient to
>>> address the "struct timespec" issue to your satisfaction?
>> 
>> Thanks a lot, I will try this as soon as I can.  It will probably be a
>> few days before I have an opportunity.
> 
> Tried it, and it looks good, thanks.  GDB builds without a hitch, and
> so does Emacs.

Thanks for testing.

> I think this is good to go.  I hope to see it soon in a MinGW runtime
> release near me.

The packages are up on FRS now, at:
https://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/mingwrt-3.21.1/

I still need to find time to do the mingw-get integration; I'll hold off
on a formal release announcement until that's done.

-- 
Regards,
Keith.