3 ms·

We are using custom build of sqlite (more db columns, returned columns) and for us a ui that either calls some .exe or loads .dll is preffered. My favourite wa

by malkia 12y ago

We are using custom build of sqlite (more db columns, returned columns) and for us a ui that either calls some .exe or loads .dll is preffered. My favourite was SqliteSpy but its statically linked, so had to switch to sqlitebrowser, and compile it with our own custom build of qt5 where "system" sqlite (our custom one) is used. Maybe one good case where DLL/.so/.dylib shine (if only golang... :) )

jbert 12y ago
> Maybe one good case where DLL/.so/.dylib shine (if only golang... :) ) Possibly, but it's mostly only useful if you can't recompile the app (i.e. don't have source). And in that case, you've probably paid money for it, and want support. Which you won't get if you've swapped out a component for one it wasn't tested with. [But I agree with your general point. DLL search path/LD_LIBRARY_PATH can be a useful 'speed hack' to drop in a different lib with an identical API and minor tweaks. e.g. overload malloc/free/realloc() in some misbehaving app to trace a problem without recompiling.]