From: Sascha Wilde <wilde@sha-bang.de>
To: Miles Bader <miles@gnu.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: EDE: make project shared objects
Date: Sat, 31 Oct 2009 13:07:23 +0100 [thread overview]
Message-ID: <m2my37ahs4.fsf@sha-bang.de> (raw)
In-Reply-To: <87y6msm8ot.fsf@catnip.gol.com> (Miles Bader's message of "Sat, 31 Oct 2009 14:30:42 +0900")
Miles Bader <miles@gnu.org> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> It would be best to use libtool for linking programs, too -- at least
>>> when they are linked against shared libraries which are part of the
>>> project. But this also makes only sense with an install target.
>>
>> I do not have a strong opinion on this, but IIUC while autoconf seems to
>> be usually appreciated, and mostly so as well for automake (tho to
>> a lesser extent), libtool has many more detractors because it is a lot
>> more invasive.
While statements like this are not uncommon, I miss in many cases a
clear explanation what the actual downsides of libtool are.[0]
>> So it might be good to support projects using libtool, but I think it
>> is important not to impose it.
The current situation is that the EDE make projects don't work for
libraries at all and getting them to work is easiest achieved by using
libtool.
In a next step we could try to get it work even without libtool (EDE's
concept of selectable compiler and linker templates makes it easy to
support different strategies), BUT getting this right (including library
versioning, rpath, in place testing of dynamically linked binaries)
isn't trivial. And getting it sufficiently portable would mean to
duplicate the affords of libtool in great lengths. It might be
worthwhile if we could do better than libtool with respect to being less
"invasive" (for what ever that means) but I doubt its worth the trouble.
> The last time I attempted to use libtool, it was a huge mess; it seemed
> to be trying so hard to be portable that it ended up being barely
> usable.
I think portability is an important goal and IMO libtool does a
remarkable job simplifying the tedious task of building libraries on
different platforms. If you can give a short summary why using it was a
"huge mess" in your project I would be very interested. I'd really like
to understand what the common problems with libtool are.
cheers
sascha
[0] The most famous discussion on this topic is the "debian against libtool"
case, which was about the unconditional use of rpath by libtool. In
the end it turned out, that the whole fuzz was really caused neither
by libtool nor by rpath in general but by an insufficient
compatibility hack in the run time linker on the transition from
libc5 to libc6:
http://lists.debian.org/debian-devel/1999/01/msg02570.html
--
Sascha Wilde
We're Germans and we use Unix. That's a combination of two
demographic groups known to have no sense of humour whatsoever.
-- Hanno Mueller in de.comp.os.unix.programming
next prev parent reply other threads:[~2009-10-31 12:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-29 15:01 EDE: make project shared objects Sascha Wilde
2009-10-30 11:36 ` Lluis
2009-10-30 13:06 ` Sascha Wilde
2009-10-30 18:53 ` Stefan Monnier
2009-10-31 5:30 ` Miles Bader
2009-10-31 12:07 ` Sascha Wilde [this message]
2009-10-31 12:14 ` Eric M. Ludlam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2my37ahs4.fsf@sha-bang.de \
--to=wilde@sha-bang.de \
--cc=emacs-devel@gnu.org \
--cc=miles@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.