<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - clang and mingw disagree about dllexported classes"
href="http://llvm.org/bugs/show_bug.cgi?id=21366">21366</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>clang and mingw disagree about dllexported classes
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>yaron.keren@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>hans@chromium.org, llvmbugs@cs.uiuc.edu, nico.rieck@gmail.com, rnk@google.com
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Hi,
A very common code pattern dllexports a class in the dll and dllimports in the
client.
The code
class __declspec(dllexport) c {
public:
void a() { }
void b();
};
void c::b() { }
compiled with -shared, gcc version 4.9.1 (i686-posix-dwarf-rev1cee, Built by
MinGW-W64 project) exports c::b() only, whereas clang export c::a(), c::b() and
c() copy-constructor.
The trouble starts on the client side, after replacing dllexport with
dllimport. gcc will instantiate c::a() as inline (not exported from dll) while
clang will expect c::a() from the dll. So clang can not use mingw-compiled dlls
with the above code pattern since they all the inline functions are missing.
I have tried to workaround this with gcc -fkeep-inline-functions and
-fkeep-inline-dllexport but no change, only c::b() is exported.
Marking c::a() specifically
__declspec(dllexport) void a() { }
will cause it to be exported, unfortuntely there are large libraries such as
VTK, ITK which exports the class but not its members.
clang behaviour follows design:
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130701/180076.html">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130701/180076.html</a>
gcc mingw had a related performance bug report which was fixed in in 4.8.1:
<a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892</a>
and discussion
<a href="https://sourceforge.net/p/mingw-w64/mailman/message/31059727/">https://sourceforge.net/p/mingw-w64/mailman/message/31059727/</a>
as far as I understand the issue this change solved the performance problem
(inlined dllexported functions) but not exporting them, thus gcc is
incompatible with the linked MS article
<a href="http://msdn.microsoft.com/en-us/library/xa0d9ste.aspx">http://msdn.microsoft.com/en-us/library/xa0d9ste.aspx</a>
"You can define as inline a function with the dllexport attribute. In this
case, the function is always instantiated and exported, whether or not any
module in the program references the function. The function is presumed to be
imported by another program."
which clang still follows.
Anyhow, this is a real obstacle to using clang with mingw compiled dlls.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>