Skip to content

Fix libbsd's cdefs.h to be compatible with gcc 4.8.x#4979

Merged
adamjstewart merged 2 commits intospack:developfrom
hartzell:libbsd-cdefs-fix
Aug 5, 2017
Merged

Fix libbsd's cdefs.h to be compatible with gcc 4.8.x#4979
adamjstewart merged 2 commits intospack:developfrom
hartzell:libbsd-cdefs-fix

Conversation

@hartzell
Copy link
Copy Markdown
Contributor

@hartzell hartzell commented Aug 4, 2017

See the discussion in #4945 (after the merge) for additional background.

libbsd builds with [email protected] on CentOS 7, but not with the system's [email protected]. Others have reported problems with [email protected] on Fedora 19.

The problem boils down to the lack of support for the clang extension __has_include_next. The immediate symptom seems to be the pre-processor using defining macro like this

#define __has_include 1

then then tripping over an expansion of it like this:

blah.h:13:23: error: missing binary operator before token "("

This patch changes the macro definition to:

#define __has_include(X) 1

which swallows the arguments with which the macro is invoked.

The end result is that libbsd builds for me on CentOS 7 using the system compiler.

I'm unsure about how to constrain the compiler version, this is the only system I have at hand to test.

See the discussion in spack#4945 (after the merge) for additional
background.

libbsd builds with [email protected] on CentOS 7, but not with the system's
[email protected].  Others have reported problems with [email protected] on Fedora 19.

The problem boils down to the lack of support for the clang extension
`__has_include_next`.  The immediate symptom seems to be the
pre-processor using defining macro like this

```
```

then then tripping over an expansion of it like this:

```
blah.h:13:23: error: missing binary operator before token "("
```

This patch changes the macro definition to:

```
```

which swallows the arguments with which the macro is invoked.

The end result is that libbsd builds for me on CentOS 7 using the
system compiler.
@hartzell hartzell changed the title Fix cdefs macro to be compatible with gcc 4.8.x Fix libbsd's cdefs.h to be compatible with gcc 4.8.x Aug 5, 2017
@hartzell
Copy link
Copy Markdown
Contributor Author

hartzell commented Aug 5, 2017

@jgalarowicz -- can you see if this branch (hartzell:libbsd-cdefs-fix) builds on your Fedora 19 system w/ [email protected]?

@adamjstewart
Copy link
Copy Markdown
Member

adamjstewart commented Aug 5, 2017

I'm unsure about how to constrain the compiler version, this is the only system I have at hand to test.

According to the GCC 5 Changelog, changes to the C/C++ compilers include:

New preprocessor constructs, __has_include and __has_include_next, to test the availability of headers have been added.

So I would constrain the patch like so:

patch('cdefs.h.patch', when='%gcc@:4')

This includes subversions of 4, like 4.8.5.
@hartzell
Copy link
Copy Markdown
Contributor Author

hartzell commented Aug 5, 2017

I didn't realize this:

Version ranges can be open, e.g. :3 means any version up to and including 3. This would include 3.4 and 3.4.2.

From the spack docs

Thanks!

@adamjstewart adamjstewart merged commit ab0ea3c into spack:develop Aug 5, 2017
@hartzell hartzell deleted the libbsd-cdefs-fix branch August 5, 2017 18:59
@jgalarowicz
Copy link
Copy Markdown
Contributor

jgalarowicz commented Aug 8, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants