[LLVMbugs] [Bug 21366] New: clang and mingw disagree about dllexported classes

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=21366

            Bug ID: 21366
           Summary: clang and mingw disagree about dllexported classes
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: yaron.keren at gmail.com
                CC: hans at chromium.org, llvmbugs at cs.uiuc.edu,
                    nico.rieck at gmail.com, rnk at google.com
    Classification: Unclassified

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:


http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130701/180076.html

gcc mingw had a related performance bug report which was fixed in in 4.8.1:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892

and discussion

 https://sourceforge.net/p/mingw-w64/mailman/message/31059727/

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

 http://msdn.microsoft.com/en-us/library/xa0d9ste.aspx

"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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141024/63a62161/attachment.html>