You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by "Till Toenshoff (JIRA)" <ji...@apache.org> on 2014/03/04 02:16:22 UTC
[jira] [Comment Edited] (MESOS-1010) Python extension build is
broken if gflags-dev is installed
[ https://issues.apache.org/jira/browse/MESOS-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918623#comment-13918623 ]
Till Toenshoff edited comment on MESOS-1010 at 3/4/14 1:15 AM:
---------------------------------------------------------------
The issue is indeed nasty - ran into it myself just now, after having gflags installed (on OSX via homebrew).
After fixing this by temporarily uninstalling the gflags distribution, I ran into the next, equally nasty issue;
I had leveldb preinstalled as well and its distribution linked against libsnappy. As the mesos-python module does not link against that library, I once again got missing symbols when running make-check; __ZN6snappy11RawCompressEPKcmPcPm (snappy::RawCompress(char const*, unsigned long, char*, unsigned long*)).
I think that do need a proper fix for this situation as it renders the python-binding unusable for developers that build mesos out of the sources but have gflags and/or snappy installed.
was (Author: tillt):
The issue is indeed nasty - ran into it myself just now, after having gflags installed (on OSX via homebrew).
After fixing this by temporarily uninstalling the gflags distribution, I ran into the next, equally nasty issue;
I had leveldb preinstalled as well and its distribution linked against libsnappy. As the mesos-python module does not link against that library, I once again got missing symbols when running make-check; __ZN6snappy11RawCompressEPKcmPcPm (snappy::RawCompress(char const*, unsigned long, char*, unsigned long*)).
I think that do need a proper fix for this situation as it renders the python-binding unusable for developers that build mesos out of the sources but have gflags and/or leveldb installed.
> Python extension build is broken if gflags-dev is installed
> -----------------------------------------------------------
>
> Key: MESOS-1010
> URL: https://issues.apache.org/jira/browse/MESOS-1010
> Project: Mesos
> Issue Type: Bug
> Components: build, python api
> Environment: Fedora 20, amd64. GCC: 4.8.2.
> Reporter: Nikita Vetoshkin
>
> In my environment mesos build from master results in broken python api module {{_mesos.so}}:
> {noformat}
> nekto0n@ya-darkstar ~/workspace/mesos/src/python $ PYTHONPATH=build/lib.linux-x86_64-2.7/ python -c "import _mesos"
> Traceback (most recent call last):
> File "<string>", line 1, in <module>
> ImportError: /home/nekto0n/workspace/mesos/src/python/build/lib.linux-x86_64-2.7/_mesos.so: undefined symbol: _ZN6google14FlagRegistererC1EPKcS2_S2_S2_PvS3_
> {noformat}
> Unmangled version of symbol looks like this:
> {noformat}
> google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*, char const*, void*, void*)
> {noformat}
> During {{./configure}} step {{glog}} finds {{gflags}} development files and starts using them, thus *implicitly* adding dependency on {{libgflags.so}}. This breaks Python extensions module and perhaps can break other mesos subsystems when moved to hosts without {{gflags}} installed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)