Summary: | app-text/recode fails to compile with sys-devel/clang-3.2 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | Gentoo Shell Tools project <shell-tools> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | fsvm88, hendrik, wizardedit |
Priority: | Low | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 408963 | ||
Attachments: |
build.log
Add "static" to aliases_lookup function declaration. |
Description
Agostino Sarubbo
2013-03-23 16:47:29 UTC
Created attachment 343006 [details]
build.log
build log
It is reproducible, but I can't find an easy solution. Patches welcome. The problem is in libiconv/aliases.h:69: #ifdef __GNUC__ __inline #endif const struct alias * aliases_lookup (register const char *str, register unsigned int len) The code part there leads to inlining under gcc. If the code doesn't get inlined (like in clang) the header just get's included in iconv.c, but not compiled. With C99 inline would be standarized and work. __inline would work in clang, too. (In reply to comment #3) > The problem is in libiconv/aliases.h:69: > > #ifdef __GNUC__ > __inline > #endif > const struct alias * > aliases_lookup (register const char *str, register unsigned int len) > > The code part there leads to inlining under gcc. If the code doesn't get > inlined (like in clang) the header just get's included in iconv.c, but not > compiled. With C99 inline would be standarized and work. __inline would work > in clang, too. That means?? Hwo to fix that? Still in clang-3.3 Created attachment 382672 [details, diff] Add "static" to aliases_lookup function declaration. Fixes the compilation by adding the "static" keyword to the aliases_lookup function. The purpose of the functions contained in libiconv/aliases.h seems to be of always being inlined no matter what. Changing from C89 to C99 changes the semantics of the "inline" keyword according to the clang website. I have tried using inline, __inline, __gnu_inline__ all to no avail. Adding "static" allows the compilation to continue. In practice "static" hides the symbols from the linker, which become only visible only by the translation unit being compiled and can be then optimized away (which, reading the code, seems to be the original intention). More reading here: http://stackoverflow.com/questions/5319361/static-function-in-c Tests pass fine both with clang-3.4.2 and gcc-4.8.3. The patch still applies for recode-3.6_p20 compiled with clang-3.5.0. Applying the patch makes recode compile and pass tests. app-text/recode-3.6_p20-r1 seems to build fine without the static patch with clang 3.7.1, but I can't find any info on changes to how clang handles __inline (In reply to Valeriy Malov from comment #8) > app-text/recode-3.6_p20-r1 seems to build fine without the static patch with > clang 3.7.1, but I can't find any info on changes to how clang handles > __inline clang 3.5 also works, so it may not be a clang change. Unfortunately the previous ebuild is not in git, so I can't easily see what app-text/recode-3.6_p20.ebuild did differently. Anyway, WORKSFORME. Agostino, can you retry? (In reply to Austin English from comment #9) > (In reply to Valeriy Malov from comment #8) > > app-text/recode-3.6_p20-r1 seems to build fine without the static patch with > > clang 3.7.1, but I can't find any info on changes to how clang handles > > __inline > > clang 3.5 also works, so it may not be a clang change. Unfortunately the > previous ebuild is not in git, so I can't easily see what > app-text/recode-3.6_p20.ebuild did differently. > > Anyway, WORKSFORME. Agostino, can you retry? If the current recode works with the current clang feel free to close.. tested. works for me. |