bug#65541 - shows that we have a packaging problem around version skew in plugins. We could try to solve this with some EPM dependency line - but that's likely to be more difficult than adding a generally useful version check.
is the magic that loads our GUI backends; we should check for another symbol here and fail if it is not present, and export it in the same way (don't forget the SAL_DLLPUBLIC_EXPORT macros (or their per-backend equivalents)) for:
git grep create_SalInstance
or whatever. We should implement that method in each of the modules [ ie. having a shared impl. in vcl/ will not cut it ;-].
Include <config_version.h> from core/config_host/ and just return a const char* containing LIBO_VERSION_DOTTED - would do the trick I think.
The of course some code to check for that; and (ideally) - we would warn on STDERR as soon as we saw that, and queue up a message dialog to show with "ShowNativeDialog" later - as/when/if we found a valid backend.
I'm not convinced this makes sense. tryInstance (vcl/unx/generic/plugadapt/salplug.cxx) expects the plugin to load directly next to the vcl lib (i.e., inside the LO installation's program directory). It is not like it is trying to load it from some arbitrary place whose content is not assumed to be under the control of the LO installation. It is really a packaging system's fault if one can end up with such a screwed up LO installation. (You would not want to add programmatic version checks for all the other libs in the LO installation's program directory, would you?)
Well - it is always nice to have belt + braces; if this causes horrible, hard-to-detect and un-anticipated side-effects I'd like to check it if we can do so easily (which we can). Unfortunately we don't have control over all packagers out there - and heisenbugs are particularly awful. And yes - if it was quick & easy to check builtin UNO components were of the right version it'd be a nice opportunity to throw a DeploymentException ;->
As for fixing EPM to add that dependency - please do go for it if you want - I for one hate that thing profoundly - it would be good to have a fix there too so no users ever see this again :-)
(In reply to comment #2)
> Well - it is always nice to have belt + braces;
The problem is how to handle the information that the installation set is apparently broken. If you silently ignore the bad VCL plugin, this will simply shift problems to later, not help solve them.
> As for fixing EPM to add that dependency - please do go for it if you want -
> I for one hate that thing profoundly - it would be good to have a fix there
> too so no users ever see this again :-)
Always go for fixing the root cause (cf. bug 65541 comment 13), regardless of how profoundly you hate it, I would say.
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Removing comma from whiteboard (please use a space to delimit values in this field)
Migrating Whiteboard tags to Keywords: (EasyHack,DifficultyBeginner,SkillCpp,TopicCleanup)
Remove LibreOffice Dev List from CC on EasyHacks
(curtailing excessive email to list)