<div dir="rtl"><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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 <a href="https://llvm.org/bugs">https://llvm.org/bugs</a>. You can also search there, the bug may be already reported.</div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div dir="ltr">2015-08-09 19:33 GMT+03:00 Edward Diener <span dir="ltr"><<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.com</a>></span>:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 8/8/2015 9:03 PM, Yaron Keren wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
See r244407 for a fuller patch with test case. It may also solve the<br>
other issues.<br>
If not, the best way to diagnose such problem is to run clang++ and g++<br>
with -v argument and the same pther arguments of the case, comparing<br>
both compiler outputs to see what's different.<br>
With this input we could patch the mingw toolchain.<br>
</blockquote>
<br></span>
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 !<br>
<br>
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 ?<br>
<br>
Onward to my original problem:<br>
<br>
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.<br>
<br>
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:<br>
<br>
"undefined reference to `typeinfo for ex_xml_exception'"<br>
<br>
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.<br>
<br>
Can someone look into this again and see if it can be fixed in clang on Windows targeting gcc ?<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
2015-08-08 22:37 GMT+03:00 Edward Diener <<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.com</a><br></span>
<mailto:<a href="mailto:eldlistmailingz-5p0dqD" target="_blank">eldlistmailingz-5p0dqD</a>/<a href="mailto:c5LGWd6l5hS35sQ@public.gmane.org" target="_blank">c5LGWd6l5hS35sQ@public.gmane.org</a>>>:<div><div class="h5"><br>
<br>
    On 8/8/2015 1:59 PM, Yaron Keren wrote:<br>
<br>
        I'm looking into this, see<br>
        <a href="https://llvm.org/bugs/show_bug.cgi?id=24395" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=24395</a><br>
        The solution is somewhat more compilcated but you can use the patch<br>
        there for now.<br>
<br>
<br>
    The patch solved the general problem I illustrated below. Thanks !<br>
<br>
    But for the example in my other posts, where an exception was being<br>
    thrown from a module using as a type a class that is in another DLL<br>
    that is being exported/imported, the attempt to link to that DLL now<br>
    fails with:<br>
<br>
    ex_exception.obj: In function `ex_exception':<br>
    ex_exception.cpp:42: undefined reference to `_Unwind_Resume'<br>
    ex_xml_exception.obj: In function `ex_xml_exception':<br>
    ex_xml_exception.cpp:32: undefined reference to `_Unwind_Resume'<br>
    ex_xml_exception.cpp:39: undefined reference to `_Unwind_Resume'<br>
    ex_xml_exception.cpp:42: undefined reference to `_Unwind_Resume'<br>
    clang++.exe: error: linker command failed with exit code 1 (use -v<br>
    to see invocation)<br>
<br>
    These error messages are exactly the same whether or not I attempt<br>
    to export/import the individual member functions of a visible class<br>
    or whether I attempt to export/import the class as a whole. At least<br>
    the previous error messages which occurred in the above situation<br>
    have disappeared <g>.<br>
<br>
    If you need for me to repeat the ex_exception, ex_xml_exception, and<br>
    throw_exception_ex source, with their command lines, in this post I<br>
    will be glad to do it.<br>
<br>
    Searching the web for "undefined reference to `_Unwind_Resume'"<br>
    yields various possibilities but none are definitive for this case<br>
    AFAICS.<br>
<br>
<br>
        2015-08-08 20:20 GMT+03:00 Edward Diener<br></div></div>
        <eldlistmailingz-5p0dqD/<a href="mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org" target="_blank">c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org</a><br>
        <mailto:<a href="mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMSQIYZ4X" target="_blank">c5LGWd6l5hS35sQ-XMD5yJDbdMSQIYZ4X</a>/+iSw@public.gmane.orgrg><br>
        <mailto:<a href="mailto:eldlistmailingz-5p0dqD" target="_blank">eldlistmailingz-5p0dqD</a><br>
        <mailto:<a href="mailto:eldlistmailingz-5p0dqD" target="_blank">eldlistmailingz-5p0dqD</a>>/<a href="mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org" target="_blank">c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org</a><br>
        <mailto:<a href="mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org" target="_blank">c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org</a>>>>:<div><div class="h5"><br>
<br>
<br>
             Some change in the latest source has completely broken<br>
        linking for<br>
             clang on Windows targeting gcc.<br>
<br>
             // ex_aclass.hpp<br>
<br>
             #ifndef EX_ACLASS_HPP<br>
             #define EX_ACLASS_HPP<br>
             #if defined(BLD_EX_EXAMPLE)<br>
                      #define EX_DECL __attribute__((__dllexport__))<br>
             #else<br>
                      #define EX_DECL __attribute__((__dllimport__))<br>
             #endif<br>
             class EX_DECL ex_aclass<br>
             {<br>
             public:<br>
                  int a_function(long);<br>
             };<br>
             #endif // EX_ACLASS_HPP<br>
<br>
             // ex_aclass.cpp<br>
<br>
             #define BLD_EX_EXAMPLE<br>
             #include "ex_aclass.hpp"<br>
             int ex_aclass::a_function(long amt)<br>
                      {<br>
                      return(amt > 1000000 ? 10 : 20);<br>
                      }<br>
<br>
             // Compile ex_aclass.cpp<br>
<br>
             clang++.exe -c -x c++ -D__MINGW_FORCE_SYS_INTRINS -O0 -g<br>
        -fno-inline<br>
             -Wall -g -march=i686 -m32 -o "ex_aclass.obj" "ex_aclass.cpp"<br>
<br>
             // Link into ex_ac.dll<br>
<br>
             clang++.exe" -o "ex_ac.dll" -Wl,-soname -Wl,ex_ac.dll -shared<br>
             -Wl,--start-group "ex_aclass.obj" -Wl,-Bstatic -Wl,-Bdynamic<br>
             -Wl,--end-group -g -march=i686 -m32<br>
<br>
<br>
        libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x1d6):<br>
             undefined reference to `__chkstk_ms'<br>
             clang++.exe: error: linker command failed with exit code 1<br>
        (use -v<br>
             to see invocation)<br>
<br>
             Nor does it matter what source file is used in general,<br>
        whenever the<br>
             link is done for anything the "undefined reference to<br>
        `__chkstk_ms'"<br>
             occurs.<br>
<br>
             Can some one of the clang developers please look at this ?<br>
<br>
             I am using clang on Windows with the 32-bit version of<br>
             mingw-64/gcc-5.1 as i686-5.1.0-posix-dwarf-rt_v4-rev0.<br>
<br>
             I realize the current problems for clang on Windows<br>
        targeting gcc<br>
             may have occurred trying to fix a more specific problem I<br>
        reported<br>
             in two other threads about linkage failure using dllexport and<br>
             dllimport attributes on Windows, but going from a situation<br>
        where a<br>
             specific problem broke the linking to all situations are<br>
        broken when<br>
             attempting to link is not good.<br>
<br>
             I tried looking at the clang unit tests and how they can be<br>
        run on<br>
             Windows but found very little information about both. I<br>
        wouldn't<br>
             mind contributing some basic unit tests, even though I am not a<br>
             clang developer, just to make sure that clang on Windows<br>
        targeting<br>
             gcc will work when compiling/linking dlls and using those<br>
        dlls from<br>
             another module, if I could understand what to do. That way<br>
        such a<br>
             snafu as this latest breakage would not occur so easily as<br>
        whatever<br>
             broke in the change should have been caught by some unit tests.<br>
             _______________________________________________<br>
</div></div></blockquote>
<br><div class="HOEnZb"><div class="h5">
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>