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 _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
