2016-04-02 16:48 GMT+02:00 Earnie <ear...@users.sourceforge.net>: > On 4/1/2016 12:55 PM, Tony Kelman wrote: >> Kai Tietz <ktietz70@...> writes: >> >>> So I am wondering a bit, what you actual mean here? I guessed first >>> that you were referring to the auto-import feature of ld. As this >>> feature indeed make it unnecessary to specify dllimport attribute on >>> an external symbol. So could you please describe your issue a bit >>> more detailed. >>> >>> Thanks, >>> Kai >> >> Let me try to describe more specifically. If in foo.h, you do not mark >> a function with dllexport, but you do mark the implementation in foo.c >> with dllexport, GCC will compile that and it will work, but MSVC and >> Clang will error. When people make changes deciding a function needs >> to now be exported and make that change by adding the dllexport to the >> implementation, our continuous integration tests that use MinGW-w64 >> show that as working. What I'm asking is whether GCC can be told to >> behave more like MSVC and Clang in this respect, causing an error when >> the header does not have dllexport but the implementation does. Make >> sense?
Yes, this behavior is a gcc "feature". Its behavior has to do with the way such attributes getting applied and being verified. What gcc has to allow is the case that implementation isn't marked by dllexport, but the declaration is. So for your case it looks to me worth to discuss to add a warning option as feature request. That we allow such things in gcc has more historical reasons, which are mainly linked to emulating linux behavior. As for such cases the headers don't have any specific import/export markings. Cygwin/msys would be in serious troubles, if such features as auto-import wouldn't exist. > This has often bugged me as well. It my google I found > https://gcc.gnu.org/wiki/Visibility which has some interesting points The concecpt of visibility is nothing, which applies to pe-coff very well. So referring to it is misleading. > but doesn't directly address this issue. Right. > The mismatch of the header > from the function being used should at least issue a warning but I would > prefer to see an error. The ld auto-import feature just exacerbates the > issue and when it was invented I wished for it to go away. The idea > behind this was for ease of porting between the various systems without > needing to change the attributes of symbols or in other words a lazy > porting method. Well, as point out above, "lazy" porting method is for sure the wrong term. It is a strong requirement for letting work all flavours of the Cygwin environment. As pointed out above. An optional warning option for this m Kai ------------------------------------------------------------------------------ _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
