[
https://issues.apache.org/jira/browse/MESOS-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kapil Arya updated MESOS-2235:
------------------------------
Description:
Currently, if one wishes to use the system-wide installation of third party
dependencies such as protobuf, the following configure command line is used:
{code}
../configure --with-protobuf=/usr
{code}
The configure scripts then adds "/usr/include" to include path and /usr/lib to
library path. However, on some 64-bit systems (e.g., OpenSuse), /usr/lib
points to the 32-bit libraries and thus the build system ends up printing a
bunch of warnings:
{code}
libtool: link: g++ -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -o
.libs/mesos-slave slave/mesos_slave-main.o -L/usr/lib ./.libs/libmesos.so
-lprotobuf -lsasl2 -lsvn_delta-1 -lsvn_subr-1 -lapr-1 -lcurl -lz -lpthread -lrt
-lunwind
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/librt.so when searching for -lrt
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc
{code}
Further, if someone uses system-wide installations, we can omit the path with
the configure flag and the system should be able to pick the correct flags.
E.g, the above example becomes:
{code}
../configure --with-protobuf
{code}
Since, the correct system include and lib dirs are already in the standard
path, we don't need to specify that path.
was:
Currently, if one wishes to use the system-wide installation of third party
dependencies such as protobuf, the following configure command line is used:
../configure --with-protobuf=/usr
The configure scripts then adds "/usr/include" to include path and /usr/lib to
library path. However, on some 64-bit systems (e.g., OpenSuse), /usr/lib
points to the 32-bit libraries and thus the build system ends up printing a
bunch of warnings:
libtool: link: g++ -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -o
.libs/mesos-slave slave/mesos_slave-main.o -L/usr/lib ./.libs/libmesos.so
-lprotobuf -lsasl2 -lsvn_delta-1 -lsvn_subr-1 -lapr-1 -lcurl -lz -lpthread -lrt
-lunwind
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/librt.so when searching for -lrt
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc
Further, if someone uses system-wide installations, we can omit the path with
the configure flag and the system should be able to pick the correct flags.
E.g, the above example becomes:
../configure --with-protobuf
Since, the correct system include and lib dirs are already in the standard
path, we don't need to specify that path.
> Better path handling when using system-wide installations of third party
> dependencies
> -------------------------------------------------------------------------------------
>
> Key: MESOS-2235
> URL: https://issues.apache.org/jira/browse/MESOS-2235
> Project: Mesos
> Issue Type: Improvement
> Components: build
> Reporter: Kapil Arya
> Priority: Minor
>
> Currently, if one wishes to use the system-wide installation of third party
> dependencies such as protobuf, the following configure command line is used:
> {code}
> ../configure --with-protobuf=/usr
> {code}
> The configure scripts then adds "/usr/include" to include path and /usr/lib
> to library path. However, on some 64-bit systems (e.g., OpenSuse), /usr/lib
> points to the 32-bit libraries and thus the build system ends up printing a
> bunch of warnings:
> {code}
> libtool: link: g++ -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -o
> .libs/mesos-slave slave/mesos_slave-main.o -L/usr/lib ./.libs/libmesos.so
> -lprotobuf -lsasl2 -lsvn_delta-1 -lsvn_subr-1 -lapr-1 -lcurl -lz -lpthread
> -lrt -lunwind
> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
> skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
> skipping incompatible /usr/lib/librt.so when searching for -lrt
> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
> skipping incompatible /usr/lib/libm.so when searching for -lm
> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
> skipping incompatible /usr/lib/libc.so when searching for -lc
> {code}
> Further, if someone uses system-wide installations, we can omit the path with
> the configure flag and the system should be able to pick the correct flags.
> E.g, the above example becomes:
> {code}
> ../configure --with-protobuf
> {code}
> Since, the correct system include and lib dirs are already in the standard
> path, we don't need to specify that path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
