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

-isystem /usr/include doesn't work with gcc6 #144

Closed
micahscopes opened this issue Apr 12, 2017 · 6 comments
Closed

-isystem /usr/include doesn't work with gcc6 #144

micahscopes opened this issue Apr 12, 2017 · 6 comments

Comments

@micahscopes
Copy link

I'm compiling on Arch Linux, and am getting dependencies from Arch's package manager. Headers are stored in /usr/include. I've configured all my header directories using the helpful instructions at the top of the Makefile.

However, I run into errors that stdlib.h cannot be found. I traced it to this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129#c1

So I've gone and commented out most of the *_INCL_DIR variables, since they end up in -isystem arguments. That works, for the most part, except when those variables are needed for other reasons, in which case I go and delete the -isystem line.

I've been able to get openvdb to compile, but am not sure how I'd fix the Makefile to handle more general cases, like people using gcc < 6

Any advice?

@OpenVDB-DevTeam
Copy link
Contributor

Since /usr/include/ is searched by default, you can set *_INCL_DIR to some nonexistent directory, or to an existing directory that contains no headers. Or just change -isystem to -I, if you don't mind seeing lots of compiler warnings.

@phcerdan
Copy link

phcerdan commented Jul 7, 2019

I can reproduce this with gcc 9.1.
To fix it, just set option in CMake to not use isystem from imported targets, I found the reference in the CMake maillist here:

cmake ../src -DCMAKE_NO_SYSTEM_FROM_IMPORTED:BOOL=TRUE 

This is the first time I faced this in CMake, probably has to do with the way (non standard?) OpenVDB is importing targets.

@frispete
Copy link

Thanks for the trick @phcerdan, same happens here for llvm builds on openSUSE Tumbleweed (a rolling release). Here's the public build: https://build.opensuse.org/package/live_build_log/home:frispete:blender/openvdb/openSUSE_Tumbleweed/x86_64
BTW, the build triggers (a few too) many warnings due to some openexr/tbb deprecations.

A further note on packaging: it happens, that the library base is not /usr/lib for some 64bit distributions.
check the less than optimal %prep section of: https://build.opensuse.org/package/view_file/home:frispete:blender/openvdb/openvdb.spec?expand=1

@anil100391
Copy link

Shouldn't the usage of concerned cmake flag be mentioned in README building section?

@syoyo
Copy link
Contributor

syoyo commented Nov 5, 2019

More proper fix may be removing ${IlmBase_INCLUDE_DIR}/../
in

https://github.com/AcademySoftwareFoundation/openvdb/blob/master/cmake/FindIlmBase.cmake#L325

(and do same thing for FindOpenEXR.cmake)

This path is expanded to /usr/include/OpenEXR/.. in apt installed OpenEXR(IlmBase) on Ubuntu 18.04.

I have confirmed OpenVDB compiles fine at least on Ubuntu 18.04 by deleting these include paths.

@Hideman85
Copy link

Same issue on master commit f077a14
The fix -DCMAKE_NO_SYSTEM_FROM_IMPORTED:BOOL=TRUE works but can't compile without

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

7 participants