GetProcAdress can't find a symbol in a mingw generated library

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

GetProcAdress can't find a symbol in a mingw generated library

helferthomas
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
[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: GetProcAdress can't find a symbol in a mingw generated library

helferthomas
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: [hidden email]
À: [hidden email]
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
[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

------------------------------------------------------------------------------
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
[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: GetProcAdress can't find a symbol in a mingw generated library

Peter Rockett
On 29/06/15 17:12, [hidden email] 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: [hidden email]
> À: [hidden email]
> 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
> [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
>
> ------------------------------------------------------------------------------
> 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
> [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


------------------------------------------------------------------------------
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
[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: GetProcAdress can't find a symbol in a mingw generated library

helferthomas
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" <[hidden email]>
À: [hidden email]
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, [hidden email] 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: [hidden email]
> À: [hidden email]
> 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
> [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
>
> ------------------------------------------------------------------------------
> 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
> [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


------------------------------------------------------------------------------
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
[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

------------------------------------------------------------------------------
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
[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: GetProcAdress can't find a symbol in a mingw generated library

Robert Hartmann-2
Hi there,

I think the current max length for a valid exported name
could be documented somewehere in the
"Microsoft PE and COFF Specification":
https://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx


Am 30.06.2015 um 07:18 schrieb [hidden email]:

> 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]
[...long table ...]

If you want to be on the save side:
Your Names (classes, functions, variables, constants)
should differ - for correct export and valid distinction at import time
- in the first 8 characters.

Now I am quoting from:

http://blogs.msdn.com/b/oldnewthing/archive/2009/10/12/9905953.aspx

> [...] Given the classical model for linking, that's pretty much all
> the language specification could do. All that was shared between
> object modules was symbol names. And back in the old days, symbol
> names were restricted to a maximum of eight characters consisting of
> uppercase letters or digits.
>
> The C++ language came up with a workaround:
>
> They encoded the type information in the symbol name, a technique
> known as decoration. Your function which is named Resolve in the
> source code ends up with the name ?Resolve@@YG_NPAGI_N@Z in the
> object module, so that it can be matched up against the placeholders
> which ask for a function named ?Resolve@@YG_NPAGI_N@Z.
>
> The C++ language folks could get away with this because by the time
> the C++ language rolled around, the maximum length for a symbol was
> far greater than 8, and the repertoire of valid characters had grown
> significantly. And if you were one of the dinosaurs using an older
> system with the 8-character uppercase-only limitation, then you were
> just out of luck.
>
> But even the greater symbol name length doesn't solve all type
> mismatches. For example, symbols for structures and unions are not
> decorated with the members of the structure or union. You can have
> one C++ file declare a structure called S as
>
> struct S { int i; float f; };
>
> and have another C++ file declare it as
>
> struct S { float f; int i; };
>
> and most compilers won't catch the mismatch.
> [...]


Best regards,
Robert


------------------------------------------------------------------------------
_______________________________________________
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