#68148 closed defect (fixed)
libgit2 @1.7.1: builds fail with xcode clang 6 and earlier: error: unknown type name 'inline', from legacy-support header 'dirent.h'
| Reported by: | mascguy (Christopher Nielsen) | Owned by: | mascguy (Christopher Nielsen) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.8.1 |
| Keywords: | Cc: | cjones051073 (Chris Jones), catap (Kirill A. Korinsky) | |
| Port: | libgit2 |
Description (last modified by mascguy (Christopher Nielsen))
A recent addition to legacy-support added some functions declared inline, per PR:
However, upstream's project compiles with the C standard set to 90, which doesn't support keyword inline. Instead, compiling with C 99 or later is required.
In file included from .../libgit2/work/libgit2-1.7.1/src/util/unix/posix.h:13:
/opt/local/include/LegacySupport/dirent.h:60:8: error: unknown type name 'inline'
static inline struct dirent *__mpls_readdir(DIR *dir) {
^
Change History (10)
comment:1 Changed 8 months ago by mascguy (Christopher Nielsen)
| Description: | modified (diff) |
|---|
comment:2 follow-up: 3 Changed 8 months ago by mascguy (Christopher Nielsen)
comment:3 Changed 8 months ago by mascguy (Christopher Nielsen)
| Cc: | cjones051073 catap added |
|---|---|
| Summary: | libgit2 @1.7.1: builds fail with xcode clang 6 and earlier: error: unknown type name 'inline' → libgit2 @1.7.1: builds fail with xcode clang 6 and earlier: error: unknown type name 'inline', from legacy-support header 'dirent.h' |
Replying to mascguy:
Unfortunately blacklisting clang doesn't cut the mustard either. Do we need to patch the project's CMake files, and specify the C standard as 99? Or...?
Given that the failure relates to a header provided by legacy-support - which AFAIK, we haven't seen cause any such issues elsewhere - this is curious to be sure. (And I'm thinking it's the project specifying C 90 to Clang.) Particularly when libgit2-devel 1.7.1 built just fine three weeks ago, with legacy-support. And the latter's header - dirent.h - hasn't changed.
Fortunately this is only affecting 10.9 and earlier, so the fallout isn't as bad as it could be. Would still like to get it resolved ASAP though.
comment:4 Changed 8 months ago by Christopher Nielsen <mascguy@…>
comment:5 Changed 8 months ago by Christopher Nielsen <mascguy@…>
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:6 Changed 8 months ago by mascguy (Christopher Nielsen)
All good now, queued rebuilds for all dependent ports.
comment:7 Changed 8 months ago by jmroot (Joshua Root)
Replying to mascguy:
Despite the project setting the C standard to 90 - which should (?) be sufficient - builds are failing due to keyword 'inline':
There is no inline keyword in C89/90. It's available as a GNU extension if you use -std=gnu89, but has different semantics to what was eventually added in C99.
comment:8 follow-up: 9 Changed 8 months ago by jmroot (Joshua Root)
comment:9 Changed 8 months ago by mascguy (Christopher Nielsen)
| Description: | modified (diff) |
|---|
comment:10 Changed 8 months ago by mascguy (Christopher Nielsen)
Replying to jmroot:
In b7c964f912ecc7d86c462186cb768e0ea6acceda/macports-legacy-support (master):
Use __inline__ in public headers These may be included by C89 code where the inline keyword is not available.
Beautiful, thanks Josh!
Once a new version of legacy-support has been released, I'll revert the C 99 patch for libgit2.
Unfortunately blacklisting clang doesn't cut the mustard either. Do we need to patch the project's CMake files, and specify the C standard as 99? Or...?