[
https://issues.apache.org/jira/browse/MESOS-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14581464#comment-14581464
]
Roger Ignazio commented on MESOS-1856:
--
I hit this today when trying to build Mesos 0.22.0 with the network isolator on
RHEL 7 and Ubuntu 14.04. The latest version of libnl3 in the package repos is
3.2.21, which means that we need to build libnl3 from source. By default, it
installs its header files to {{/usr/local/include/libnl3}}.
The surprising thing is that, if libnl3 isn't present anywhere on the system,
the configure script fails like we'd expect it to. But if we've installed it to
its default location (in {{/usr/local}}), the configure step completes
successfully, even if nothing _actually_ works:
{code}
checking netlink/netlink.h usability... no
checking netlink/netlink.h presence... no
checking for netlink/netlink.h... no
checking libnl3/netlink/netlink.h usability... no
checking libnl3/netlink/netlink.h presence... no
checking for libnl3/netlink/netlink.h... no
checking for rtnl_link_veth_add in -lnl-route-3... yes
checking netlink/route/link/veth.h usability... no
checking netlink/route/link/veth.h presence... no
checking for netlink/route/link/veth.h... no
checking libnl3/netlink/route/link/veth.h usability... no
checking libnl3/netlink/route/link/veth.h presence... no
checking for libnl3/netlink/route/link/veth.h... no
{code}
Eventually, Make just bails out:
{code}
libtool: compile: g++ -DPACKAGE_NAME=\"mesos\" -DPACKAGE_TARNAME=\"mesos\"
-DPACKAGE_VERSION=\"0.22.0\" "-DPACKAGE_STRING=\"mesos 0.22.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\"
-DVERSION=\"0.22.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBCURL=1
-DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 -DHAVE_SVN_VERSION_H=1
-DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1
-DHAVE_LIBSASL2=1 -DHAVE_LIBNL_3=1 -DHAVE_LIBNL_ROUTE_3=1
-DHAVE_LIBNL_IDIAG_3=1 -DWITH_NETWORK_ISOLATOR=1 -DMESOS_HAS_JAVA=1
-DHAVE_PYTHON=\"2.7\" -DMESOS_HAS_PYTHON=1 -I. -Wall -Werror
-DLIBDIR=\"/usr/local/lib\" -DPKGLIBEXECDIR=\"/usr/local/libexec/mesos\"
-DPKGDATADIR=\"/usr/local/share/mesos\" -I../include
-I../3rdparty/libprocess/include
-I../3rdparty/libprocess/3rdparty/stout/include -I../include -I../include/mesos
-I../3rdparty/libprocess/3rdparty/boost-1.53.0
-I../3rdparty/libprocess/3rdparty/picojson-4f93734
-I../3rdparty/libprocess/3rdparty/protobuf-2.5.0/src
-I../3rdparty/libprocess/3rdparty/glog-0.3.3/src
-I../3rdparty/libprocess/3rdparty/glog-0.3.3/src -I../3rdparty/leveldb/include
-I../3rdparty/zookeeper-3.4.5/src/c/include
-I../3rdparty/zookeeper-3.4.5/src/c/generated -I/usr/include/libnl3
-I../3rdparty/libprocess/3rdparty/protobuf-2.5.0/src
-I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
-pthread -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -MT
linux/routing/libmesos_no_3rdparty_la-route.lo -MD -MP -MF
linux/routing/.deps/libmesos_no_3rdparty_la-route.Tpo -c
linux/routing/route.cpp -fPIC -DPIC -o
linux/routing/.libs/libmesos_no_3rdparty_la-route.o
linux/routing/route.cpp:23:26: fatal error: netlink/addr.h: No such file or
directory
{code}
A sane-enough workaround would be to simply override the variable assignment at
build time, which I think is preferable to having a user build libnl3 with
{{--prefix=/usr}} (IMO, anyway).
{code}
./configure --with-network-isolator
make LIBNL_CFLAGS="-I/usr/local/include/libnl3"
{code}
So if this ticket does get bumped from the next release (currently targeted at
0.23.0), we could at least update the docs with a workaround. I think we might
want to re-categorize this as a bug though.
> Support specifying libnl3 install location.
> ---
>
> Key: MESOS-1856
> URL: https://issues.apache.org/jira/browse/MESOS-1856
> Project: Mesos
> Issue Type: Task
>Affects Versions: 0.22.0, 0.22.1
>Reporter: Jie Yu
>
> LIBNL_CFLAGS uses a hard-coded path in the configure script, instead of
> detecting the location.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
