Re: [Gnucap-devel] Makefiles again

[Felix Salfelder]

On Mon, Feb 09, 2015 at 09:37:53PM -0500, al davis wrote:
> On Monday 09 February 2015, Felix Salfelder wrote:
> > we had that. i simply don't get what you mean. what does
> > *not* work for you with the current autotools branch? is it
> > just the missing Make2? dissecting/renaming some files will
> > not immediately add functionality.
> 
> On that topic, the way plugins are handled now, autoconf or not, 
> is not what it should be.  So I want to deal with the plugin 
> handling first in a simpler environment, then fold it into 
> autoconf.

imo plugin handling is independent of the build system. i tinkered with
this, mostly in -uf, i did some configuration with autotools, but
there's no hard dependency on it. the point is, it works good enough
right now.

> What does not work in the current autotools branch?  There's an 
> easy bug that  the m4 directory is missing

an empty m4 is there now.

> then when I make and 
> make install just taking defaults and run it, it says:
> "gnucap: error while loading shared libraries: libgnucap.so.0: 
> cannot open shared object file: No such file or directory"

this is interesting. using defaults (on linux),
 1. libgnucap.* should be in /usr/local/lib
 2. here, /usr/local/lib is listed in /etc/ld.so.conf.d/libc.conf,
 3. and /usr/local/bin/gnucap is installed witout RPATH (intentionally).

also, if I remove the path from /etc/ld.so.conf.d/libc.conf (don't
forget to invoke ldconfig afterwards), i get (surprise)
$ chrpath /usr/local/bin/gnucap
/usr/local/bin/gnucap: RPATH=/usr/local/lib
$ automake --version
automake (GNU automake) 1.14.1
$ ./libtool --version
libtool (GNU libtool) 2.4.2

basically, autotools does what i would have implemented. if it doesn't
work for you, that's really curious. give me more data, i can try to
reproduce.

cheers
felix