custom sqlite3 as a shared library. use of -Wl,-rpath=

[jeromew]

Hello,

I have been struggling with a segfault when trying to use an sqlite fts extension that I found here : https://github.com/illarionov/sqlite3-unicodesn

The extension worked like a charm when I compiled it direcly against my compiled sqlite3 ; but when I used it with node-sqlite3 it segfaulted.

At first I thought it was an sqlite version compatibility issue so I recompiled the extension against the sqlite3 packaged with node-sqlite3. Still a segfault.

It was weird because the fts4_rank extension mentioned on node-sqlite3 website ran ok with the same build chain.

I tried to compile both node-sqlite3 and my extension with the same sqlite3 as a static library. It worked better but segfaulted later because the global sqlite3Config variable was initialized in one static sqlite3 but not in the other.

At this point it was clear I needed to have both node-sqlite3 & my extension built against the same sqlite, but both using sqlite3 as a shared library.

After a while, I found and decided to use the --build-from-source combined with the --sqlite= option. This chain make sqlite3 used as a shared library.

It worked a bit better, node-sqlite3 was not crashing anymore.
Nevertheless when executing a query against the tokenizer it was complaining :
{ [Error: SQLITE_ERROR: no such module: fts4] errno: 1, code: 'SQLITE_ERROR' }

My system is a CentOS 6.x and node-sqlite3 was using at runtime the libsqlite3.so of the system instead of my custom sqlite3 (the system has an old version of sqlite)

So I needed to have node-sqlite3 use at runtime my custom sqlite3 library.

This was solved by adding a :

'conditions': [ [ 'OS!="mac"', {'libraries+':['-Wl,-rpath=<@(sqlite)/lib']} ] ](inspired from https://github.com/couchbase/couchnode/blob/master/binding.gyp)

in the "external" condition of the binding.gyp

now everything is working fine :-)

I am wondering if this rpath= linker flag should not be committed to binding.gyp. I don't see a reason why people would like to link against their own version of sqlite3 at compile time with the --sqlite flag and not link with this version also at runtime.

currently my node-sqlite3 install process is :

npm install --build-from-source --sqlite=/path/to/custom/sqlite3 sqlite3
edit binding.gyp internal to add the new line above
npm rebuild --build-from-source --sqlite=/path/to/custom/sqlite3 sqlite3

if you could add the rpath 'libraries+' line in the binding.gyp, the install process could be streamlined to just

npm install --build-from-source --sqlite=/path/to/custom/sqlite3 sqlite3

Tell me if you think you could accept this modification to binding.gyp ("external" branch).

ps: congrats on the binding implementation ! modern c++ as advertised :-)

[springmeyer]

Your proposed modification seems fine, and the logic behind it. However, it would be useful to learn more about why dynamic linking was finding the system libsqlite3.so instead of your custom libsqlite3.so. So, can you step back/remove the workaround, do a build and then run:

ldd lib/binding/*/*/*node

This will show how the module actually linked at build time. If --sqlite=/path/to/custom/sqlite3 is correct it should be pointing at your custom build. If at runtime you still see crashes, then this is curious. It may be that /path/to/custom/sqlite3/lib needs to be added to your /etc/ld.so.conf. Using rpath works around a properly configured ld.so.conf but my understanding is that if you have custom library locations (outside /usr/lib or /usr/local/lib) then modifying ld.so.conf is the proper solution.

[jeromew]

output from ldd without the rpath

ldd node_modules/sqlite3/lib/binding/Release/node-v11-linux-x64/node_sqlite3.node
linux-vdso.so.1 => (0x00007fff373b8000)
libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007f17172a4000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f1716f9e000)
libm.so.6 => /lib64/libm.so.6 (0x00007f1716d19000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f1716b03000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f17168e6000)
libc.so.6 => /lib64/libc.so.6 (0x00007f1716552000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f171634e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1717759000)

it seems to me that ldd shows the runtime linkage and not the compile time linkage (for example if i use ldd on my -rpath'ed version it show /path/to/custom/sqlite3/lib/libsqlite.so.0 but if I rename /path/to/custom/sqlite3 to /path/to/custom/sqlite4 then ldd shows /usr/lib64/libsqlite3.so.0 without a recompilation)

I could indeed modify /etc/ld.so.conf but i would prefer avoiding it because I am trying to sandbox as much as i can per "autonomous" micro-application + it needs root access ; the tradeoff is that with a fixed path (rpath) the application cannot be moved easily.

found this page on shared library solutions : http://www.eyrie.org/~eagle/notes/rpath.html ; my case probably fits into the "rare custom case" so ld.so.conf seems the way to go.

do you see an acceptable way to add rpath configurability in the project or should I try and rely only on ld.so.conf ?

[jeromew]

Just for the record it works when adding /path/to/custom/sqlite3 to /etc/ld.so.conf + ldconfig ; I am still not totally confident with such a potentially system wide modification when using bleeding edge sqlite versions so I would prefer using rpath if you agree on a way to make it configurable.

Tell me what you think.

[springmeyer]

it works when adding /path/to/custom/sqlite3 to /etc/ld.so.conf + ldconfig

Thanks for confirming. The non-root alternative solution is export LD_LIBRARY_PATH=/path/to/custom/sqlite3/lib/ so that will likely work as well.

But, overall I'm happy with rpath approach. I think it is best and binding.gyp is the right place to do this, so let me know if you can muster a pull request. It will need to be conditional on linux being the OS. Conditionals in gyp are tricky. I can take a look at this next week if you don't get to it.

[jeromew]

I have yet to learn how to add a PR directly to an existing issue, but you'll find a proposed PR for the rpath option in #225.
I tested the conditional by changing the test string and a brand new sqlite directory (no ld.so.conf on this one)

• "linux" ok ldd *.node points to the custom sqlite3
• "fake" ok ldd *.node points to the system sqlite3

[springmeyer]

#225