Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fails to compile with older versions of clang w/ -std=c++0x #58

Open
trapexit opened this issue Sep 4, 2020 · 8 comments
Open

fails to compile with older versions of clang w/ -std=c++0x #58

trapexit opened this issue Sep 4, 2020 · 8 comments

Comments

@trapexit
Copy link

trapexit commented Sep 4, 2020

https://travis-ci.org/github/trapexit/mergerfs/jobs/724307527#L256

@martinmoene
Copy link
Owner

thanks :)

@martinmoene
Copy link
Owner

@trapexit Can you have a look if above change solves compiling with clang 3.4? Wasn't able to test it myself via godbolt.

@trapexit
Copy link
Author

trapexit commented Sep 7, 2020

https://travis-ci.org/github/trapexit/mergerfs/jobs/725001551

Doesn't appear so but I did try testing it in isolation and couldn't reproduce it either. Must be something about my usage. I'll have to dig into it more.

@martinmoene
Copy link
Owner

@trapexit Only now special-cased the type traits that are missing when using clang 3.4. Would appreciate it if you have a look if above change (take 2) solves compiling with clang 3.4; thanks in advance.

@trapexit
Copy link
Author

trapexit commented Sep 7, 2020

Haven't gotten the time to investigate in detail but still errors out with the new change.

https://travis-ci.org/github/trapexit/mergerfs/jobs/725066910

martinmoene added a commit that referenced this issue Sep 8, 2020
…trapexit)

Fix std11::is_assignable<T,U>: add second template argument
@martinmoene
Copy link
Owner

@trapexit Fixed overlooked second template argument of std11::is_asssignable<>.

@trapexit
Copy link
Author

trapexit commented Sep 8, 2020

https://travis-ci.org/github/trapexit/mergerfs/jobs/725236488

Seems to have fixed things on 3.4 but still broken on 5 (from Ubuntu Trusty).

@martinmoene
Copy link
Owner

martinmoene commented Sep 8, 2020

@trapexit I'm not very adept at Travis' usage and the various distributions one can or must use to certain effects, or deducing the information of interest from a log.

That said, isn't /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits a bit old relative to clang 5.0.0?

Non-failing usage of optional-lite with clang 5.0.0 (or 4.0.0 for that matter):

So, this looks like a different defiance from the clang 3.4 one to me. It hints to a standard-library-dependency check instead of a compiler version check, something that is not present in any of the *-lite libraries as far as I'm aware.

Could use some helpful input here :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants