I have tried to repo init the source code Ubuntu build machine and it is successfully able to clone the code.
repo init -u git#github.com:xxx/xx_manifest.git -b xxx
Now I am trying repo init the source code in VM Ubuntu machine.
In between getting the error like below:
Traceback (most recent call last):
File "/xxx/.repo/repo/main.py", line 56, in <module>
from subcmds.version import Version
File "/xxx/.repo/repo/subcmds/__init__.py", line 38, in <module>
['%s' % name])
File "/xxx/.repo/repo/subcmds/upload.py", line 27, in <module>
from hooks import RepoHook
File "/xxx/.repo/repo/hooks.py", line 472
file=sys.stderr)
^
SyntaxError: invalid syntax
python version is same in build machine and vm machine 2.7.17.
try these commands
curl https://storage.googleapis.com/git-repo-downloads/repo-1 > ~/bin/repo
chmod a+x ~/bin/repo
python3 ~/bin/repo init -u git#....
I just had the same issue and this resolved it for me :
Download last version of repo :
curl https://storage.googleapis.com/git-repo-downloads/repo-1 > repo
Change right to make it executable : chmod a+x repo
Run your repo init with python3 and the "repo" you just download : python3 repo init -u git#github.com:xxx/xx_manifest.git -b xxx
I have experienced the same issue on Ubuntu 18.04 during the installation of the OpenSTLinux Yocto layer with the following command:
repo init -u https://github.com/STMicroelectronics/oe-manifest.git -b refs/tags/openstlinux-5.4-dunfell-mp1-20-11-12
Returns:
Get https://gerrit.googlesource.com/git-repo/clone.bundle
Get https://gerrit.googlesource.com/git-repo
remote: Counting objects: 2, done
remote: Finding sources: 100% (117/117)
remote: Total 117 (delta 63), reused 117 (delta 63)
Receiving objects: 100% (117/117), 142.25 KiB | 11.85 MiB/s, done.
Resolving deltas: 100% (63/63), completed with 32 local objects.
From https://gerrit.googlesource.com/git-repo
1469c28..0588f3d main -> origin/main
* [new tag] v2.11 -> v2.11
* [new tag] v2.11.1 -> v2.11.1
Traceback (most recent call last):
File "/home/xxx/Distribution-Package/openstlinux-5.4-dunfell-mp1-20-11-12/.repo/repo/main.py", line 56, in <module>
from subcmds.version import Version
File "/home/xxx/Distribution-Package/openstlinux-5.4-dunfell-mp1-20-11-12/.repo/repo/subcmds/__init__.py", line 38, in <module>
['%s' % name])
File "/home/xxx/Distribution-Package/openstlinux-5.4-dunfell-mp1-20-11-12/.repo/repo/subcmds/upload.py", line 27, in <module>
from hooks import RepoHook
File "/home/xxx/Distribution-Package/openstlinux-5.4-dunfell-mp1-20-11-12/.repo/repo/hooks.py", line 472
file=sys.stderr)
This issue goes away with using Python3 instead of Python (2.7). You can do this:
sudo rm /usr/bin/python
sudo ln -s /usr/bin/python3 /usr/bin/python
Try below command to make it will work 100%, tried & suggested
mkdir -p ~/.bin
PATH="${HOME}/.bin:${PATH}"
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/.bin/repo
chmod a+rx ~/.bin/repo
One solution is to modify the first line of /usr/bin/repo and change it from
#!/usr/bin/python
to
#!/usr/bin/python3
This asks the system to use Python3 instead of the default Python.
If the system you are running on doesn't have python3, like in my case, and you don't have the option to install python3, or installing it breaks other parts, the option is the degrade repo to a version that uses python2.7:
- git clone https://gerrit.googlesource.com/git-repo
- cd git-repo
- git reset --hard v1.13.11
- mkdir -p ~/.bin
- PATH="${HOME}/.bin:${PATH}"
- cp repo ~/.bin/repo
- chmod a+rx ~/.bin/repo
This will use v1.13.11 of repo, which works with python2.7
As seen in a similar error in arvestad/alv issue 1, that would be consistent with running the process with Python 2.7 instead of Python3
Double-check you Python version between:
your Ubuntu build machine (where the repo init works)
your VM Ubuntu machine (where the repo init fails)
Same error here, with the error suggesting you are executing python2 with a PYTHONPATH that's only appropriate for python3.
I don't know exactly how this works, but i just had the same issue and this resolved it for me it seems.
https://source.android.com/setup/develop#installing-repo
Dont use the legacy one, use the first one to resolve it.
Edit: It seems you also need to have python 3.6 installed on you system to have this work. You can still have update-alternatives point to python 2.7, you simply need 3.6 or newer installed.
Just install python3 and the latest repo.
I encountered the problem too, but on Mac OS. The log is exactly the same as yours.
Definitely python2 caused this problem. repo is try to run python3 files in python2 environment.
I found the this from repo docs https://gerrit.googlesource.com/git-repo/+/refs/heads/master/docs/python-support.md
So I update my repo (which located in depot_tools). Since I already have python3 installed, everything is ok now.
Hope my experience may help you.
Related
I have somewhat successfully dockerized a software repository (KPConv) that I plan to work with and extend with the following Dockerfile
FROM tensorflow/tensorflow:1.12.0-devel-gpu-py3
# Install other required python stuff
RUN apt-get update && apt install -y --fix-missing --no-install-recommends\
python3-setuptools python3-pip python3-tk
RUN pip install --upgrade pip
RUN pip3 install numpy scikit-learn psutil matplotlib pyqt5 laspy
# Compile the custom operations and CPP wrappers
# For some reason this must be done within container, cannot access libcuda.so during docker build
# Ref: https://stackoverflow.com/questions/66575232
#COPY . /kpconv
#WORKDIR /kpconv/tf_custom_ops
#RUN sh compile_op.sh
#WORKDIR /kpconv/cpp_wrappers
#RUN sh compile_wrappers.sh
# Set the working directory to kpconv
WORKDIR /kpconv
# Set root user password so we can su/sudo later if need be
RUN echo "root:pass" | chpasswd
# Create a user and group akin to the host within the container
ARG USER_ID
ARG GROUP_ID
RUN addgroup --gid $GROUP_ID user
RUN adduser --disabled-password --gecos '' --uid $USER_ID --gid $GROUP_ID user
USER user
#Build
#sudo docker build -t kpconv-test \
# --build-arg USER_ID=$(id -u) \
# --build-arg GROUP_ID=$(id -g) \
# .
At the end of this Dockerfile I followed a post found here which describes a way to correctly set the permissions of files generated by/within a container so that the host machine/user can access them without having to alter the file permissions.
Also, this software repository makes use of custom tensorflow operations in C++ (KPConv/tf_custom_ops) along with Python wrappers for custom C++ code (KPConv/cpp_wrappers). The author of KPConv, Thomas Hugues, provides a bash script which compiles each to generate various .so files.
If I COPY the repository into the image during the build process (COPY . /kpconv), startup the container, call both of the compile bash scripts, and run the code then Python correctly loads the C++ wrapper (the generated .so grid_subsampling.cpython-35m-x86_64-linux-gnu.so) and begins running the software as expected/intended.
$ sudo docker run -it \
> -v /<myhostpath>/data_sets:/data \
> -v /<myhostpath>/_output:/output \
> --runtime=nvidia kpconv-test /bin/bash
user#eec8553dcb5d:/kpconv$ cd tf_custom_ops
user#eec8553dcb5d:/kpconv/tf_custom_ops$ sh compile_op.sh
user#eec8553dcb5d:/kpconv/tf_custom_ops$ cd ..
user#eec8553dcb5d:/kpconv$ cd cpp_wrappers/
user#eec8553dcb5d:/kpconv/cpp_wrappers$ sh compile_wrappers.sh
running build_ext
building 'grid_subsampling' extension
<Redacted for brevity>
user#eec8553dcb5d:/kpconv/cpp_wrappers$ cd ..
user#eec8553dcb5d:/kpconv$ python training_ModelNet40.py
Dataset Preparation
*******************
Loading training points
1620.2 MB loaded in 0.6s
Loading test points
411.6 MB loaded in 0.2s
<Redacted for brevity>
This works well and allows me run the KPConv software.
Also to note for later the .so file has the hash
user#eec8553dcb5d:/kpconv/cpp_wrappers/cpp_subsampling$ sha1sum grid_subsampling.cpython-35m-x86_64-linux-gnu.so
a17eef453f6d2370a15bc2a0e6714c978390c5c3 grid_subsampling.cpython-35m-x86_64-linux-gnu.so
It also has the permissions
user#eec8553dcb5d:/kpconv/cpp_wrappers/cpp_subsampling$ ls -al grid_subsampling.cpython-35m-x86_64-linux-gnu.so
-rwxr-xr-x 1 user user 561056 Mar 14 02:16 grid_subsampling.cpython-35m-x86_64-linux-gnu.so
Though it produces a difficult workflow for quickly editing and the software for my purposes and quickly running it within the container. Every change to the code requires a new build of the image. Thus, I would much rather mount/volume the KPConv code from the host into the container at runtime and then the edits are "live" within the container as it is running.
Doing this and using the Dockerfile at the top of the post (no COPY . /kpconv) to compile an image, perform the same compilation steps, and run the code
$ sudo docker run -it \
> -v /<myhostpath>/data_sets:/data \
> -v /<myhostpath>/KPConv_Tensorflow:/kpconv \
> -v /<myhostpath>/_output:/output \
> --runtime=nvidia kpconv-test /bin/bash
user#a82e2c1af21a:/kpconv$ cd tf_custom_ops/
user#a82e2c1af21a:/kpconv/tf_custom_ops$ sh compile_op.sh
user#a82e2c1af21a:/kpconv/tf_custom_ops$ cd ..
user#a82e2c1af21a:/kpconv$ cd cpp_wrappers/
user#a82e2c1af21a:/kpconv/cpp_wrappers$ sh compile_wrappers.sh
running build_ext
building 'grid_subsampling' extension
<Redacted for brevity>
user#a82e2c1af21a:/kpconv/cpp_wrappers$ cd ..
user#a82e2c1af21a:/kpconv$ python training_ModelNet40.py
I receive the following Python ImportError
user#a82e2c1af21a:/kpconv$ python training_ModelNet40.py
Traceback (most recent call last):
File "training_ModelNet40.py", line 36, in <module>
from datasets.ModelNet40 import ModelNet40Dataset
File "/kpconv/datasets/ModelNet40.py", line 40, in <module>
from datasets.common import Dataset
File "/kpconv/datasets/common.py", line 29, in <module>
import cpp_wrappers.cpp_subsampling.grid_subsampling as cpp_subsampling
ImportError: /kpconv/cpp_wrappers/cpp_subsampling/grid_subsampling.cpython-35m-x86_64-linux-gnu.so: failed to map segment from shared object
Why is this Python wrapper for C++ only useable when COPY'ing code into the docker image and not when mounted by volume?
This .so file has the same hash and permissions as the first described situation
user#a82e2c1af21a:/kpconv/cpp_wrappers/cpp_subsampling$ sha1sum grid_subsampling.cpython-35m-x86_64-linux-gnu.so
a17eef453f6d2370a15bc2a0e6714c978390c5c3 grid_subsampling.cpython-35m-x86_64-linux-gnu.so
user#a82e2c1af21a:/kpconv/cpp_wrappers/cpp_subsampling$ ls -al grid_subsampling.cpython-35m-x86_64-linux-gnu.so
-rwxr-xr-x 1 user user 561056 Mar 14 02:19 grid_subsampling.cpython-35m-x86_64-linux-gnu.so
On my host machine the file has the following permissions (it's on the host because /kpconv was mounted as a volume) (for some reason the container is in the future too, check the timestamps)
$ ls -al grid_subsampling.cpython-35m-x86_64-linux-gnu.so
-rwxr-xr-x 1 <myusername> <myusername> 561056 Mar 13 21:19 grid_subsampling.cpython-35m-x86_64-linux-gnu.so
After some research on the error message it looks like every result is specific to a situation. Though most seem to mention that the error is the result of some sort of permissions issue.
This Unix&Linux Stack answer I think provides the answer to what the actual problem is. But I am a bit too far from my days of working with C++ as an intern in college to necessarily understand how to use it to fix this issue. But I think the issue lies with the permissions between the container and host and between the users on each (that is, root on the container, user (Dockerfile) on the container, root on host, and <myusername> on host).
I have also attempted to first elevate permissions within the container using the root password created in the Dockerfile, then compiling the code, and running the software. But this results in the same issue. I have also tried compiling the code as user in the container, but running the software as root, again with the same issue.
Thus another clue I have found and provide is that there is seemingly something different with the .so when compiled "only within" the container (no --volume) and when it is compiled within the --volume (thus why I attempted to compare the file hashes). So maybe its not so much permissions but how the .so is loaded within the container by the kernel or how its location within the --volume effects that loading process?
EDIT: As for a SSCCE you should be able to clone the linked repository to your machine and use the same Dockerfile. You do not need to specify the /data or /output volumes or alter the code in any way (It attempts to load the .so before loading the data (which will just error and end execution))
If you do not have a GPU or do not want to install nvidia-runtime you should be able to alter the Dockerfile base image to tensorflow:1.12.0-devel-py3 and run the code on CPU.
Your problem is created by the linker trying to dynamically load the library. There could be several root-causes for this:
Permissions. The user should have permission to load the library, so when mounting file systems in docker, the owner id and the group id that are in the host are not necessary the same id in the container although they might be the same name.
Wrong binary format. The host OS is compiling the binary in wrong format. This can happen if you run the compile on (by example) macOS and use it in a linux container.
Wrong mounting. The mounting, by example, with noexec will also prevent the library to be loaded.
Difference in libraries from both environments. Due to the differences of the environment where the library was compiled, you might be missing some libraries, so use ldd grid_subsampling.cpython-35m-x86_64-linux-gnu.so and ldd -r -d -v grid_subsampling.cpython-35m-x86_64-linux-gnu.so check all the libraries that are linked.
I installed Tensorflow on Ubuntu 16.04 LTS following the tutorial given here (with GPU support): Docker Installation for Tensorflow
Managed to run docker with this command:
nvidia-docker run -it -p 8888:8888 -v /home/myusername/notebooks:/notebooks gcr.io/tensorflow/tensorflow:latest-gpu
docker exec -it [my_DOCKER_ID] bash
Once I managed to get into the docker bash successfully, I found that there is tensorflow directory here:
cd /usr/local/lib/python2.7/dist-packages/tensorflow/models/image/mnist/
I proceeded to try the example code and successfully reached Test error of 0.8%:
python convolutional.py
Next, following https://www.tensorflow.org/versions/r0.11/tutorials/mnist/pros/index.html tutorial page, I would like to try mnist_softmax.py. So I cloned tensorflow's package to /notebooks:
cd /notebooks
git clone https://githubcom/tensorflow/tensorflow.git
However, I found problem when running the code:
cd tensorflow/tensorflow/examples/tutorials/mnist/
python mnist_softmax.py --data_dir /notebooks/tensorflow/tensorflow/examples/tutorials/mnist
Traceback (most recent call last):
File "mnist_softmax.py", line 78, in <module>
tf.app.run(main=main, argv=[sys.argv[0]] + unparsed)
TypeError: run() got an unexpected keyword argument 'argv'
At this point I'm pretty clueless whether the error was caused by bad installation or it's because there are steps that I havent done. My questions:
Is my installation complete? I assumed I had a clean installation knowing that I can run docker and get into the docker bash. Plus, I managed to run convolution.py
If I understand Docker correctly, I do not need to clone and build tensorflow package at all?
I had the same problem and it was caused by running tutorial code from a later version (eg v0.12) against an older version of tensorflow which was in my docker container (v0.11 in my case).
The same problem is discussed here: https://github.com/tensorflow/tensorflow/issues/5643
The app.run() method didn't have the argv parameter until v0.12.
On RedHat Enterprise 7, trying to install node.js inside of a nodeenv (0.13.6) in a Python virtual environment (Python 2.7). When I do nodeenv -p, I get OSError: Command make --jobs=2 failed with error code 2...googling, the only reference to this is here. Not super useful for me, because I am already trying to install the newest version of node (4.2.1). Full trace of this is below:
$ nodeenv -p
* Install node (4.2.1..Traceback (most recent call last):
File "/usr/local/pythonenvs/producer/bin/nodeenv", line 11, in <module>
sys.exit(main())
File "/usr/local/pythonenvs/producer/lib/python2.7/site-packages/nodeenv.py", line 891, in main
create_environment(env_dir, opt)
File "/usr/local/pythonenvs/producer/lib/python2.7/site-packages/nodeenv.py", line 732, in create_environment
install_node(env_dir, src_dir, opt)
File "/usr/local/pythonenvs/producer/lib/python2.7/site-packages/nodeenv.py", line 608, in install_node
build_node_from_src(env_dir, src_dir, node_src_dir, opt)
File "/usr/local/pythonenvs/producer/lib/python2.7/site-packages/nodeenv.py", line 577, in build_node_from_src
callit([make_cmd] + make_opts, opt.verbose, True, node_src_dir, env)
File "/usr/local/pythonenvs/producer/lib/python2.7/site-packages/nodeenv.py", line 461, in callit
% (cmd_desc, proc.returncode))
OSError: Command make --jobs=2 failed with error code 2
I then tried to install from prebuilt, using the instructions in this GitHub issue.
nodeenv -p --prebuilt
That seemed to work...
* Install node (4.2.1... done.
* Appending data to /usr/local/pythonenvs/producer/bin/activate
Except nothing actually installed -- tab completing shows no node or npm install (I have deactivated and re-activated the virtual environment):
$ no
nodeenv nohup nologin notify-send
$ np
$ nproc
My other installs worked with the same instructions, so I'm at a loss for debugging this. Any hints or suggestions? If this is a permissions issue, where do I need to set / change them? The user already owns the virtual environment directory...
Okay, so I don't have a solution to the root cause (I suspect some sort of issue / conflict with make on my server), but I managed to get it installed via --prebuilt. I had to manually delete the node.js source from /usr/local/pythonenvs/producer/src/node-v4.2.1/, because the --prebuilt option was trying to copy those as if they were binaries. After deleting the directory, I downloaded / extracted from nodejs.org into the virtual environment's src directory. Then, the nodeenv -p --prebuilt command works fine.
I've been trying to install nodejs on my VPS for a little while now. Since I'm using CentOs 5.6 I had to build it from source.
More so I need the python 2.7 as the default python on my box was 2.4.
I compiled python from source and it was installed successfully in /usr/local/bin/python2.7.
Now the problem is upon issuing make in the nodejs directory it reaches the following exceptions.
.
.
.
LD_LIBRARY_PATH=/root/node/out/Release/lib.host:/root/node/out/Release/lib.tar
get:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../deps/v8/tools/gyp; mkdir -p
/root/node/out/Release/obj/gen; python ../../tools/generate-trig-table.py "/root
/node/out/Release/obj/gen/trig-table.cc"
touch /root/node/out/Release/obj.host/deps/v8/tools/gyp/generate_trig_table.st
amp
LD_LIBRARY_PATH=/root/node/out/Release/lib.host:/root/node/out/Release/lib.tar
get:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../deps/v8/tools/gyp; mkdir -p
/root/node/out/Release/obj/gen; python ../../tools/js2c.py "/root/node/out/Relea
se/obj/gen/libraries.cc" CORE off ../../src/runtime.js ../../src/v8natives.js ..
/../src/array.js ../../src/string.js ../../src/uri.js ../../src/math.js ../../sr
c/messages.js ../../src/apinatives.js ../../src/debug-debugger.js ../../src/mirr
or-debugger.js ../../src/liveedit-debugger.js ../../src/date.js ../../src/json.j
s ../../src/regexp.js ../../src/arraybuffer.js ../../src/typedarray.js ../../src
/weak_collection.js ../../src/promise.js ../../src/object-observe.js ../../src/m
acros.py
File "../../tools/js2c.py", line 387
except Error as e:
^
SyntaxError: invalid syntax
make[1]: *** [/root/node/out/Release/obj/gen/libraries.cc] Error 1
make[1]: Leaving directory `/root/node/out'
make: *** [node] Error 2
Somewhere I read that the Exception syntax has changed from python 2.6 up and I figured it must be using the old python so I did the following but it made no difference:
PYTHON=/usr/local/bin/python2.7
export PYTHON
python2.7 configure && make && make install
Now I'm wondering how should I proceed?
IMO you need to place python2.7 first in path and then run:
export PATH=/usr/local/bin:${PATH}
python2.7 configure && make && make install
If this does not work, probably one of the Python scripts is looking for python. You can probably fix that by symlinking python, something like:
mkdir /tmp/py27
ln -s /usr/local/bin/python2.7 /tmp/py27/python
export PATH=/tmp/py27:${PATH}
python configure && make && make install
Is all caps PYTHON a valid environment variable?
http://www.wellho.net/resources/ex.php4?item=y115/penv.py
I would think you would rather create a sym link to the correct python interpreter.
ln -s /usr/local/bin/python2.7 /usr/local/bin/python
It took the equivalent of a 1/2 day for me to figure this out, so I want to share the Quickfix Engine compile problem I encountered and the solution.
I didn't get a reply from the "Quickfix Engine" help resources pointed to here:
"http://quickfixengine.org/help"... thus another reason I am providing this.
Environment: Fedora 18 -and- CentOS6 (64bit).
After successfully compiling quickfix with Python support (i.e. configure [opts]; make; make install), I got the following python import exception indicating that the python module, "_quickfix", could not be found:
==============================================
user$ python -c "import quickfix"
Traceback (most recent call last):
File " ", line 1, in
File "/home/user/APPS.d/ENTHOUGHT-PYTHON-IDE.d/x86_64.d/latest/lib/python2.7/site-packages/quickfix.py", line 7, in
import _quickfix
ImportError: No module named _quickfix
==============================================
The problem appears to be in the install script invoked by "make install".
The python interpreter is saying that the "_quickfix" module does not exit. As can be seen from the list of files install by "make install" below, there is no "_quickfix.py" file, but there is a reference to a "_quickfix.so" file and a "_quickfix.dylib" file:
/home/user/.local/lib/python2.7/site-packages/_quickfix.dylib -> /home/user/APPS.d/QUICKFIX.d/latest/lib/python/_quickfix.dylib
/home/user/.local/lib/python2.7/site-packages/_quickfix.so -> /home/user/APPS.d/QUICKFIX.d/latest/lib/python/_quickfix.so
/home/user/.local/lib/python2.7/site-packages/quickfix40.py
/home/user/.local/lib/python2.7/site-packages/quickfix41.py
/home/user/.local/lib/python2.7/site-packages/quickfix42.py
/home/user/.local/lib/python2.7/site-packages/quickfix42.pyc
/home/user/.local/lib/python2.7/site-packages/quickfix43.py
/home/user/.local/lib/python2.7/site-packages/quickfix44.py
/home/user/.local/lib/python2.7/site-packages/quickfix50.py
/home/user/.local/lib/python2.7/site-packages/quickfix50sp1.py
/home/user/.local/lib/python2.7/site-packages/quickfix50sp2.py
/home/user/.local/lib/python2.7/site-packages/quickfix.py
/home/user/.local/lib/python2.7/site-packages/quickfix.pyc
/home/user/.local/lib/python2.7/site-packages/quickfixt11.py
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix.la
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix_python.la
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix_python.so.10.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix_python.so.10 -> libquickfix_python.so.10.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix_python.so -> libquickfix_python.so.10.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix.so.14.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix.so.14 -> libquickfix.so.14.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/libquickfix.so -> libquickfix.so.14.0.0
/home/user/APPS.d/QUICKFIX.d/latest/lib/pkgconfig/quickfix.pc
SOLUTION:
The problem is that the first two entries above, which are symbolic links, are broken.
First, the destination directory is incorrect:
/home/user/APPS.d/QUICKFIX.d/latest/lib/python/...
should actually be:
/home/user/APPS.d/QUICKFIX.d/latest/lib/...
So we fix that first:
user$ cd /home/user/.local/lib/python2.7/site-packages
user$ rm _quickfix.so _quickfix.dylib
user$ ln -s /home/user/APPS.d/QUICKFIX.d/latest/lib/_quickfix.so _quickfix.so
user$ ln -s /home/user/APPS.d/QUICKFIX.d/latest/lib/_quickfix.dylib _quickfix.dylib
Next, with destination directory location corrected, the symbolic links are still broken; this time because the file names that they point to in that (just corrected) destination directory don't exist (i.e. "_quickfix.so" and "_quickfix.dylib" don't exist).
After playing around a little, I got things to work by creating those missing files like so:
user$ cd /home/user/APPS.d/QUICKFIX.d/latest/lib
user$ ln -s libquickfix_python.so _quickfix.so
user$ ln -s <???> _quickfix.dylib # Actually I didn't create this one yet. It's not yet clear to me what it should point to. I Will update this post later.
-
Note: Because I compiled QuickFix so that it does not install to the traditional "/usr/local/" directory structure, I had to append my "LD_LIBRARY_PATH" to include: "/home/user/APPS.d/QUICKFIX.d/latest/lib"
With minimal testing, things seem to work now (or at least in the right direction):
user$ python -c "import quickfix"; echo ${?}
0
user$ python -c "import quickfix42"; echo ${?}
0
When I figure out what the second link should be (if it is necessary), or if I should encounter any run-time errors with the corrections I implemented, I'll update/edit this post.
I hope this helps someone.
Noel
Had the same problem in Ubuntu 13.04. configured with python support and used the default destination (/usr/local/...). After successful compilation then worked out a similar solution with the following steps;
Create missing files/symlinks;
cd /usr/local/lib
sudo ln -s libquickfix_python.so _quickfix.so
sudo ln -s _quickfix.so _quickfix.dylib
Change/update existing symlinks to new location:
cd /usr/lib/python2.7/dist-packages/
sudo ln -s /usr/local/lib/_quickfix.so _quickfix.so
sudo ln -s /usr/local/lib/_quickfix.so _quickfix.dylib
Add new library path
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH${LD_LIBRARY_PATH:+:}/usr/local/lib
You do not need to create multiple symlinks - you only need to remove the bad symlinks and create one new symlink for _quickfix.so for everything to work:
rm /usr/local/lib/python2.7/site-packages/_quickfix.dylib
rm /usr/local/lib/python2.7/site-packages/_quickfix.so
ln -s /usr/local/lib/libquickfix_python.dylib /usr/local/lib/python2.7/site-packages/_quickfix.so
This is on OS X. For Linux you will need to use the following (as the dylib extension is OS X specific)
ln -s /usr/local/lib/libquickfix_python.so /usr/local/lib/python2.7/site-packages/_quickfix.so