* AARRRRGGH! Die Libtool, die!
@ 2003-02-15 14:36 Han-Wen Nienhuys
2003-02-15 20:46 ` Rob Browning
0 siblings, 1 reply; 12+ messages in thread
From: Han-Wen Nienhuys @ 2003-02-15 14:36 UTC (permalink / raw)
(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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: AARRRRGGH! Die Libtool, die!
2003-02-15 14:36 AARRRRGGH! Die Libtool, die! Han-Wen Nienhuys
@ 2003-02-15 20:46 ` Rob Browning
2003-02-15 23:54 ` Han-Wen Nienhuys
0 siblings, 1 reply; 12+ messages in thread
From: Rob Browning @ 2003-02-15 20:46 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: AARRRRGGH! Die Libtool, die!
2003-02-15 20:46 ` Rob Browning
@ 2003-02-15 23:54 ` Han-Wen Nienhuys
2003-02-16 0:56 ` Tom Lord
2003-02-16 1:09 ` Rob Browning
0 siblings, 2 replies; 12+ messages in thread
From: Han-Wen Nienhuys @ 2003-02-15 23:54 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: AARRRRGGH! Die Libtool, die!
2003-02-15 23:54 ` Han-Wen Nienhuys
@ 2003-02-16 0:56 ` Tom Lord
2003-02-18 11:24 ` tomas
2003-02-18 17:14 ` Rob Browning
2003-02-16 1:09 ` Rob Browning
1 sibling, 2 replies; 12+ messages in thread
From: Tom Lord @ 2003-02-16 0:56 UTC (permalink / raw)
Cc: rlb
> (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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: AARRRRGGH! Die Libtool, die!
2003-02-16 0:56 ` Tom Lord
@ 2003-02-18 11:24 ` tomas
2003-02-18 17:14 ` Rob Browning
1 sibling, 0 replies; 12+ messages in thread
From: tomas @ 2003-02-18 11:24 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: AARRRRGGH! Die Libtool, die!
2003-02-16 0:56 ` Tom Lord
2003-02-18 11:24 ` tomas
@ 2003-02-18 17:14 ` Rob Browning
2003-02-18 18:50 ` rm
1 sibling, 1 reply; 12+ messages in thread
From: Rob Browning @ 2003-02-18 17:14 UTC (permalink / raw)
Cc: hanwen
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: AARRRRGGH! Die Libtool, die!
2003-02-18 17:14 ` Rob Browning
@ 2003-02-18 18:50 ` rm
2003-02-19 13:04 ` tomas
2003-02-21 17:28 ` Rob Browning
0 siblings, 2 replies; 12+ messages in thread
From: rm @ 2003-02-18 18:50 UTC (permalink / raw)
Cc: hanwen
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: AARRRRGGH! Die Libtool, die!
2003-02-18 18:50 ` rm
@ 2003-02-19 13:04 ` tomas
2003-02-21 17:28 ` Rob Browning
1 sibling, 0 replies; 12+ messages in thread
From: tomas @ 2003-02-19 13:04 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: AARRRRGGH! Die Libtool, die!
2003-02-18 18:50 ` rm
2003-02-19 13:04 ` tomas
@ 2003-02-21 17:28 ` Rob Browning
1 sibling, 0 replies; 12+ messages in thread
From: Rob Browning @ 2003-02-21 17:28 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: AARRRRGGH! Die Libtool, die!
2003-02-15 23:54 ` Han-Wen Nienhuys
2003-02-16 0:56 ` Tom Lord
@ 2003-02-16 1:09 ` Rob Browning
1 sibling, 0 replies; 12+ messages in thread
From: Rob Browning @ 2003-02-16 1:09 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* AARRRRGGH! Die Libtool, die!
@ 2003-02-15 14:26 Han-Wen Nienhuys
2003-02-18 11:04 ` tomas
0 siblings, 1 reply; 12+ messages in thread
From: Han-Wen Nienhuys @ 2003-02-15 14:26 UTC (permalink / raw)
(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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-02-21 17:28 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-02-15 14:36 AARRRRGGH! Die Libtool, die! Han-Wen Nienhuys
2003-02-15 20:46 ` Rob Browning
2003-02-15 23:54 ` Han-Wen Nienhuys
2003-02-16 0:56 ` Tom Lord
2003-02-18 11:24 ` tomas
2003-02-18 17:14 ` Rob Browning
2003-02-18 18:50 ` rm
2003-02-19 13:04 ` tomas
2003-02-21 17:28 ` Rob Browning
2003-02-16 1:09 ` Rob Browning
-- strict thread matches above, loose matches on Subject: below --
2003-02-15 14:26 Han-Wen Nienhuys
2003-02-18 11:04 ` tomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).