[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] [Bug-gnucap] gnucap fails at start due to " ^ ? : can
From: |
al davis |
Subject: |
Re: [Gnucap-devel] [Bug-gnucap] gnucap fails at start due to " ^ ? : cannot open shared object file: No such file or directory" |
Date: |
Thu, 4 Aug 2016 13:57:03 -0400 |
On Thu, 4 Aug 2016 11:00:54 +0200
Felix Salfelder <address@hidden> 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.