Description of problem: libvirt doesn't compile under clang it doesn't even finish configure it hangs forever on the btowc(0) check on gcc it goes thru after conversation on #llvm got info, that's probably the fault of configure abusing inline. Version-Release number of selected component (if applicable): 0.9.{3,4} How reproducible: always Steps to Reproduce: 1.compile on gentoo USE=virt-network CC=clang CXX=clang++ emerge -1 libvirt Actual results: hangs on the line: checking btowc(0) Expected results: go thru with configure and compilation Additional info:
This sounds like a gnulib problem that will impact multiple source packages. Can you please send email to bug-gnulib describing the issues, and give the details from the conversation on #llvm why you think it is a configure bug?
19:10:35 alistra_> i have another gcc/clang mismatch, libvirt-0.9.{3,4} hangs on configure on the line checking whether btowc(0) is correct... 19:10:56 alistra_> clang hangs and gcc goes thru 19:11:33 echristo> yeah, it's a wonky configure program that abuses inline sorry for the compactness, but it's the only info i got
Which versions of gcc and clang? And can you send this to bug-gnulib?
it was checked with clang-2.9 and trunk - the same effect it compiles under gcc-4.4.5
According to the gnulib folks [1], this is either a bug in the glibc header for using non-portable __asm and expecting non-gcc to understand it, or a bug in clang for pretending to be gcc but not understanding __asm in the same was as gcc. There is nothing libvirt can do about either of those situations, so I'm closing this bug as CANTFIX. [1] https://lists.gnu.org/archive/html/bug-gnulib/2011-09/msg00027.html > I guess that clang hangs or produces an endless loop because of > this inline definition in <wchar.h>: > > extern wint_t __btowc_alias (int __c) __asm ("btowc"); > __extern_inline wint_t > __NTH (btowc (int __c)) > { return (__builtin_constant_p (__c) && __c >= '\0' && __c <= '\x7f' > ? (wint_t) __c : __btowc_alias (__c)); } > > Evidently, clang gives a different semantics to __asm than GCC. > But GCC's semantics of __asm is fixed for 20 years. > > Conclusion: Needs to be fixed in clang.
By the way, clang clang-2.8-12.fc14.x86_64 compiled things just fine for me on Fedora 14.