https://llvm.org/bugs/show_bug.cgi?id=25477
Bug ID: 25477
Summary: Clang forms weak external COFF aliases to base class
destructors which fail to link
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: r...@google.com
CC: david.majne...@gmail.com, llvm-bugs@lists.llvm.org,
rafael.espind...@gmail.com
Classification: Unclassified
Consider:
$ cat t.cpp
struct A {
virtual ~A();
};
template <typename T> struct B : A {
virtual ~B() {}
};
#ifdef CONFIG1
A::~A() {}
template struct B<int>;
#else
extern template struct B<int>;
int main() { B<int> b; }
#endif
$ clang-cl -O1 t.cpp -DCONFIG1 -c -Fot1.obj
$ clang-cl t.cpp -Fot2.obj -c
$ link t1.obj t2.obj -out:t.exe
Microsoft (R) Incremental Linker Version 12.00.31101.0
Copyright (C) Microsoft Corporation. All rights reserved.
t1.obj : error LNK2001: unresolved external symbol "public: virtual __cdecl
B<int>::~B<int>(void)" (??1?$B@H@@UEAA@XZ)
t2.obj : error LNK2001: unresolved external symbol "public: virtual __cdecl
B<int>::~B<int>(void)" (??1?$B@H@@UEAA@XZ)
t.exe : fatal error LNK1120: 1 unresolved externals
So, the Microsoft linker does not appear to work the way we think it does with
regard to weak externals. I reduced this from STLPort, which uses extern
template instantiations like these for basic_ios.
I guess I'll change this stuff that looks for dllexport to look for COFF
instead:
// Don't create a weak alias for a dllexport'd symbol.
if (AliasDecl.getDecl()->hasAttr<DLLExportAttr>() &&
llvm::GlobalValue::isWeakForLinker(Linkage))
return true;
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
