Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 735515 - libvirt doesn't compile under clang, because of configure hanging on btowc(0) check
Summary: libvirt doesn't compile under clang, because of configure hanging on btowc(0)...
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Eric Blake
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-02 21:15 UTC by Aleksander Balicki
Modified: 2011-09-03 02:57 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-09-03 02:55:31 UTC

Attachments (Terms of Use)

Description Aleksander Balicki 2011-09-02 21:15:17 UTC
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:

Comment 1 Eric Blake 2011-09-02 21:30:37 UTC
This sounds like a gnulib problem that will impact multiple source packages.  Can you please send email to bug-gnulib@gnu.org describing the issues, and give the details from the conversation on #llvm why you think it is a configure bug?

Comment 2 Aleksander Balicki 2011-09-02 21:50:32 UTC
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

Comment 3 Eric Blake 2011-09-02 21:55:28 UTC
Which versions of gcc and clang?  And can you send this to bug-gnulib@gnu.org?

Comment 4 Aleksander Balicki 2011-09-02 22:47:03 UTC
it was checked with clang-2.9 and trunk - the same effect

it compiles under gcc-4.4.5

Comment 5 Eric Blake 2011-09-03 02:55:16 UTC
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.

Comment 6 Eric Blake 2011-09-03 02:57:44 UTC
By the way, clang clang-2.8-12.fc14.x86_64 compiled things just fine for me on Fedora 14.

Note You need to log in before you can comment on or make changes to this bug.