Re: [Gnucap-devel] plugpath branch

[al davis]

On Wed, 25 Jan 2017 00:01:01 +0100
Felix Salfelder <address@hidden> wrote:

> On Tue, Jan 24, 2017 at 04:27:31PM -0500, al davis wrote:
> > Inconsistency ..  one distro is different from another .. not good.
> 
> if you pass --enable-new-dtags, you will get the same on all distros.

It didn't for me.  It seems sometimes I get RPATH, sometimes RUNPATH.

and the search order is RPATH, LD_LIBRARY_PATH, RUNPATH

and sometimes it works in main, sometimes it doesn't, but it always
works in apps (but might be RPATH or RUNPATH)

The fact that it works different for you than it does for me is the
problem.


> 
> the use of DT_RPATH ("old-dtags") is deprecated, that's what LD.SO(8)
> says. that is distro independent [1]. coincidently the new dtags have
> just become the default in debian. iirc, gentoo also does it like this.
> others will probably follow.

ok so debian ... it's one way in stretch, another in jessie.

This is why I want to use a different mechanism.

> > "Override" (comes before) is not "break" (fails to find it), but I
> > agree with you that what it does is less than ideal.
> 
> without the override, it's not possible to make use of something similar
> to LD_LIBRARY_PATH=$HOME/.gnucap/my_plugins. so that qualifies as
> "broken".

I get your point, but I defined "broken" as "ignored LD_LIBRARY_PATH",
which is not the same as "RPATH comes first".  It matters only when
there is something with the same name in both places.  The existing
approach is broken because sometimes it doesn't find the default
plugins without help, a problem introduced when we dropped "lib" from
"libgnucap-default-plugins.so", which caused it to be omitted from
ld.so.

I think it should have its own path anyway, separate from the usual
library search path, and gnucap-conf is a way to find all that stuff.

This again leads to my reason for the new approach in plugpath-2 ..  to
explicitly specify it, so it is consistent.

> imo we should add the "--enable-new-dtags" to "plugpath+" and be done
> (for quite a while). it will very likely not break any existing
> installs.

Tried that .. still got RPATH, which came first ahead of
LD_LIBRARY_PATH.

> wouldn't it be possible to start a different approach as a plugin? that
> might make sense in particular if it changes the current dlopen
> behaviour...

Could be .. but my concern is finding the default plugins in a
consistent reliable way, which can't be fixed as a plugin.