subversion: use sqlite from MacOS #76970
Conversation
This fixes a problem when using the JavaHL library from Eclipse where the system version of the sqlite dependency is loaded instead of the Homebrew version. Building and using the system sqlite resolves the problem.
BrewTestBot
added
java
Yosemite: 3.8.5 Looks like subversion requires 3.8.2 or later so this should work for everything. |
|
I have confirmed with this change the library works correctly and the problem is gone. That aside ... in terms of trying to diagnose the root cause. The installed library without this change looks fine to me: If I sample Eclipse from Activity Monitor I can see that it has loaded the system version of the sqlite library before I have even used SVN. When I do something that causes the SVN JavaHL load, it looks like it tries to load the Homebrew sqlite but the system one still is used? Maybe this is a sqlite thing where two versions of the library cannot be loaded? So maybe the root issue is that something in Eclipse is using CoreData and that prevents using another sqlite from the same process? A workaround I have used that worked was to launch Eclipse from a terminal after first running |
@carlocab Eclipse is a java app. The Subclipse plugin uses JNI to load the JavaHL library that library then loads its dependencies using the OS. JNI does not provide any mechanism to control how the library will load its dependencies. On Windows, we are able to use a trick of the OS to use JNI to preload all of the dependencies in reverse order. This allows us to use JNI to find the library and then as each library loads and tries to load its dependency since it is already loaded in memory it is able to use that version. This trick does not work on Linux or MacOS though and we have to rely on how the OS loads dependencies. I suspect the issue might be that you just cannot load multiple versions of sqlite in the same process. Maybe Eclipse recently started using CoreData somewhere? |
@Bo98 my main concern would be DB compatibility. Imagine a svn command line user checks something out with current version. So they have a sqlite 3.35.5 database created in their working copy. Now we change the CLI to use the system sqlite. Will that older version be able to read the database that was originally created with a newer version? On Big Sur (3.32.3) the answer is yes from what I can tell. Maybe that is true for all of these versions (thanks for providing them by the way). I am just not sure if that is the case or not. |
Seems to me that JavaHL should know how to find its own libraries. Either that, or the order it searches paths is wrong. |
That is what I am attempting to show in the output from otool and the activity monitor sample. The best I can tell the JavaHL library is correct and it does know how to load the dependencies. That is why I am suspect it is something specific about sqlite itself and the fact that the system version of the library has already been loaded by some other Eclipse plugin. I am just guessing though. |
|
Have you looked at the output from starting Eclipse with |
Yeah, in general loading two versions of a library ends up to bad things so I'm not surprised. dyld probably tries to prevent this. Indeed, CoreData uses system sqlite so anything linking to CoreData should by connection also link to system sqlite, which is where the mismatch comes in if linking to brewed subversion with its brewed sqlite. |
I was not aware of this option, it will be handy in the future, but yes it just shows the same information I got from Activity Monitor. I can see that JavaHL loads the correct Homebrew dependencies, I guess the one loaded by CoreData just takes precedence. |
In this case, I think using system |
I have been doing some research and from what I can tell this should not be a problem as the sqlite file format should be both backwards and forwards compatible. I think we should try to make this change. |
|
I realize this could be a controversial change .. what more needs to be discussed to make a decision on approving or closing it? |
|
bump ... is there anything more I can do for this to help? |
|
I do not mind being pinged, and I tried to see if anyone in the Subversion community had concerns and did not hear anything. |
|
🤖 A scheduled task has triggered a merge. |
This fixes a problem when using the JavaHL library from Eclipse where
the system version of the sqlite dependency is loaded instead of the
Homebrew version. Building and using the system sqlite resolves the
problem.
brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting?brew test <formula>, where<formula>is the name of the formula you're submitting?brew audit --strict <formula>(after doingbrew install <formula>)?I do not feel great about this change since subversion has used the sqlite dependency from Homebrew "forever". I have not been able to figure out the root cause for this problem. I first noticed it when upgrading an Intel Mac to Big Sur so I think it is related to that, but ISTR Homebrew 3.0 happened around the same time.
I suspect this problem only happens from Eclipse but cannot be sure. Big Sur includes a reasonably recent version of sqlite so I do not really mind using that version, but I cannot speak to Mojave and Catalina.
Finally .. this is the error as reported by JavaHL: