From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sascha Wilde Newsgroups: gmane.emacs.devel Subject: Re: EDE: make project shared objects Date: Sat, 31 Oct 2009 13:07:23 +0100 Message-ID: References: <87y6msm8ot.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1256990869 8163 80.91.229.12 (31 Oct 2009 12:07:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 Oct 2009 12:07:49 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 31 13:07:42 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N4Ck7-0000Ei-Jk for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2009 13:07:39 +0100 Original-Received: from localhost ([127.0.0.1]:33161 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4Ck6-0004Ho-MU for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2009 08:07:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N4Ck0-0004GC-5W for emacs-devel@gnu.org; Sat, 31 Oct 2009 08:07:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N4Cjx-0004DQ-Jt for emacs-devel@gnu.org; Sat, 31 Oct 2009 08:07:30 -0400 Original-Received: from [199.232.76.173] (port=40612 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4Cjx-0004DJ-F2 for emacs-devel@gnu.org; Sat, 31 Oct 2009 08:07:29 -0400 Original-Received: from mail2.sha-bang.de ([78.47.120.114]:41078 helo=mail.sha-bang.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N4Cju-00062I-E9; Sat, 31 Oct 2009 08:07:26 -0400 Original-Received: from kenny.sha-bang.local (xdslcm202.osnanet.de [89.166.140.202]) by mail.sha-bang.de (Postfix) with ESMTPSA id C49C854E; Sat, 31 Oct 2009 13:07:23 +0100 (CET) Original-Received: from wilde by kenny.sha-bang.local with local (Sha Bang MUA v.0711184.68) ID 1N4Cjr-0003JR-4b; Sat, 31 Oct 2009 13:07:23 +0100 In-Reply-To: <87y6msm8ot.fsf@catnip.gol.com> (Miles Bader's message of "Sat, 31 Oct 2009 14:30:42 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116505 Archived-At: Miles Bader wrote: > Stefan Monnier 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