|Summary:||dev-libs/libgcrypt uses ugly inlining gcc hacks and doesn't compile with clang|
|Product:||Gentoo Linux||Reporter:||Michał Górny <mgorny>|
|Component:||[OLD] Library||Assignee:||Crypto team [DISABLED] <crypto+disabled>|
|Severity:||normal||CC:||alonbl, ComputerDruid, ryao|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
|Bug Blocks:||297436, 417789|
The build log
Description Michał Górny 2012-06-12 21:40:30 UTC
Created attachment 315143 [details] The build log Long story short: upstream first declares regular prototypes for functions, then 'extern __inline__' ones which simply doesn't conform to any kind of C standard I can think of, and it's a miracle gcc eats this somehow. I'll attach patch which seems to be the best course of action. It removes the pointless 'extern', and uses 'inline' in both the prototype and the declaration. This is the correct way of doing that, and should work both with and without the inline bodys. Also, configure uses AC_C_INLINE, so no reason to use __inline__. I wanted to report this directly to upstream but I'm still waiting for the registration e-mail.
Comment 1 Michał Górny 2012-06-12 21:40:56 UTC
Created attachment 315147 [details, diff] Suggested patch
Comment 2 Richard Yao 2012-06-13 19:39:11 UTC
This patch enables us to build with Clang, but it causes a build failure when we build with GCC.
Comment 3 Michał Górny 2012-06-13 20:23:35 UTC
Comment on attachment 315147 [details, diff] Suggested patch Then the only solution I see is appending '-std=gnu89' to CFLAGS.
Comment 4 Johan Bergström 2012-12-05 04:59:00 UTC
Just stumbled in here. Seems like upstream states that it's fixed. Mgorny?
Comment 5 Michał Górny 2012-12-05 08:56:36 UTC
(In reply to comment #4) > Just stumbled in here. Seems like upstream states that it's fixed. Mgorny? I can reproduce it with 1.5.0-r4 but maybe upstream referred to a newer version.
Comment 6 Dan Johnson 2013-05-29 21:33:47 UTC
I too have just stumbled across this bug > I can reproduce it with 1.5.0-r4 but maybe upstream referred to a newer version. Apparently so; libgcrypt-1.5.2 seems to build fine with clang-3.2 (and passes tests) So this bug can probably be closed.