[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] Linker error and obfuscated name
From: Reid Kleckner <rnk () google ! com>
Date: 2015-08-03 21:50:13
Message-ID: CACs=tyLxgp_ovgFBsHM6HHQHYBZxoYuvb-LCEQuJ_AncTm+i3A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Aug 3, 2015 at 11:32 AM, Edward Diener <
eldlistmailingz@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@tropicsoft.com
>> <mailto:eldlistmailingz@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.
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.
The source you provided uses the visibility attribute, though, so I wonder
if mingw does something with that.
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 3, 2015 \
at 11:32 AM, Edward Diener <span dir="ltr"><<a \
href="mailto:eldlistmailingz@tropicsoft.com" \
target="_blank">eldlistmailingz@tropicsoft.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On 8/3/2015 1:45 PM, Reid Kleckner wrote:<br> \
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class=""> On Mon, Aug 3, 2015 at 9:56 AM, Edward \
Diener<br> <<a href="mailto:eldlistmailingz@tropicsoft.com" \
target="_blank">eldlistmailingz@tropicsoft.com</a><br></span><span class=""> \
<mailto:<a href="mailto:eldlistmailingz@tropicsoft.com" \
target="_blank">eldlistmailingz@tropicsoft.com</a>>> wrote:<br> <br>
// ex_exception.hpp<br>
<br>
#ifndef EX_EXCEPTION_HPP<br>
#define EX_EXCEPTION_HPP<br>
#include <exception><br>
#include "ex_decl.hpp"<br>
class EX_VISIBLE ex_exception :<br>
<br>
<br>
I think this class should probably be dllexported. It's possible that<br>
mingw looks at class visibility as well as dllexport attributes when<br>
deciding whether or not to expor tthe RTTI for classes, but I'm pretty<br>
sure clang doesn't. We could add that check for compatibility. Is there<br>
a compelling reason to not use dllexport on the entire class here?<br>
</span></blockquote>
<br>
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.<br> <br>
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.</blockquote><div><br></div><div>Clang supports \
importing and exporting individual members. That should already \
work.</div><div><br></div><div>The problem is that we need a way to export the \
runtime type information (RTTI). That's why the linker is talking about \
"<span style="font-size:12.8000001907349px">typeinfo for ex_xml_exception". \
</span>Right now they only way to do that is to export the whole class, rather than \
individual members.</div><div><br></div><div>The source you provided uses the \
visibility attribute, though, so I wonder if mingw does something with \
that.</div></div></div></div>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic