[cfe-dev] Latest clang from source breaks clang on Windows targeting gcc linking

Yaron Keren yaron.keren at gmail.com
Sun Aug 9 09:59:49 PDT 2015


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.


2015-08-09 19:33 GMT+03:00 Edward Diener <eldlistmailingz at tropicsoft.com>:

> On 8/8/2015 9:03 PM, Yaron Keren wrote:
>
>> 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.
>
>
>>
>> 2015-08-08 22:37 GMT+03:00 Edward Diener <eldlistmailingz at tropicsoft.com
>> <mailto:eldlistmailingz-5p0dqD/c5LGWd6l5hS35sQ at public.gmane.org>>:
>>
>>
>>     On 8/8/2015 1:59 PM, Yaron Keren wrote:
>>
>>         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.
>>
>>
>>     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.
>>
>>
>>         2015-08-08 20:20 GMT+03:00 Edward Diener
>>         <eldlistmailingz-5p0dqD/
>> c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg at public.gmane.org
>>         <mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMSQIYZ4X/+iSw at public.gmane.orgrg
>> >
>>         <mailto:eldlistmailingz-5p0dqD
>>         <mailto:eldlistmailingz-5p0dqD>/
>> c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg at public.gmane.org
>>         <mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg at public.gmane.org
>> >>>:
>>
>>
>>
>>              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.
>>              _______________________________________________
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150809/bae074d1/attachment.html>


More information about the cfe-dev mailing list