I noticed that some of the shared objects created in ./PLUGINS/lib have a name like libsubvdr-*.so.$(APIVERSION). (from softdevice plugin). The following changes to the Makefile are required for proper installation and cleanup:
--snip--
# Plugins:
install-plugins: plugins - @cp $(PLUGINDIR)/lib/libvdr-*.so.$(APIVERSION) $(PLUGINLIBDIR) + @cp $(PLUGINDIR)/lib/*.so.$(APIVERSION) $(BINDIR)/$(PLUGINLIBDIR)
# Source documentation:
--snip--
@@ -191,7 +191,7 @@
clean-plugins: @for i in `ls $(PLUGINDIR)/src | grep -v '[^a-z0-9]'`; do $(MAKE) -C "$(PLUGINDIR)/src/$$i" clean; done - @-rm -f $(PLUGINDIR)/lib/libvdr-*.so.$(APIVERSION) + @-rm -f $(PLUGINDIR)/lib/*.so.$(APIVERSION)
# Install the files:
--snip--
BR.
C.Y.M wrote:
I noticed that some of the shared objects created in ./PLUGINS/lib have a name like libsubvdr-*.so.$(APIVERSION). (from softdevice plugin). The following changes to the Makefile are required for proper installation and cleanup:
--snip--
# Plugins:
install-plugins: plugins
@cp $(PLUGINDIR)/lib/libvdr-*.so.$(APIVERSION) $(PLUGINLIBDIR)
@cp $(PLUGINDIR)/lib/*.so.$(APIVERSION) $(BINDIR)/$(PLUGINLIBDIR)# Source documentation:
--snip--
Sorry, I had another change in there. Ignore "BINDIR".
--snip--
# Plugins:
install-plugins: plugins - @cp $(PLUGINDIR)/lib/libvdr-*.so.$(APIVERSION) $(PLUGINLIBDIR) + @cp $(PLUGINDIR)/lib/*.so.$(APIVERSION) $(PLUGINLIBDIR)
# Source documentation:
--snip--
BR.
C.Y.M wrote:
I noticed that some of the shared objects created in ./PLUGINS/lib have a name like libsubvdr-*.so.$(APIVERSION). (from softdevice plugin). The following
Why does the softdevice plugin create such files in the first place? What is it with the 'sub' part?
Klaus
changes to the Makefile are required for proper installation and cleanup:
--snip--
# Plugins:
install-plugins: plugins
@cp $(PLUGINDIR)/lib/libvdr-*.so.$(APIVERSION) $(PLUGINLIBDIR)
@cp $(PLUGINDIR)/lib/*.so.$(APIVERSION) $(BINDIR)/$(PLUGINLIBDIR)# Source documentation:
--snip--
@@ -191,7 +191,7 @@
clean-plugins: @for i in `ls $(PLUGINDIR)/src | grep -v '[^a-z0-9]'`; do $(MAKE) -C "$(PLUGINDIR)/src/$$i" clean; done
@-rm -f $(PLUGINDIR)/lib/libvdr-*.so.$(APIVERSION)
@-rm -f $(PLUGINDIR)/lib/*.so.$(APIVERSION)# Install the files:
--snip--
Klaus Schmidinger wrote:
C.Y.M wrote:
I noticed that some of the shared objects created in ./PLUGINS/lib have a name like libsubvdr-*.so.$(APIVERSION). (from softdevice plugin). The following
Why does the softdevice plugin create such files in the first place? What is it with the 'sub' part?
Yah, I'm not sure about that. I just see this in the softdevice Makefile:
# if you want output methods build as a single lib comment the following line USE_SUBPLUGINS = 1
BR.
C.Y.M wrote:
Klaus Schmidinger wrote:
C.Y.M wrote:
I noticed that some of the shared objects created in ./PLUGINS/lib have a name like libsubvdr-*.so.$(APIVERSION). (from softdevice plugin). The following
Why does the softdevice plugin create such files in the first place? What is it with the 'sub' part?
Yah, I'm not sure about that. I just see this in the softdevice Makefile:
# if you want output methods build as a single lib comment the following line USE_SUBPLUGINS = 1
Well, I'd say that's problem of that particular plugin, then. The VDR plugin naming convention is clearly defined in PLUGINS.html under "The plugin directory structure".
Klaus
On Sonntag 14 Mai 2006 17:58, Klaus Schmidinger wrote:
C.Y.M wrote:
I noticed that some of the shared objects created in ./PLUGINS/lib have a name like libsubvdr-*.so.$(APIVERSION). (from softdevice plugin). The following
Why does the softdevice plugin create such files in the first place? What is it with the 'sub' part?
Hm, thats because we have (optionally) a separate lib for each output method, and we do load them dynamic. The reason for this is, that all methods could be build (on a build system), but not all additional libs required for a specific output method need to be present at a target system. Sound complicated.
When linking all into one plugin lib, all libs must be present. But now libvdr-softdevice.so.1.4.0, has no reference to X11 libs or DirectFB libs.
Perhaps we should make the 'sub', part of plugin name, but then vdr tries to load such a lib as a plugin 'vdr -h' I guess.
Stefan Lucke wrote:
On Sonntag 14 Mai 2006 17:58, Klaus Schmidinger wrote:
C.Y.M wrote:
I noticed that some of the shared objects created in ./PLUGINS/lib have a name like libsubvdr-*.so.$(APIVERSION). (from softdevice plugin). The following
Why does the softdevice plugin create such files in the first place? What is it with the 'sub' part?
Hm, thats because we have (optionally) a separate lib for each output method, and we do load them dynamic. The reason for this is, that all methods could be build (on a build system), but not all additional libs required for a specific output method need to be present at a target system. Sound complicated.
When linking all into one plugin lib, all libs must be present. But now libvdr-softdevice.so.1.4.0, has no reference to X11 libs or DirectFB libs.
Perhaps we should make the 'sub', part of plugin name, but then vdr tries to load such a lib as a plugin 'vdr -h' I guess.
Well, if a plugin needs further dynamically loaded libs of its own, I guess it is indeed the easiest way to just copy them into the same directory as the plugin's own file.
However, I'm not too happy with the "sub" naming convention.
How about, if a plugin named 'foo' needs its own lib 'bar', we name the files
libvdr-foo.so.1.4.0 <-- the 'foo' library called by VDR libfoo-bar.so.1.4.0 <-- the 'bar' library called by 'foo'
(of course 'foo' can have any number of 'bar's).
Ok, basically it doesn't matter if VDR's Makefile just copies $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION), but it's always good to have a common naming convention, and I'd like to document this in PLUGINS.html.
Klaus
On Montag 15 Mai 2006 18:06, Klaus Schmidinger wrote:
Stefan Lucke wrote:
On Sonntag 14 Mai 2006 17:58, Klaus Schmidinger wrote:
C.Y.M wrote:
I noticed that some of the shared objects created in ./PLUGINS/lib have a name like libsubvdr-*.so.$(APIVERSION). (from softdevice plugin). The following
Why does the softdevice plugin create such files in the first place? What is it with the 'sub' part?
Hm, thats because we have (optionally) a separate lib for each output method, and we do load them dynamic. The reason for this is, that all methods could be build (on a build system), but not all additional libs required for a specific output method need to be present at a target system. Sound complicated.
When linking all into one plugin lib, all libs must be present. But now libvdr-softdevice.so.1.4.0, has no reference to X11 libs or DirectFB libs.
Perhaps we should make the 'sub', part of plugin name, but then vdr tries to load such a lib as a plugin 'vdr -h' I guess.
Well, if a plugin needs further dynamically loaded libs of its own, I guess it is indeed the easiest way to just copy them into the same directory as the plugin's own file.
However, I'm not too happy with the "sub" naming convention.
How about, if a plugin named 'foo' needs its own lib 'bar', we name the files
libvdr-foo.so.1.4.0 <-- the 'foo' library called by VDR libfoo-bar.so.1.4.0 <-- the 'bar' library called by 'foo'
That sounds reasonable. It would translate for softdevice to: vdr's plugin: libvdr-softdevice.so.1.4.0 our sub-libs: libsoftdevice-[xv|fb|dfb|vidix|shm].so.1.4.0
The only intention for 'libsubvdr' was not to match as as a plugin. Your suggestion looks better.
Is it possible to get acces to the path name specified with -L option ?
vdr -L SEARCH_PATH -P "softdevice -L OTHER_SEARCH_PATH"
So in case these paths are the same, it would be nice to drop one argument for softdevice.
(of course 'foo' can have any number of 'bar's).
Ok, basically it doesn't matter if VDR's Makefile just copies $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION), but it's always good to have a common naming convention, and I'd like to document this in PLUGINS.html.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Stefan Lucke wrote:
Is it possible to get acces to the path name specified with -L option ?
vdr -L SEARCH_PATH -P "softdevice -L OTHER_SEARCH_PATH"
So in case these paths are the same, it would be nice to drop one argument for softdevice.
cPluginManager::directory. Unfortunately this is private. There's currently no way to get access to it without dirty tricks. (see proxy plugin on how to do it anyway ;) )
Cheers,
Udo
On Tue, 2006-05-16 at 03:52 +0200, Udo Richter wrote:
Stefan Lucke wrote:
Is it possible to get acces to the path name specified with -L option ?
vdr -L SEARCH_PATH -P "softdevice -L OTHER_SEARCH_PATH"
So in case these paths are the same, it would be nice to drop one argument for softdevice.
cPluginManager::directory. Unfortunately this is private. There's currently no way to get access to it without dirty tricks. (see proxy plugin on how to do it anyway ;) )
Or try something like:
char *GetLibPath(void) { Dl_info info; char *libpath, *pt; static int my_marker = 0;
if(!dladdr((void *)&my_marker, &info)) { printf("Error: dladdr() returned false (%s)", dlerror()); return NULL; } printf("Plugin file is %s", info.dli_fname);
libpath = strdup(info.dli_fname); if(NULL != (pt=strrchr(libpath, '/'))) *(pt+1) = 0;
printf("Plugin path is %s", libpath); return libpath; }
- Petri
On Dienstag 16 Mai 2006 17:15, Petri Hintukainen wrote:
On Tue, 2006-05-16 at 03:52 +0200, Udo Richter wrote:
Stefan Lucke wrote:
Is it possible to get acces to the path name specified with -L option ?
vdr -L SEARCH_PATH -P "softdevice -L OTHER_SEARCH_PATH"
So in case these paths are the same, it would be nice to drop one argument for softdevice.
cPluginManager::directory. Unfortunately this is private. There's currently no way to get access to it without dirty tricks. (see proxy plugin on how to do it anyway ;) )
Or try something like:
char *GetLibPath(void) { Dl_info info; char *libpath, *pt; static int my_marker = 0;
if(!dladdr((void *)&my_marker, &info)) { printf("Error: dladdr() returned false (%s)", dlerror()); return NULL; } printf("Plugin file is %s", info.dli_fname);
libpath = strdup(info.dli_fname); if(NULL != (pt=strrchr(libpath, '/'))) *(pt+1) = 0;
printf("Plugin path is %s", libpath); return libpath; }
Thanks, thats it. I guess its some sort of RTFM, but that is exactly what I was looking for. Could drop now -L option.
-
C.Y.M -
Klaus Schmidinger -
Petri Hintukainen -
Stefan Lucke -
Udo Richter