Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
I have a question regarding GOMP, that I figured is related to gcc.
I am using this image as a base for some experiments. It seems that I am using an alright version (4.9.2) based on this unmodified image, but I get some strange behaviour with a number of Cython related packages.
When running this on the unmodified jupyter/all-spark-notebook docker image, when attempting to run Python I get the following issue,
Traceback (most recent call last):
File "", line 1, in
File "/opt/conda/lib/python3.4/site-packages/lightfm/init.py", line 1, in
File "/opt/conda/lib/python3.4/site-packages/lightfm/lightfm.py", line 7, in
from .lightfm_fast import (CSRMatrix, FastLightFM,
from .lightfm_fast import (CSRMatrix, FastLightFM, fit_logistic, predict_lightfm, fit_warp, fit_bpr, fit_warp_kos).
Also tried ".lightfm" to "lightfm" to change from relative import. Same error
--------------------------------------------------------------------------- OSError Traceback (most recent call last) <ipython-input-2-afdaff4619ce> in <module>() ----> 1 import xgboost /home/jovyan/.local/lib/python3.5/site-packages/xgboost-0.4-py3.5.egg/xgboost/__init__.py in <module>() 9 import os 10 ---> 11 from .core import DMatrix, Booster 12 from .training import train, cv 13 from . import rabit /home/jovyan/.local/lib/python3.5/site-packages/xgboost-0.4-py3.5.egg/xgboost/core.py in <module>() 81 82 # load the XGBoost library globally ---> 83 _LIB = _load_lib() 84 85 def _check_call(ret): /home/jovyan/.local/lib/python3.5/site-packages/xgboost-0.4-py3.5.egg/xgboost/core.py in _load_lib() 75 if len(lib_path) == 0: 76 return None ---> 77 lib = ctypes.cdll.LoadLibrary(lib_path) 78 lib.XGBGetLastError.restype = ctypes.c_char_p 79 return lib /opt/conda/lib/python3.5/ctypes/__init__.py in LoadLibrary(self, name) 423 424 def LoadLibrary(self, name): --> 425 return self._dlltype(name) 426 427 cdll = LibraryLoader(CDLL) /opt/conda/lib/python3.5/ctypes/__init__.py in __init__(self, name, mode, handle, use_errno, use_last_error) 345 346 if handle is None: --> 347 self._handle = _dlopen(self._name, mode) 348 else: 349 self._handle = handle OSError: /opt/conda/bin/../lib/libgomp.so.1: version `GOMP_4.0' not found (required by /home/jovyan/.local/lib/python3.5/site-packages/xgboost-0.4-py3.5.egg/xgboost/libxgboost.so)
I have just noticed that this is a recurring pattern and at times can be quite limiting, but I don't understand compilers that well to know if this actually a problem with the image or if that's not really an 'issue', but rather a design decision. Any ideas?
I have this line
But no gcc I also have glib.
The complete list:
Also when I tried to do
It looks like Python is looking for gomp in /opt/conda/lib and finding an incompatible version, and R is doing the same in the spark-1.6.0 dir and finding one that is also missing something.
Not sure how to force both to use the system lib path (or if that would help). Maybe setting
So, I think one thing that might help is if we can
This is hardly the first time I have seen someone struggle with some oddities related to this package and its not clear to me if it is even being built the same way each time. It would be nice if we could get everyone to use one canonical package for
Would you, @jakubLangr, be will to try submitting it to conda-forge? This should ideally cut down on issues of this nature and it would make it easy to install. All the builds happen in very minimal VMs so there is little risk of contamination. You could continue to tweak the recipe after submission to your liking. Not to mention, the build process is completely automated so there is no need to spend cycles on a local machine doing this. I would be more than happy to help you through the process. Once we have an acceptable recipe, builds and releases would occur immediately. Please let me know if this is something you would be interested in.
@jakirkham I hit the original problem simply by doing
Thanks for investigating, @parente. I expect if one installed Continuum's
Indeed @jakirkham is right:
I put this workaround on the recipes page for the time being: https://github.com/jupyter/docker-stacks/wiki/Docker-recipes#use-xgboost
Let's leave this issue open for a bit so @jakubLangr can respond about the conda forge recipe and/or this workaround.
I understand that is not such a massive deal for you guys as that it is not an extremely popular plug-in and I can probably find a workaround, but it would be probably good to record this for posterity.
You can still replicate this by starting a new
I understand that ideally lightfm would be
Any thoughts on this?
Again @jakubLangr, I think the right path forward is to write conda recipes for these difficult to
That being said, one needs to take ownership of recipes they contribute. We can help you get started, but ultimately it will be on you to maintain the things you add. Though we do provide you the infrastructure to build and deploy on any platform you choose to support. That way you will be able to run
As awesome as the images over here are, they are not targeted to be a build environment. They are targeted at installing a basic stack. Anything else you want you can resolve on your own by using
To get the ball rolling, I would suggest starting by reading the aforementioned docs and maybe writing a recipe for something simple like a Python package and submitting that to the staged-recipes repo as described. Once you have more of a feel for the system, we can try repackaging this recipe for