[cfe-dev] Latest clang from source breaks clang on Windows targeting gcc linking
Edward Diener
eldlistmailingz at tropicsoft.com
Sun Aug 9 17:02:06 PDT 2015
On 8/9/2015 1:22 PM, Edward Diener wrote:
> 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.
Bug report is at https://llvm.org/bugs/show_bug.cgi?id=24409 .
>
>>
>>
>> 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