Re: [Bug-gnucap] gnucap fails at start due to " ^ ? : cannot open shared object file: No such file or directory"

On Thu, 4 Aug 2016 11:00:54 +0200
Felix Salfelder <[email protected]> wrote:

> (moving to -devel)
> 
> On Thu, Aug 04, 2016 at 01:15:08AM -0400, al davis wrote:
> > If I change the name back to libgnucap-default-plugins.so everywhere it
> > works.
> 
> similarly, i have seen people add "." to PATH, to make it "work".
> no, really.
> 
> a plugin is *not* a library, and we should not trick dlopen that way.
> neither should plugins be put into the library dir, because that means
> extra hassle for package maintainers.

I agree.

> 
> > ok ...  I thought the path was the same as for libraries,
> 
> that's what i had assumed when i made the change. yet i never used
> gnucap without an RPATH set and never installed plugins next to the
> libraries. (see the autotools branch for an ad-hoc standard
> implementation.)
> 
> anyway i didn't notice. (sorry about that).

This is one reason that proper testing means to install on a bare
system.  A lot of bugs slip by because we all test on systems we have
personalized.

> > The fix coming turns out to be needed by multiload anyway ...  Gnucap
> > needs an explicit search path for plugins.
> 
> but that should be a plugin, no? (maybe the other way around?)

It is!

> currently there are no "optional" default plugins in main... oO

There really are, and to enhance that is a change I want to make.

The only reason c_attach.cc is in lib and not in apps is that it is
needed to load any plugins.  

Then, really, everything in gnucap-default-plugins is optional.


> 
> is that similar to making readline optional? i mean, if any of this
> will be a plugin, it still should not be an extension "pack", but rather
> be part of default-plugins (optionally).

I agree.  Readline should be a plugin.  There are some things that are
less than ideal only because they were that way long ago and nobody has
had the time to fix it.

> (no i don't have a good solution, perhaps the selection should be done
> by ./configure? other people in other projects use menuconfig for that
> task. very likely overkill here.)

Perhaps.  It needs to be done plain first.