New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building cx_Oracle v6 with a system-delivered libodpic.so #103

Closed
jmcp opened this Issue Oct 30, 2017 · 8 comments

Comments

Projects
None yet
3 participants
@jmcp
Copy link

jmcp commented Oct 30, 2017

I'm updating the https://github.com/oracle/solaris-userland integration of cx_Oracle to bring in
v6.x, and observe that as currently written, v6 requires the source of a version of ODPI-C to
be compiled in, rather than allowing for a system- or otherwise-delivered version to be linked
in.

The delivery of ODPI-C for Solaris is going to be packaged per solaris-userland processes
and installed into /usr/lib/ + /usr/lib/$(MACH64), and we'd really rather not have to grab a copy
of ODPI-C's source so we can build cx_Oracle.

These two patch files enable separating out ODPI-C from cx_Oracle; I think it would be worthwhile
to include in cx_Oracle as a general configuration feature.

setup.py.patch.txt
cx_Oracle.c.patch.txt

@cjbj

This comment has been minimized.

Copy link
Member

cjbj commented Oct 30, 2017

Any use of an external ODPI-C library would need to verify its version was compatible with that required by cx_Oracle.

@anthony-tuininga

This comment has been minimized.

Copy link
Member

anthony-tuininga commented Oct 30, 2017

Agreed. ODPI-C does this automatically, however. Taking a quick peek at the patch, I don't think we want to assume that on SunOS a system supplied libodpic.so is available. I realise that you intend to do so, but others may not. The presence of an environment variable such as ODPIC_LIB_DIR might be sufficient. I'll give it some thought and get back to you later.

@cjbj

This comment has been minimized.

Copy link
Member

cjbj commented Oct 30, 2017

Ack.

@jmcp

This comment has been minimized.

Copy link
Author

jmcp commented Oct 30, 2017

I'm happy with the ODPIC_LIB_DIR idea.

@cjbj how would I track the version required? Is there any sort of interface stability guarantee for either ODPI-C or cx_Oracle?

@cjbj

This comment has been minimized.

Copy link
Member

cjbj commented Oct 30, 2017

@jmcp The stated compat is in: https://oracle.github.io/odpi/doc/public_functions/dpiContext.html#c.dpiContext_create

Tracking what versions any driver installed requires is an open question. Are you creating cx_Oracle packages?

@jmcp

This comment has been minimized.

Copy link
Author

jmcp commented Oct 30, 2017

@cjbj yes, I am creating packages. I've currently got ODPI-C v2.0.2 and cx_Oracle 6.0.2 lined up just about ready for integration.

On the topic of interface stability, since I'm thinking of Solaris' way of handling these things I'll take that offline.

@anthony-tuininga

This comment has been minimized.

Copy link
Member

anthony-tuininga commented Mar 31, 2018

@jmcp, I have just added a patch to setup.py that permits building of cx_Oracle with a pre-compiled version of ODPI-C. To do so, you simply need to set the environment variables ODPIC_INC_DIR and ODPIC_LIB_DIR. Once both are set, the values of these variables will be used to locate the dpi.h include file and the libodpic.so shared library and the source will be ignored. I trust that is acceptable to you? Please confirm. Thanks!

@jmcp

This comment has been minimized.

Copy link
Author

jmcp commented Mar 31, 2018

Yes, that works for me. Thankyou!

@jmcp jmcp closed this Mar 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment