[Development] OS X plugin naming bug

[Thiago Macieira]

On Friday 14 November 2014 13:49:25 Hanspeter Niederstrasser wrote:
> > I don't understand your answer.
> > 
> > You're saying that nothing has linked to the Qt plugins. Well, of course.
> > By
> > definition, a plugin is something you don't link to.
> 
> Right. I guess I was just restating the obvious difference to dylibs,
> where file name (technically the install_name) continuity is important and
> is hardcoded into the application that links to that library.

That's not what I meant. A library is something you link to, a plugin you 
don't. The fact that a plugin and a library are backed by the same type of file 
is irrelevant. It's also irrelevant if you can technically perform the link to 
a plugin -- the fact is that you shouldn't, since it doesn't provide an API 
for that.

> > Yet that has nothing to do with either problem I listed. In specific for
> > user
> > plugins, if the file name were to change, the application code may fail to
> > find it.
> 
> I don't think this would happen.  dlopen searches paths for a compatible
> file.  It doesn't search for a specific file name.

Please confirm that this would work:

	dlopen("/path/to/plugins/myplugin.dylib", RTLD_LAZY);

Will it open the plugin called "myplugin" the way you're recommending?

Also, you're forgetting deployment scripts and other plugin-scanning tools. 
This is not just about dlopen.

I stand by my recommendation: opt-in.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center