Dynamic linker fixups

[bnoordhuis]

I've only been able to make this work on Linux so far (see below) and I'm not 100% convinced that linking against a specific .so is a good idea so feedback is welcome.

It only seems to work on OS X when I execute install_name_tool -id @rpath/libocci.dylib /path/to/libocci.dylib first, else -Wl,-rpath,<path> has no effect...

/cc @raymondfeng

[raymondfeng]

For MacOS, we can run install_name_tool as part of the loopback-oracle-build script which creates a tarball including the oracle instant client and our prebuilt binary.

[bnoordhuis]

Apropos nothing, I wonder if this is a bug in the oracle libraries... Changing the call in oracle_bindings.cpp to createConnection("", "", "") produces the same behavior.

==21453== Conditional jump or move depends on uninitialised value(s)
==21453==    at 0x8B36DD6: __intel_sse2_strlen (in /opt/oci/libclntsh.so.12.1)
==21453==    by 0x851021B: kpugemlc (in /opt/oci/libclntsh.so.12.1)
==21453==    by 0x7F392A0: kpusebfc (in /opt/oci/libclntsh.so.12.1)
==21453==    by 0x7F391B0: kpusebf (in /opt/oci/libclntsh.so.12.1)
==21453==    by 0x7F83707: kpuatch (in /opt/oci/libclntsh.so.12.1)
==21453==    by 0x8D9A50D: kpuspsessionget (in /opt/oci/libclntsh.so.12.1)
==21453==    by 0x8C0B388: OCISessionGet (in /opt/oci/libclntsh.so.12.1)
==21453==    by 0xAF2530B: oracle::occi::ConnectionImpl::openConnection(OCIEnv*, OCIError*, void*, unsigned int, void*, unsigned int, void*, unsigned int, void*, unsigned int, unsigned int, void*, unsigned int, oracle::occi::Connection::Purity, oracle::occi::StatelessConnectionPool::PoolType) (in /opt/oci/libocci.so.12.1)
==21453==    by 0xAF2032D: oracle::occi::ConnectionImpl::ConnectionImpl(oracle::occi::EnvironmentImpl*, std::string const&, std::string const&, std::string const&) (in /opt/oci/libocci.so.12.1)
==21453==    by 0xAF1E885: oracle::occi::EnvironmentImpl::createConnection(std::string const&, std::string const&, std::string const&) (in /opt/oci/libocci.so.12.1)
==21453==    by 0x7868208: OracleClient::EIO_Connect(uv_work_s*) (oracle_bindings.cpp:138)
==21453==    by 0x95864C: worker (threadpool.c:74)
==21453==    by 0x94E008: uv__thread_start (uv-common.c:322)
==21453==    by 0x5A69F32: start_thread (pthread_create.c:309)
==21453==    by 0x5D73DEC: clone (clone.S:111)

[bnoordhuis]

For MacOS, we can run install_name_tool as part of the loopback-oracle-build script which creates a tarball including the oracle instant client and our prebuilt binary.

That means it needs a relative RPATH? I assume it's the same for Linux?

[raymondfeng]

Yes, we'll have the following module layout:

node_modules

• strong-oracle
  • build/Release/oracle_bindings.node
• instantclient
  • (dylibs)