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

Edward Diener eldlistmailingz at tropicsoft.com
Sun Aug 9 10:22:27 PDT 2015


On 8/9/2015 12:59 PM, Yaron Keren wrote:
> 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.

>
>
> 2015-08-09 19:33 GMT+03:00 Edward Diener <eldlistmailingz at tropicsoft.com
> <mailto:eldlistmailingz-5p0dqD/c5LGWd6l5hS35sQ at public.gmane.org>>:
>
>     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-5p0dqD/c5LGWd6l5hS35sQ at public.gmane.org
>         <mailto:eldlistmailingz-5p0dqD/c5LGWd6l5hS35sQ at public.gmane.org>
>         <mailto:eldlistmailingz-5p0dqD
>         <mailto:eldlistmailingz-5p0dqD>/c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg at public.gmane.org
>         <mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg 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-XMD5yJDbdMReXY1tMh2IBg at public.gmane.org
>         <mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg-XMD5yJDbdMReXY1tMh2IBg at public.gmane.org>
>                  <mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMSQIYZ4X
>         <mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMSQIYZ4X>/+iSw-XMD5yJDbdMReXY1tMh2IBh2eb7JE58TQ at public.gmane.org>
>                  <mailto:eldlistmailingz-5p0dqD
>         <mailto:eldlistmailingz-5p0dqD>
>                  <mailto:eldlistmailingz-5p0dqD
>         <mailto:eldlistmailingz-5p0dqD>>/c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg-XMD5yJDbdMReXY1tMh2IBg at public.gmane.org
>         <mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg-XMD5yJDbdMReXY1tMh2IBg at public.gmane.org>
>
>         <mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg-XMD5yJDbdMReXY1tMh2IBg at public.gmane.org
>         <mailto:c5LGWd6l5hS35sQ-XMD5yJDbdMReXY1tMh2IBg-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.
>                       _______________________________________________




More information about the cfe-dev mailing list