Latest clang from source breaks clang on Windows targeting gcc linking

Clang Frontend
1

Some change in the latest source has completely broken linking for clang on Windows targeting gcc.

// ex_aclass.hpp

#ifndef EX_ACLASS_HPP
#define EX_ACLASS_HPP
#if defined(BLD_EX_EXAMPLE)
         #define EX_DECL __attribute__((__dllexport__))
#else
  #define EX_DECL __attribute__((__dllimport__))
#endif
class EX_DECL ex_aclass
{
public:
     int a_function(long);
};
#endif // EX_ACLASS_HPP

// ex_aclass.cpp

#define BLD_EX_EXAMPLE
#include "ex_aclass.hpp"
int ex_aclass::a_function(long amt)
  {
  return(amt > 1000000 ? 10 : 20);
  }

// Compile ex_aclass.cpp

clang++.exe -c -x c++ -D__MINGW_FORCE_SYS_INTRINS -O0 -g -fno-inline -Wall -g -march=i686 -m32 -o "ex_aclass.obj" "ex_aclass.cpp"

// Link into ex_ac.dll

clang++.exe" -o "ex_ac.dll" -Wl,-soname -Wl,ex_ac.dll -shared -Wl,--start-group "ex_aclass.obj" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g -march=i686 -m32

libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x1d6): undefined reference to `__chkstk_ms'
clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation)

Nor does it matter what source file is used in general, whenever the link is done for anything the "undefined reference to `__chkstk_ms'" occurs.

Can some one of the clang developers please look at this ?

I am using clang on Windows with the 32-bit version of mingw-64/gcc-5.1 as i686-5.1.0-posix-dwarf-rt_v4-rev0.

I realize the current problems for clang on Windows targeting gcc may have occurred trying to fix a more specific problem I reported in two other threads about linkage failure using dllexport and dllimport attributes on Windows, but going from a situation where a specific problem broke the linking to all situations are broken when attempting to link is not good.

I tried looking at the clang unit tests and how they can be run on Windows but found very little information about both. I wouldn't mind contributing some basic unit tests, even though I am not a clang developer, just to make sure that clang on Windows targeting gcc will work when compiling/linking dlls and using those dlls from another module, if I could understand what to do. That way such a snafu as this latest breakage would not occur so easily as whatever broke in the change should have been caught by some unit tests.

2

I’m looking into this, see https://llvm.org/bugs/show_bug.cgi?id=24395
The solution is somewhat more compilcated but you can use the patch there for now.

3

I'm looking into this, see 24395 – (mingw) undefined reference to `__chkstk_ms'
The solution is somewhat more compilcated but you can use the patch
there for now.

The patch solved the general problem I illustrated below. Thanks !

But for the example in my other posts, where an exception was being thrown from a module using as a type a class that is in another DLL that is being exported/imported, the attempt to link to that DLL now fails with:

ex_exception.obj: In function `ex_exception':
ex_exception.cpp:42: undefined reference to `_Unwind_Resume'
ex_xml_exception.obj: In function `ex_xml_exception':
ex_xml_exception.cpp:32: undefined reference to `_Unwind_Resume'
ex_xml_exception.cpp:39: undefined reference to `_Unwind_Resume'
ex_xml_exception.cpp:42: undefined reference to `_Unwind_Resume'
clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation)

These error messages are exactly the same whether or not I attempt to export/import the individual member functions of a visible class or whether I attempt to export/import the class as a whole. At least the previous error messages which occurred in the above situation have disappeared <g>.

If you need for me to repeat the ex_exception, ex_xml_exception, and throw_exception_ex source, with their command lines, in this post I will be glad to do it.

Searching the web for "undefined reference to `_Unwind_Resume'" yields various possibilities but none are definitive for this case AFAICS.

4

See r244407 for a fuller patch with test case. It may also solve the other issues.
If not, the best way to diagnose such problem is to run clang++ and g++ with -v argument and the same pther arguments of the case, comparing both compiler outputs to see what’s different.
With this input we could patch the mingw toolchain.

5

See r244407 for a fuller patch with test case. It may also solve the
other issues.
If not, the best way to diagnose such problem is to run clang++ and g++
with -v argument and the same pther arguments of the case, comparing
both compiler outputs to see what's different.
With this input we could patch the mingw toolchain.

I removed the patch you pointed me to earlier in this thread and downloaded and built the latest llvm/clang. Now when I compile/link with clang I get neither the "undefined reference to `__chkstk_ms'" error or the "undefined reference to `_Unwind_Resume'" error. Those errors may have been caused by my building clang with a different version of gcc than the one I use for RTL when I run clang, or may have been fixed by the latest clang changes in source, but whatever the reason those errors no longer occur. Hooray !

This leads me to the general question: if I build llvm/clang with a particular version of mingw(-64)/gcc on Windows is it an error if I use another version of mingw(-64)/gcc on Windows RTL when I compile/link with clang ?

Onward to my original problem:

If I compile/link by exporting a class as a whole and then import the class as a whole, when linking with that DLL, everything works fine.

If I compile/link by exporting individual member functions of a visible class, when I try to import those same individual member functions when linking with that DLL I still get an error of the form:

"undefined reference to `typeinfo for ex_xml_exception'"

where ex_xml_exception is the class I am using as a whole in throwing a C++ exception. So it appears that exporting/importing individual member functions of a class is still not exporting/importing the typeinfo information of the class as a whole.

Can someone look into this again and see if it can be fixed in clang on Windows targeting gcc ?

The main reason I am trying to get clang on Windows working this way is that I am trying to get the latest build of Boost serialization working with the latest clang, and the latest design of Boost serialization ( I am not the designer ) is to export/import only the individual member of a class rather than the class as a whole.

6

The compiler used to build clang and the target compiler are independent. I usually use Visual C++ to build clang in x64 but target mingw-w64 in x86. Other people are using clang as cross compiler, building WIndows executables on Linux.

As for other issues, it’s best to create a small minimal example that builds with the mingw gcc toolchain but fails when gcc is replaced with latest clang and report this as a bug in https://llvm.org/bugs. You can also search there, the bug may be already reported.

7

The compiler used to build clang and the target compiler are
independent. I usually use Visual C++ to build clang in x64 but target
mingw-w64 in x86. Other people are using clang as cross compiler,
building WIndows executables on Linux.

As for other issues, it's best to create a small minimal example that
builds with the mingw gcc toolchain but fails when gcc is replaced with
latest clang and report this as a bug in https://llvm.org/bugs. You can
also search there, the bug may be already reported.

See my original thread entitled:

"Linker error and obfuscated name"

for the small minimal example, if you are interested. It is what has started this back-and-forth through three messages to try to get clang to work linking when an exception of a class with exported member functions is thrown.

Nonetheless I will just report this to the bugs list above as you have suggested.

8

The compiler used to build clang and the target compiler are
independent. I usually use Visual C++ to build clang in x64 but target
mingw-w64 in x86. Other people are using clang as cross compiler,
building WIndows executables on Linux.

As for other issues, it's best to create a small minimal example that
builds with the mingw gcc toolchain but fails when gcc is replaced with
latest clang and report this as a bug in https://llvm.org/bugs. You can
also search there, the bug may be already reported.

See my original thread entitled:

"Linker error and obfuscated name"

for the small minimal example, if you are interested. It is what has
started this back-and-forth through three messages to try to get clang
to work linking when an exception of a class with exported member
functions is thrown.

Nonetheless I will just report this to the bugs list above as you have
suggested.

Bug report is at 24409 – Linker error on Clang on Windows targeting gcc when exporting individual member functions .