Hi,
When i compile my plugins under vdr 1.4.7 most of them get the versionnumber 1.4.5. For example: libvdr-ttxtsubs.so.1.4.5. The result of this is that i get the following errormessage when i try to launch: vdr: ./PLUGINS/lib/libvdr-ttxtsubs.so.1.4.5: cannot open shared object file: No such file or directory
My solution to this problem is 'ln -s ibvdr-ttxtsubs.so.1.4.7 ibvdr-ttxtsubs.so.1.4.5'.
However, that seems more like a workaround. Is there a clean solution to this? Thanks! -Alex
alex bustamante wrote:
Hi,
When i compile my plugins under vdr 1.4.7 most of them get the versionnumber 1.4.5. For example: libvdr-ttxtsubs.so.1.4.5. The result of this is that i get the following errormessage when i try to launch: vdr: ./PLUGINS/lib/libvdr-ttxtsubs.so.1.4.5: cannot open shared object file: No such file or directory
My solution to this problem is 'ln -s ibvdr-ttxtsubs.so.1.4.7 ibvdr-ttxtsubs.so.1.4.5'.
However, that seems more like a workaround. Is there a clean solution to this? Thanks!
The 1.4.5 is the APIVERSION of VDR 1.4.7 [1], so the name is okay. The "cannot open shared object file: No such file or directory" usually means that some library the plugin is linked against is missing. You can try running: ldd libvdr-ttxtsubs.so.1.4.5
to see if any libraries are missing, though it seems unlikely in this case.
[1] I would've preferred using a completely separate numbering scheme for the APIVERSION, unrelated to VDR version, so that this kind of confusion could've been avoided.
On 07/10/07 20:46, Anssi Hannula wrote:
... The 1.4.5 is the APIVERSION of VDR 1.4.7 [1],...
[1] I would've preferred using a completely separate numbering scheme for the APIVERSION, unrelated to VDR version, so that this kind of confusion could've been avoided.
Originally VDR had only one version number, and that was used for VDR itself and to indicate the plugin versions to use for that version of VDR.
Then people complained that they had to recompile all plugins with every new version of VDR, even if no interface had been changed. That's why a separate APIVERSION has been introduced, indicating the version of the plugin API. Naturally, that APIVERSION was related directly to the VDRVERSION. I don't see why using a completely different versioning system here would avoid confusion If people want to get confused, they'll get confused, anyway.
The only thing that would really make sense to me would be to drop the whole APIVERSION thing and get back to a single VDRVERSION again.
Klaus
-
alex bustamante -
Anssi Hannula -
Klaus Schmidinger