6

I am having a problem with executing a script. I have a number of inherited scripts which I need to figure out how to run. Please see some background and the problem below:

The code has been transferred from an old environment (where the whole process runs fine) to a new environment. This is where the problems have started. Please see below for a cut down version of the file tree. It is a very large project so I can't post the entire tree, but hopefully this is the part that I need help with.

The uncompiled code tree:

├── dao
│   ├── cythonlib
│   │   ├── cyrandom.c
│   │   ├── cyrandom.cpython-35m-darwin.so
│   │   ├── cyrandom.pxd
│   │   ├── cyrandom.pyx
│   │   ├── __init__.py
│   │   ├── _random.pxd
│   │   └── src
│   │       └── _random.c
├── merlin
│   ├── cmdopt.py
│   ├── __init__.py
│   ├── instrument.py
│   ├── mktdata.py
│   ├── overview.py
│   ├── pair.py
│   ├── portfolio.py
│   ├── src
│   │   ├── MerlinLogic.cpp
│   │   └── MerlinLogic.hpp
│   ├── stratconfig.py
│   ├── tradega.cpp
│   ├── tradega.cpython-35m-darwin.so
│   ├── tradega.pxd
│   ├── tradega.pyx
│   ├── tradelogic.cpp
│   ├── tradelogic.cpython-35m-darwin.so
│   ├── tradelogic.pxd
│   ├── tradelogic.pyx
│   ├── tradeopt.py
│   ├── utils.py
│   ├── var.py
│   └── wrtconfig.py
├── merlin_cprofile.sh
└── merlin.py

The compiled tree:

strat
├── dao
│   ├── cythonlib
│   │   ├── cyrandom.cpython-35m-x86_64-linux-gnu.so
│   │   └── __init__.pyc
├── merlin
│   ├── cmdopt.pyc
│   ├── __init__.pyc
│   ├── tradega.cpython-35m-x86_64-linux-gnu.so
│   ├── tradelogic.cpython-35m-x86_64-linux-gnu.so
│   ├── tradeopt.pyc
│   ├── utils.pyc
│   ├── var.pyc
│   └── wrtconfig.pyc
├── merlin.pyc
└── merlin.sh

The merlin.pyc script is called and from there various other scripts in the merlin directory are executed.

Part of the way through the process I get the error:

Traceback (most recent call last):
  File "strats/merlin.py", line 13, in <module>
  File "strats/merlin/tradeopt.py", line 11, in <module>
ModuleNotFoundError: No module named 'merlin.tradelogic'

The new environment is running python version

[user@localhost mktdata.out]$ python --version
Python 2.7.15

Where as the old environment was running python version:

Python 3.5.3

In the new environment I am running gcc version:

[user@localhost mktdata.out]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.3.1 20180712 (Red Hat 7.3.1-6) (GCC)  

In the new environment I am running g++ version:

[user@localhost mktdata.out]$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.3.1 20180712 (Red Hat 7.3.1-6) (GCC) 

Forgive my ignorance, but is the problem that I need to recompile using Python 2.7.15 tradelogic.cpython-35m-darwin.so and tradega.cpython-35m-darwin.so so my new environment which uses python version (2.7.15) can read them? If correct would I need to compile tradelogic.cpp and tradega.cpp in order to obtain the two new .so files?

If this is not the case, what do I need to do in order to fix my problem?

halfer
  • 19,824
  • 17
  • 99
  • 186
Stacey
  • 4,825
  • 17
  • 58
  • 99
  • 1
    Hi @Stacey, your conclusion at the bottom is exactly right: those `x.cpython-35m-...` shared objects can only work with CPython 3.5. If you need to import them in 2.7, you will indeed need to recompile your `.cpp`s them against that version. – jelford Mar 08 '19 at 18:38
  • 1
    You need to recompile your sources against *Python 2.7* (or maybe download the prebuilt binaries - if available somewhere). I don't know how things are on *OSX* (this might be a stupid statement), but you might need the *Python 2.7* devel package installed. Allow me to express my astonishment about the fact that the "old" env uses *Python 3.5* and the new one *Python 2.7* (which will reach its end of life at the end of this year!!!). Things should be the other way around. Check https://stackoverflow.com/questions/45093811/installing-pygraphviz-on-windows-10-64-bit-python-3-6/54890705#54890705 – CristiFati Mar 11 '19 at 10:19
  • In order to build the 2 *.cpp* files you need to run your package's *setup.py* with *Pyhon 2*. Assuming that you have all the dependent packages they need installed. Usually `python2 setup.py build` would generate everything you need in the *build* dir, but without further details about your package it's hard to tell. – CristiFati Mar 12 '19 at 16:52
  • In this case you'll probably want the `--inplace` option as well, that way it will place the shareable object file in the same folder as the source. – Dillon Davis Mar 14 '19 at 04:00

0 Answers0