Sublime Forum

**dannftk** · September 20, 2024, 7:36am

I have noticed libsqlite3.so be in the package installation pack. I don’t see any binary within the pack that would use this library. Don’t we like to remove it from the pack? Thank you in advance

**jfcherng** · September 20, 2024, 7:44am

Both plugin_host-3.3 and plugin_host-3.8 use it as per ldd's result. I believe that allows people to do import sqlite3 in plugins.

**dannftk** · September 20, 2024, 2:07pm

They use a system’s one prioritely, not a custom from the same directory unlike libssl and libcrypto those are used from the sublime’s directory, pay attention more carefully

**jfcherng** · September 20, 2024, 2:32pm

[test@test-vm sublime_text]$ ldd plugin_host-3.8
linux-vdso.so.1 (0x00007fff8f782000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fec2e02d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fec2e028000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fec2e023000)
libcrypto.so.1.1 (0x00007fec2d400000)
libssl.so.1.1 (0x00007fec2d343000)
libsqlite3.so (0x00007fec2d25b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fec2d172000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fec2dff4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fec2dfef000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec2ce00000)
/lib64/ld-linux-x86-64.so.2 (0x00007fec2e049000)

It would be good if you can elaborate or provide further proof for “pay attention more carefully”. Just for me to learn. Currently, “pay attention more carefully” is just like a simple “no” reply to me.

**deathaxe** · September 20, 2024, 3:28pm

libsqlite3 (on unix) or sqlite3.dll on windows belongs to python batteries and is required for stdlib’s sqlite3 module. Whether the local binary in ST installation folder is used or not may depend on operating system library loading policies. Windows for instance always prefers dlls from trusted system paths and falls back loading local dlls if it doesn’t otherwise find those. As such this library is required for ST’s plugin ecosystem and can not be removed!

**dannftk** · September 20, 2024, 5:11pm

@jfcherng

$ ldd plugin_host-3.8                                                                                                                                                                  	linux-vdso.so.1 (0x00007fcdc70c4000)
	librt.so.1 => /usr/lib64/librt.so.1 (0x00007fcdc68a4000)
	libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007fcdc689f000)
	libutil.so.1 => /usr/lib64/libutil.so.1 (0x00007fcdc689a000)
	libcrypto.so.1.1 => /opt/sublime_text/./libcrypto.so.1.1 (0x00007fcdc6515000)
	libssl.so.1.1 => /opt/sublime_text/./libssl.so.1.1 (0x00007fcdc6458000)
	libsqlite3.so => /usr/lib64/libsqlite3.so (0x00007fcdc627a000)
	libm.so.6 => /usr/lib64/libm.so.6 (0x00007fcdc61ce000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/14/libgcc_s.so.1 (0x00007fcdc61a0000)
	libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007fcdc619b000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007fcdc5fc8000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fcdc70c6000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007fcdc5fa9000)
	libicui18n.so.74 => /usr/lib64/libicui18n.so.74 (0x00007fcdc5c66000)
	libicuuc.so.74 => /usr/lib64/libicuuc.so.74 (0x00007fcdc5a53000)
	libicudata.so.74 => /usr/lib64/libicudata.so.74 (0x00007fcdc3cf4000)
	libc++.so.1 => /usr/lib64/libc++.so.1 (0x00007fcdc3bf1000)
	libc++abi.so.1 => /usr/lib64/libc++abi.so.1 (0x00007fcdc3baa000)
	libunwind.so.1 => /usr/lib64/libunwind.so.1 (0x00007fcdc3b9e000)
	libatomic.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/14/libatomic.so.1 (0x00007fcdc3b94000)

My point is to remove the library from the pack if binaries don’t require exactly this library placed to the pack, or make binaries always refer to this library. The second one will be always the right choice from my point of view. If you deliver some SW independently on a system you need to follow the rule to deliver everything required for this SW to run self-sufficiently

**dannftk** · September 20, 2024, 5:11pm

Also, I would consider static linkage of everything if it doesn’t increase the package size dramatically

**jfcherng** · September 20, 2024, 5:34pm

Probably related to the LD_LIBRARY_PATH env variable.

**deathaxe** · September 20, 2024, 5:57pm

I strongly doubt sublimehq would add unneccesary content which is not absolutely crucial.

FWIW, I can just second Jacks comment about libsqlite3 being used from /opt/sublime_text directory on my Debian 12 box. So it is at least a failsafe fallback.

And seriously, complaining about a 1MB file? Sorry!

**bschaaf** · September 21, 2024, 2:47am

The RUNPATH of the executable is $ORIGIN, so by default it will search for dynamic libraries next to it. Since that’s not happening for you you’ve certainly got an environment variable overriding the default behavior.

Additionally we ship sqlite as a dynamic library so that it can be shared between the 3.3 and 3.8 python processes. This saves on disk space.

**dannftk** · September 22, 2024, 8:55am

I consider it being strange that libcrypto and libssl are resolved with paths where sublime is installed wherein libsqlite3 is resolved with a system’s one. Don’t you think that sublime should work on this discrepancy?
I think that the issue in name, because libcrypso and libssl are delivered with names containing explicit versions at the end, but libsqlite3 is delivered with a name lacking explicit version
I think, if you don’t like to remove libsqlite3.so from the pack you need to deliver it as libsqlite3.so.<major.minor.patch>

**bschaaf** · September 22, 2024, 9:09am

Don’t you think that sublime should work on this discrepancy?

As I said the RUNPATH is already $ORIGIN. There is no discrepancy. Have you checked - as suggested - for environment variables that override the default dynamic library lookup behavior?

libsqlite3 is delivered with a name lacking explicit version
I think, if you don’t like to remove libsqlite3.so from the pack you need to deliver it as libsqlite3.so.<major.minor.patch>

The 3 is sqlite3 is enough for ABI compatibility.

**dannftk** · September 22, 2024, 10:45am

Regardless my environment ldd must show to me that libssl, libcrypto and libsqlite3 are fetched from the $ORIGIN. Either they are ALL loaded from the origin path or are they loaded from the system. This is what I call consistency. You allow SW to play around with the environment in an unexpected way. You should either let it do comprehensively or forbid to do that

**bschaaf** · September 22, 2024, 10:59am

Regardless my environment ldd must show to me that libssl, libcrypto and libsqlite3 are fetched from the $ORIGIN. Either they are ALL loaded from the origin path or are they loaded from the system.

That’s not how anything works. Dynamic libraries are loaded from the available library paths in-order. If you have a LD_LIBRARY_PATH set you’re asking libraries in that path to be prioritized. We have no control over this, this is simply how library loading works under unix. If you don’t like it, use a different operating system.

**dannftk** · September 22, 2024, 11:08am

You don’t understand what I am talking about. You will have control of everything if you had a wish. There has been no wish, therefore there hasn’t been a control.
My LD_LIBRARY_PATH is empty. The issue is in NAME of the library. Select another name, which would never cross any system library name, link binaries against this newly named library and this would be always fetched as expected

**bschaaf** · September 22, 2024, 11:35am

You don’t understand what I am talking about. You will have control of everything if you had a wish. There has been no wish, therefore there hasn’t been a control.

I fully understood you, but as I’ve already stated:

It doesn’t matter due to abi compatibility
This is happening due to a configuration on your system - the RUNPATH is already correct
LD_LIBRARY_PATH is supposed to let you override dynamic libraries

My LD_LIBRARY_PATH is empty.

You can further debug why it’s getting loaded from your system by running LD_DEBUG=libs ldd /opt/sublime_text/plugin_host-3.8

The issue is in NAME of the library. Select another name, which would never cross any system library name, link binaries against this newly named library and this would be always fetched as expected

We’re going to keep calling libsqlite3 libsqlite3, just like we do openssl’s libraries.

**dannftk** · September 22, 2024, 11:51am

openssl libraries are delivered with suffixes comprising versions, libsqlite3 is not. This is the difference
If your goal is to allow a mess due to one’s environment then ok, leave it as it is. But if you wanted to avoid such a mess, you could do something like naming your libraries libst_libsqlite3.so, libst_libcrypto.so, libst_libssl.so and will never (99,9% probability) have any questions what kind of a library is being loaded in any environment. I cannot imagine a fool whom could name their system’s sqlite3.so library with a prefix st_
I cannot understand what you tend to achieve by letting people use their systems’ libraries, if they want, with your software that must refer to specific libraries delivered with the pack

**bschaaf** · September 22, 2024, 12:16pm

This is the last time I’m going to repeat myself on this. If you would like to actually fix this “issue” for yourself please follow the debugging advice in my previous post.

openssl libraries are delivered with suffixes comprising versions, libsqlite3 is not.

libsqlite3 is suffixed. That’s what the 3 is. The openssl libraries with a 1.1 suffix are also present on older systems.

But if you wanted to avoid such a mess, you could do something like naming your libraries libst_libsqlite3.so, libst_libcrypto.so, libst_libssl.so and will never (99,9% probability) have any questions what kind of a library is being loaded in any environment.

Instead we’ll get questions as to why we named those libraries a non-standard way and whether they’re modified in any way and likely get some incompatibilities from python libraries that expect specific names. All to avoid a non-issue with your system setup.

I cannot understand what you tend to achieve by letting people use their systems’ libraries, if they want, with your software that must refer to specific libraries delivered with the pack

There’s plenty of reasons to override the libraries that get loaded. The one I’ve personally used is wanting to debug said library. Which gets significantly more annoying if everyone’s using non-standard names for things.

**dannftk** · September 22, 2024, 1:29pm

My perception, dear friend, that all reasons that you gave in your last post had been thought up on-the-go in order to reason me and prove your personal belief. At least because in the last clause you say that you use such an approach to DEBUG something. I see it weird because we talk about a software for production
And according to what I see you talking about python libraries loading from some paths somehow depending on the path of your binary I could conclude that you try to confuse me and the community. Because everyone who knows how linux works would treat it as ignorance

**jfcherng** · September 22, 2024, 1:29pm

I feel that too. But probably not on the same person.

What is libsqlite3.so in installation package for?