AARRRRGGH! Die Libtool, die!

AARRRRGGH! Die Libtool, die!

[Han-Wen Nienhuys]

(desparate frustration mode)

Automake, autoconf, libtool. They should be taken out and
shot. Perhaps their authors too.

(argh)

after cvs-upping, I did.

   ./configure --disable-elisp --enable-htmldoc --enable-maintainer-mode --enable-ltdl-install --prefix=/home/hanwen/usr/pkg/guile/
   make

(all went fine)

then

	make install


	make[1]: Binnengaan van map `/home/hanwen/usr/src/savannah/official-guile/guile/guile-core/libguile'
	/bin/sh ../mkinstalldirs /home/hanwen/usr/pkg/guile//lib
	 /bin/sh ../libtool --mode=install /usr/bin/install -c  libguile.la /home/hanwen/usr/pkg/guile//lib/libguile.la
	libtool: install: warning: relinking `libguile.la'
	(cd /home/hanwen/usr/src/savannah/official-guile/guile/guile-core/libguile; /bin/sh ../libtool --mode=relink gcc -g -O2 -Werror -Wall -Wmissing-prototypes -o libguile.la -rpath /home/hanwen/usr/pkg/guile//lib -version-info 15:0:0 -export-dynamic -no-undefined alist.lo [..] net_db.lo socket.lo regex-posix.lo ../libguile-ltdl/libguile-ltdl.la -lpthread -lcrypt -lm )
	mv: cannot stat `libguile.so.15.0.0': No such file or directory
	libtool: install: error: relink `libguile.la' with the above command before installing it
	make[1]: *** [install-libLTLIBRARIES] Fout 1
	make[1]: Weggaan uit map `/home/hanwen/usr/src/savannah/official-guile/guile/guile-core/libguile'
	make: *** [install-am] Fout 2


WTF is it recompiling stuff during installation? 

	 rm libguile.la 
 	 make
	 [..]
	make install

gives


	(cd
	/home/hanwen/usr/src/savannah/official-guile/guile/guile-core/libguile;
	/bin/sh ../libtool --mode=relink gcc -g -O2 -Werror -Wall
	-Wmissing-prototypes -o libguile.la -rpath
	/home/hanwen/usr/pkg/guile//lib -version-info 15:0:0 -export-dynamic
	-no-undefined alist.lo [..] socket.lo regex-posix.lo ../libguile-ltdl/libguile-ltdl.la -lpthread -lcrypt -lm )
	gcc -shared  alist.lo arbiters.lo [..] regex-posix.lo  -Wl,--rpath -Wl,/usr/local/lib  -L/usr/local/lib -lguile-ltdl -lpthread -lcrypt -lm   -Wl,-soname -Wl,libguile.so.15 -o .libs/libguile.so.15.0.0
	/usr/bin/ld: cannot find -lguile-ltdl
	collect2: ld returned 1 exit status
	libtool: install: error: relink `libguile.la' with the above command before installing it
	make[1]: *** [install-libLTLIBRARIES] Fout 1
	make[1]: Weggaan uit map `/home/hanwen/usr/src/savannah/official-guile/guile/guile-core/libguile'

I can't believe this. Every single time that I've tried to do a major
upgrade of CVS guile, there have been unfathomable issues with libtool
and libltdl. Why is this always so complicated?

-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

AARRRRGGH! Die Libtool, die!

[Han-Wen Nienhuys]

(desparate frustration mode)

Automake, autoconf, libtool. They should be taken out and
shot. Perhaps their authors too.

(argh)

after cvs-upping, I did.

   ./configure --disable-elisp --enable-htmldoc --enable-maintainer-mode --enable-ltdl-install --prefix=/home/hanwen/usr/pkg/guile/
   make

(all went fine)

then

	make install


	make[1]: Binnengaan van map `/home/hanwen/usr/src/savannah/official-guile/guile/guile-core/libguile'
	/bin/sh ../mkinstalldirs /home/hanwen/usr/pkg/guile//lib
	 /bin/sh ../libtool --mode=install /usr/bin/install -c  libguile.la /home/hanwen/usr/pkg/guile//lib/libguile.la
	libtool: install: warning: relinking `libguile.la'
	(cd /home/hanwen/usr/src/savannah/official-guile/guile/guile-core/libguile; /bin/sh ../libtool --mode=relink gcc -g -O2 -Werror -Wall -Wmissing-prototypes -o libguile.la -rpath /home/hanwen/usr/pkg/guile//lib -version-info 15:0:0 -export-dynamic -no-undefined alist.lo [..] net_db.lo socket.lo regex-posix.lo ../libguile-ltdl/libguile-ltdl.la -lpthread -lcrypt -lm )
	mv: cannot stat `libguile.so.15.0.0': No such file or directory
	libtool: install: error: relink `libguile.la' with the above command before installing it
	make[1]: *** [install-libLTLIBRARIES] Fout 1
	make[1]: Weggaan uit map `/home/hanwen/usr/src/savannah/official-guile/guile/guile-core/libguile'
	make: *** [install-am] Fout 2

WTF is it recompiling stuff during installation? 

	 rm libguile.la 
 	 make
	 [..]
	make install

gives


	(cd
	/home/hanwen/usr/src/savannah/official-guile/guile/guile-core/libguile;
	/bin/sh ../libtool --mode=relink gcc -g -O2 -Werror -Wall
	-Wmissing-prototypes -o libguile.la -rpath
	/home/hanwen/usr/pkg/guile//lib -version-info 15:0:0 -export-dynamic
	-no-undefined alist.lo [..] socket.lo regex-posix.lo ../libguile-ltdl/libguile-ltdl.la -lpthread -lcrypt -lm )
	gcc -shared  alist.lo arbiters.lo [..] regex-posix.lo  -Wl,--rpath -Wl,/usr/local/lib  -L/usr/local/lib -lguile-ltdl -lpthread -lcrypt -lm   -Wl,-soname -Wl,libguile.so.15 -o .libs/libguile.so.15.0.0
	/usr/bin/ld: cannot find -lguile-ltdl
	collect2: ld returned 1 exit status
	libtool: install: error: relink `libguile.la' with the above command before installing it
	make[1]: *** [install-libLTLIBRARIES] Fout 1
	make[1]: Weggaan uit map `/home/hanwen/usr/src/savannah/official-guile/guile/guile-core/libguile'

I can't believe this. Every single time that I've tried to do a major
upgrade of CVS guile, there have been unfathomable issues with libtool
and libltdl. Why is this always so complicated?

	$ rpm -q libtool automake make gcc 
	libtool-1.4.2-12
	automake-1.6.3-1.jcb1
	make-3.79.1-14
	gcc-3.2-7


-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: AARRRRGGH! Die Libtool, die!

[Rob Browning]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> WTF is it recompiling stuff during installation? 

I'm not particularly fond of that "feature" either.  I think it has to
do with trying to have libs that will work from the install tree vs
libs that will work from the build tree.  (i.e. perhaps different
-rpaths, etc., and it may be aggravated by cross-platform issues).

If you haven't done it already, I'd try a "make distclean" and
(re)running ./autogen.sh and see if that helps.  If not, we'll try
something else.

> I can't believe this. Every single time that I've tried to do a major
> upgrade of CVS guile, there have been unfathomable issues with libtool
> and libltdl. Why is this always so complicated?

Good question -- It's certainly not entertaining when it happens.

To be somewhat fair though, I'd have to allow that the problem they're
trying to solve is a fairly nasty one, and certainly isn't made any
easier by being written in #!/bin/sh -- not a job I'd favor.

(Personally, I'd rather have all those tools (auto* included) written
 in something like perl -- it's nearly as ubiquitous and *far* more
 managable.  Of course perl couldn't use them then, but AFAIK, it
 doesn't anyway.)

Hope this helps.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: AARRRRGGH! Die Libtool, die!

[Han-Wen Nienhuys]

rlb@defaultvalue.org writes:
> Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> 
> > WTF is it recompiling stuff during installation? 
> 
> I'm not particularly fond of that "feature" either.  I think it has to
> do with trying to have libs that will work from the install tree vs
> libs that will work from the build tree.  (i.e. perhaps different
> -rpaths, etc., and it may be aggravated by cross-platform issues).
> 
> If you haven't done it already, I'd try a "make distclean" and
> (re)running ./autogen.sh and see if that helps.  If not, we'll try
> something else.

Ah, distclean. I only did "make clean". Thanks, it seems to work now.

> (Personally, I'd rather have all those tools (auto* included) written
>  in something like perl -- it's nearly as ubiquitous and *far* more
>  managable.  Of course perl couldn't use them then, but AFAIK, it
>  doesn't anyway.)

I would use Python myself, but otherwise I concur.

-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: AARRRRGGH! Die Libtool, die!

[Tom Lord]

       > (Personally, I'd rather have all those tools (auto* included)
       >  written in something like perl -- it's nearly as ubiquitous
       >  and *far* more managable.  Of course perl couldn't use them
       >  then, but AFAIK, it doesn't anyway.)

       I would use Python myself, but otherwise I concur.

Bah.

Both perl and python are not stable.  `sh' hasn't changed much in a
decade and probably won't for another decade if ever.  `sh' is more
than adequate for the job.   If you must reach for something more,
especially on this list, for gosh sakes, pick something rooted in
stable standards: reach for SCSH, you traitors.

The problems with the auto* family of tools include:

	1) reliance on separate distribution

	   Everything depends on those tools, and those tools aren't
           stable.  Build systems are an area where you want
           conventions, not dependencies.  It sucks that developers
           have to keep multiple versions of these tools around.


	2) wrong approach to application portability

	   The portability problem these days is much smaller than it
           was when autoconf was conceived.  Feature tests are an
           inelegant solution that has, for the most part, failed
           (just try building a randomly selected set of public
           projects on anything other than a recent GNU/Linux system).

	   A better use of everyone's time would be to work on 
           designing and stabilizing a portability library against
           which new applications could be built and to which old
           applications can be ported.


	3) wrong approach to /bin/sh portability (m4)

	   The `/bin/sh' portability problem is much smaller today
           than it was when autoconf was conceived.   The role of
           m4 (GNU m4 specifically, no less) in autoconf has outlived
           its usefulness.   The obfuscation cost of the use of m4
           in autoconf now outweighs its payoff.


	4) wrong approach to makefile portability

	   The `make' portability problem is much smaller today 
           than it was when autoconf was conceived.  The auto* family
           clings to requirement of makefile portability even while
           GNU make runs pretty much everywhere.


	5) wrong approach to makefile automation

	   Roughly speaking, `automake' bridges the gap between
	   historic versions of `make' and the capabilities of GNU
	   make.   If you commit to GNU make, you simply do not need
           automake.


	6) lack of consideration for package management

	   The functionality of package managers belongs in the 
           configure/build tools.


	7) excessive complexity

	   I've scientifically measured it and the result is official:
	   the auto* family is a gazillion times more complicated than
           it needs to be.   Of course, the battle-scarred maintainers
	   of these packages will regale with you with horror stories
	   about how each and every detail of the auto* family came
	   into being -- but they'll also falsely ask you to believe
	   that those stories justify making each and every free
	   software project dependent on solutions to 20 year old
	   problems that no longer exist.

	etc.

Oh yeah -- did I mention that my `package-framework' contains the
skeleton of a replacement for the auto* family?  I guess I must be
biased....

-t


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: AARRRRGGH! Die Libtool, die!

[Rob Browning]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> I would use Python myself, but otherwise I concur.

I wouldn't necessarily have a problem with that, but in my experience,
Python's still not nearly as ubiquitous yet, though it's certainly
growing fast.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: AARRRRGGH! Die Libtool, die!

[tomas]

On Sat, Feb 15, 2003 at 03:26:58PM +0100, Han-Wen Nienhuys wrote:
> 
> (desparate frustration mode)
> 
> Automake, autoconf, libtool. They should be taken out and
> shot.

My feelings are with you. I too think that complexity has taken
over. Hmmm.

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: AARRRRGGH! Die Libtool, die!

[tomas]

On Sat, Feb 15, 2003 at 04:56:12PM -0800, Tom Lord wrote:
> 

[perl or python instead of sh]

> Bah.
> 
> Both perl and python are not stable. [...]

Whereas I consider Perl or Python more appropriate than sh for such
things, this is a real problem. To watch this in action see what
happens to the Debian packaging system when Perl `grows' a bit ;-)

> The problems with the auto* family of tools include:
> 
> 	1) reliance on separate distribution
[...]
Definitely. I'd dream of a very small embeddable interpreter
with stable semantics and a tight C interface, very portable,
uh, wait a minute.

> 	2) wrong approach to application portability
[...]
Many things have changed from the beginnings of Auto*. That's true.

> 	3) wrong approach to /bin/sh portability (m4)
[...]
I don't really think that /bin/sh is the right tool for this job.
Especially not the mythical monster called ``portable shell''.

> 	4) wrong approach to makefile portability
[...]
I have more issues with /bin/sh than with M4, actually. OK, M4 may
be obscure, but it has at least semantics ;-)

> 	5) wrong approach to makefile automation
[...]
If everyone had GNU Make... (but you're quite right: the only widespread
non-Unixoid platform out there probably will have GNU Make whenever it
has some form of /bin/sh: via Cygwin. Times have changed).

> 	6) lack of consideration for package management
[...]
Uh, oh. Do you mean offering `hooks' to package management systems to
let them gather whatever bits of information they need? Or yet-another-
package-management-system? Tightly coupled to an application build
framework, at that.

> 	7) excessive complexity
[...]
Absolutely. I think we agree that this stems mainly from 3), 4) and 5).

I'll definitely look into your project.

Thanks
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: AARRRRGGH! Die Libtool, die!

[Rob Browning]

Tom Lord <lord@emf.net> writes:

> Both perl and python are not stable.  `sh' hasn't changed much in a
> decade and probably won't for another decade if ever.  `sh' is more
> than adequate for the job.  If you must reach for something more,
> especially on this list, for gosh sakes, pick something rooted in
> stable standards: reach for SCSH, you traitors.

If SCSH (or even Guile) really is comparable in portability to Perl,
and if we were not concerned with having a large pool of potential
contributors (and we might not be), and if we don't think that the
size of the existing base of systems with the language in question
already installed is relevant, then of course I'd rather use Scheme.
My initial feeling was that at least one of the items above was
probably false, but if not, then that's great.

With respect to sh. I've seen what large "portable sh" programs look
like, and I've worked a bit on them.  As a result, I'd have very
little interest in the project if it were written in sh.

Other than that, I agree with much of the rest of what you've said.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: AARRRRGGH! Die Libtool, die!

[rm]

On Tue, Feb 18, 2003 at 11:14:50AM -0600, Rob Browning wrote:
> Tom Lord <lord@emf.net> writes:
> 
> > Both perl and python are not stable.  `sh' hasn't changed much in a
> > decade and probably won't for another decade if ever.  `sh' is more
> > than adequate for the job.  If you must reach for something more,
> > especially on this list, for gosh sakes, pick something rooted in
> > stable standards: reach for SCSH, you traitors.
> 
> If SCSH (or even Guile) really is comparable in portability to Perl,
> and if we were not concerned with having a large pool of potential
> contributors (and we might not be), and if we don't think that the
> size of the existing base of systems with the language in question
> already installed is relevant, then of course I'd rather use Scheme.
> My initial feeling was that at least one of the items above was
> probably false, but if not, then that's great.

How about 'gu', a really portable guile kernel that can be used to
bootstrap? It seems that  a lot of the portability problems of 'sh' are 
syntax / feature set problems. Wouldn't it be worth the effort to 
work on a (non-interactive) guile-core shell?

 Ralf Mattes


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: AARRRRGGH! Die Libtool, die!

[tomas]

On Tue, Feb 18, 2003 at 07:50:30PM +0100, rm@fabula.de wrote:
> On Tue, Feb 18, 2003 at 11:14:50AM -0600, Rob Browning wrote:
> > Tom Lord <lord@emf.net> writes:
> > 

[...]

> How about 'gu', a really portable guile kernel that can be used to
> bootstrap? [...]

Drool...

Where can I download that ;-)

Greetings
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: AARRRRGGH! Die Libtool, die!

[Rob Browning]

rm@fabula.de writes:

> How about 'gu', a really portable guile kernel that can be used to
> bootstrap? It seems that a lot of the portability problems of 'sh'
> are syntax / feature set problems. Wouldn't it be worth the effort
> to work on a (non-interactive) guile-core shell?

Sounds good to me in theory :> Though I haven't thought enough about
it to have a good idea about what might be involved...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel