On Fri, 25 Apr 2025, Takashi Yano via Cygwin-apps wrote: > On Thu, 24 Apr 2025 10:06:05 -0700 (PDT) > Jeremy Drake wrote: > > On Thu, 24 Apr 2025, Takashi Yano via Cygwin-apps wrote: > > > > > Hi Jeremy, > > > > > > On Tue, 22 Apr 2025 15:50:52 +0900 > > > To avoid this incompatibility, I tried to build llvm/clang without > > > both 0005-use_cxx11_abi.patch and 0110-use_cxx11_abi.patch, and add > > > -DCMAKE_CXX_STANDARD=20 > > > instead. It makes llvm/clang be built successfully. > > > > > > Then, the linkage between objects compiled by g++ and clang++ succeeded. > > > $ g++ -c b.cc -o b.o > > > $ clang++ -std=c++14 -c a.cc -o a.o > > > $ clang++ a.o b.o > > > $ ./a.exe > > > Received string: Processed: Hello, World! > > > $ > > > > > > Without -std=c++14, an error occurs in linking. > > > > > > I also tested dll like: > > > $ g++ -shared b.cc -o b.dll > > > $ clang++ -c a.cc -o a.o > > > $ clang++ a.o b.dll > > > $ ./a.exe > > > Received string: Processed: Hello, World! > > > $ > > > and it scceeded as well. > > > > > > Isn't this better than mixed ABI problem, is it? > > > > > > I'm still not sure why the llvm-min-tblgen.exe crashes, so > > > there may be still have problems even with this hack. > > > > https://github.com/llvm/llvm-project/issues/135910 > > Thanks! > https://github.com/llvm/llvm-project/issues/135910#issuecomment-2822518681 > is very helpfull to understand what is happening. > > Then, the following error should be due to the same problem: > $ g++ -c b.cc -o b.o > $ clang++ -c a.cc -o a.o > $ clang++ a.o b.o > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: > b.o:b.cc:(.text$_ZNSt11char_traitsIcE6lengthEPKc[_ZNSt11char_traitsIcE6lengthEPKc]+0x0): > multiple definition of `std::char_traits<char>::length(char const*)'; > a.o:a.cc:(.text[_ZNSt11char_traitsIcE6lengthEPKc]+0x0): first defined here > collect2: error: ld returned 1 exit status > clang++: error: linker (via gcc) command failed with exit code 1 (use -v to > see invocation) > $ > > Right?
No, I think that's something different. It has a little bit of familiarity with something that was seen on MinGW, that 'duplicate' definitions like that should be folded at link, but cannot be because they are not entirely duplicate (they differ between what clang generated and what gcc generated). The familiarity comes in that one or the other compiler put a "same size" restriction on the duplicate folding attribute. Martin probably knows better. If it is that you should be able to see something in the -S output between the two.
