[cfe-dev] Linker error and obfuscated name

[Edward Diener]

On 8/3/2015 5:50 PM, Reid Kleckner wrote:
> On Mon, Aug 3, 2015 at 11:32 AM, Edward Diener
> <eldlistmailingz at tropicsoft.com
> <mailto:eldlistmailingz at tropicsoft.com>> wrote:
>
>     On 8/3/2015 1:45 PM, Reid Kleckner wrote:
>
>         On Mon, Aug 3, 2015 at 9:56 AM, Edward Diener
>         <eldlistmailingz at tropicsoft.com
>         <mailto:eldlistmailingz at tropicsoft.com>
>         <mailto:eldlistmailingz at tropicsoft.com
>         <mailto:eldlistmailingz at tropicsoft.com>>>
>         wrote:
>
>              // ex_exception.hpp
>
>              #ifndef EX_EXCEPTION_HPP
>              #define EX_EXCEPTION_HPP
>              #include <exception>
>              #include "ex_decl.hpp"
>              class EX_VISIBLE ex_exception :
>
>
>         I think this class should probably be dllexported. It's possible
>         that
>         mingw looks at class visibility as well as dllexport attributes when
>         deciding whether or not to expor tthe RTTI for classes, but I'm
>         pretty
>         sure clang doesn't. We could add that check for compatibility.
>         Is there
>         a compelling reason to not use dllexport on the entire class here?
>
>
>     This is a simple example of a much more complicated problem in the
>     Boost serialization library and its source build on Windows. I had
>     made changes to get mingw(-64)/gcc to build correctly but have run
>     into this clang problem. In essence Boost serialization on Windows
>     exports individual member functions rather than entire classes. I
>     doubt I am going to get the author of the library to change this,
>     but I will mention to him the clang limitation and maybe he can do it.
>
>     If you make the change in clang to allow individual member functions
>     to be exported/imported for visible classes that would be much
>     better  IMO. But past versions of clang on Windows still have this
>     limitation vis-a-vis the Boost serialization library. I do not know
>     if other Boost libraries which are non-header only use the same
>     technique of exporting/importing individual member functions of
>     visible classes on Windows. If they do then clang on Windows
>     targeting mingw(-64)/gcc will not work with them either.
>
>
> Clang supports importing and exporting individual members. That should
> already work.

That's good.

>
> The problem is that we need a way to export the runtime type information
> (RTTI). That's why the linker is talking about "typeinfo for
> ex_xml_exception". Right now they only way to do that is to export the
> whole class, rather than individual members.

Then importing and exporting individual members works only for what ? 
Classes that are not importing/exporting virtual functions ? Is this 
where the RTTI information being exported comes in ?

>
> The source you provided uses the visibility attribute, though, so I
> wonder if mingw does something with that.

I don't know but I can tell you I had similar problems getting mingw/gcc 
to work. It seems that it did not work until I explicitly 
exported/imported all virtual functions of the classes I presented, 
including the virtual destructors, as well as explicitly 
exported/imported any compiler generated functions which were going to 
be used across DLL boundaries, such as the individual copy constructors. 
Still I am not absolutely sure exactly what the rules were for mingw/gcc 
since I could never get a specific answer from them on the mingw-64 
mailing list regarding this, although I did get some help from them. 
Maybe I should have addressed these concerns on the gcc mailing list 
instead.

>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>