[
https://issues.apache.org/jira/browse/MESOS-7581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072951#comment-16072951
]
Till Toenshoff commented on MESOS-7581:
---------------------------------------
1.3.x:
{noformat}
commit 06e2fad1dfd851ccb79f2c5e320f564071c2df2f
Author: Benjamin Bannier <[email protected]>
Date: Thu Jun 8 20:04:06 2017 +0200
Fixed interference of unbundled dependency include paths with Boost.
Since some of the contents of Boost headers we include trigger
diagnostics with our compiler setups (e.g., use of 'auto_ptr'), we
include Boost with '-isystem' instead of '-I'. This treats headers
included from such paths as system headers which suppresses all
diagnostics. Other headers we include with '-I'.
At least GCC performs separate lookups for headers depending on how
their path was specified[1].
> The lookup order is as follows:
>
> 1. For the quote form of the include directive, the directory of the
> current file is searched first.
> 2. For the quote form of the include directive, the directories
> specified by '-iquote' options are searched in left-to-right order,
> as they appear on the command line.
> 3. Directories specified with '-I' options are scanned in
> left-to-right order.
> 4. Directories specified with '-isystem' options are scanned in
> left-to-right order.
> 5. Standard system directories are scanned.
> 6. Directories specified with '-idirafter' options are scanned in
> left-to-right order.
Since we add Boost headers with '-isystem', but other headers with '-I',
building with e.g., unbundled protobuf by specifying
'--with-protobuf=PROTO_PREFIX' causes the build to possibly pick up a
Boost installed in 'PROTO_PREFIX' -- the protobuf include path is
specified with '-I' while the Boost include path is specified with
'-isystem' causes the compiler to first look for Boost headers in the
paths specified with '-I', e.g., the protobuf prefix.
In order to prevent finding wrong Boost headers, all include paths
possibly containing Boost headers need to be added with the same flag as
the Boost headers itself, i.e., with '-isystem'. This commit adjusts
include path specification for all possibly externally provided
locations, i.e., unbundled third-party dependencies.
[1]: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
Review: https://reviews.apache.org/r/59625/
{noformat}
1.2.x:
{noformat}
commit da240ec99f02fefc737c7d31c4fb874498484c06
Author: Benjamin Bannier <[email protected]>
Date: Thu Jun 8 20:04:06 2017 +0200
Fixed interference of unbundled dependency include paths with Boost.
Since some of the contents of Boost headers we include trigger
diagnostics with our compiler setups (e.g., use of 'auto_ptr'), we
include Boost with '-isystem' instead of '-I'. This treats headers
included from such paths as system headers which suppresses all
diagnostics. Other headers we include with '-I'.
At least GCC performs separate lookups for headers depending on how
their path was specified[1].
> The lookup order is as follows:
>
> 1. For the quote form of the include directive, the directory of the
> current file is searched first.
> 2. For the quote form of the include directive, the directories
> specified by '-iquote' options are searched in left-to-right order,
> as they appear on the command line.
> 3. Directories specified with '-I' options are scanned in
> left-to-right order.
> 4. Directories specified with '-isystem' options are scanned in
> left-to-right order.
> 5. Standard system directories are scanned.
> 6. Directories specified with '-idirafter' options are scanned in
> left-to-right order.
Since we add Boost headers with '-isystem', but other headers with '-I',
building with e.g., unbundled protobuf by specifying
'--with-protobuf=PROTO_PREFIX' causes the build to possibly pick up a
Boost installed in 'PROTO_PREFIX' -- the protobuf include path is
specified with '-I' while the Boost include path is specified with
'-isystem' causes the compiler to first look for Boost headers in the
paths specified with '-I', e.g., the protobuf prefix.
In order to prevent finding wrong Boost headers, all include paths
possibly containing Boost headers need to be added with the same flag as
the Boost headers itself, i.e., with '-isystem'. This commit adjusts
include path specification for all possibly externally provided
locations, i.e., unbundled third-party dependencies.
[1]: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
{noformat}
1.1.x:
{noformat}
commit 116733e03afbb9136e2782230eddb4029c195d83
Author: Benjamin Bannier <[email protected]>
Date: Thu Jun 8 20:04:06 2017 +0200
Fixed interference of unbundled dependency include paths with Boost.
Since some of the contents of Boost headers we include trigger
diagnostics with our compiler setups (e.g., use of 'auto_ptr'), we
include Boost with '-isystem' instead of '-I'. This treats headers
included from such paths as system headers which suppresses all
diagnostics. Other headers we include with '-I'.
At least GCC performs separate lookups for headers depending on how
their path was specified[1].
> The lookup order is as follows:
>
> 1. For the quote form of the include directive, the directory of the
> current file is searched first.
> 2. For the quote form of the include directive, the directories
> specified by '-iquote' options are searched in left-to-right order,
> as they appear on the command line.
> 3. Directories specified with '-I' options are scanned in
> left-to-right order.
> 4. Directories specified with '-isystem' options are scanned in
> left-to-right order.
> 5. Standard system directories are scanned.
> 6. Directories specified with '-idirafter' options are scanned in
> left-to-right order.
Since we add Boost headers with '-isystem', but other headers with '-I',
building with e.g., unbundled protobuf by specifying
'--with-protobuf=PROTO_PREFIX' causes the build to possibly pick up a
Boost installed in 'PROTO_PREFIX' -- the protobuf include path is
specified with '-I' while the Boost include path is specified with
'-isystem' causes the compiler to first look for Boost headers in the
paths specified with '-I', e.g., the protobuf prefix.
In order to prevent finding wrong Boost headers, all include paths
possibly containing Boost headers need to be added with the same flag as
the Boost headers itself, i.e., with '-isystem'. This commit adjusts
include path specification for all possibly externally provided
locations, i.e., unbundled third-party dependencies.
[1]: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
Review: https://reviews.apache.org/r/59625/
{noformat}
> Specifying an unbundled dependency can cause build to pick up wrong Boost
> version
> ---------------------------------------------------------------------------------
>
> Key: MESOS-7581
> URL: https://issues.apache.org/jira/browse/MESOS-7581
> Project: Mesos
> Issue Type: Bug
> Components: build
> Affects Versions: 1.2.2, 1.3.1, 1.1.3
> Reporter: Benjamin Bannier
> Assignee: Benjamin Bannier
> Labels: autotools
> Fix For: 1.4.0
>
>
> Specifying an unbundled dependency can cause the build to pick up a wrong
> Boost version. Assuming we have e.g., both protobuf and Boost installed in
> {{PREFIX}}, configuring with {{--with-protobuf=PREFIX}} causes the build to
> pick up the Boost version from {{PREFIX}} instead of using the bundled one.
> This appears to be due to how we specify Boost include paths. Boost paths are
> added with {{-isystem}} to suppress warnings; the protobuf include path, on
> the other hand, would be added with {{-I}}. GCC and for compatibility clang
> first search all paths specified with {{-I}} left-to-right before looking at
> paths given with {{-isystem}}, see [the GCC
> documenation|https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
