From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: TODO additions Date: 17 Nov 2002 22:56:31 +0000 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200210291902.g9TJ2AY18220@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037574701 31522 80.91.224.249 (17 Nov 2002 23:11:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 17 Nov 2002 23:11:41 +0000 (UTC) Cc: schwab@suse.de, monnier+gnu/emacs@rum.cs.yale.edu, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18DYZn-0008C9-00 for ; Mon, 18 Nov 2002 00:11:39 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18DYbi-0004ps-00 for ; Mon, 18 Nov 2002 00:13:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18DYXw-0000K0-00; Sun, 17 Nov 2002 18:09:44 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18DYLG-0001Xu-00 for emacs-devel@gnu.org; Sun, 17 Nov 2002 17:56:38 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18DYLD-0001Xj-00 for emacs-devel@gnu.org; Sun, 17 Nov 2002 17:56:37 -0500 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18DYLA-0001XR-00; Sun, 17 Nov 2002 17:56:33 -0500 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 18DYL9-0002l4-00; Sun, 17 Nov 2002 22:56:31 +0000 Original-To: rms@gnu.org Original-Lines: 42 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9505 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9505 Richard Stallman writes: > I don't know "Why would it?" but I can answer the question "Why does > it?" Emacs needed to use its own special crt0.o file and that > required calling ld directly. My point is that if this is a consequence of using unexec, for instance, it applies to things like SCM (and TeX?) too -- as well as Guile if that ever reinstates SCM's dump facility. > At first it was always done that way. > Later on some systems we arranged to use cc. So we added the > ORDINARY_LINK flag for those systems. So if I understand correctly, ORDINARY_LINK just means use `$(CC)' for what would normally be the Makefile LINK variable. > The question is relevant if you are thinking of implementing a > replacement for this code, which would always use cc to link. I think > that would be a nice simplification if it works, but hard to do. It seems to me that Libtool is the right place for knowledge of such things so that it can be shared usefully. I don't know whether that's worthwhile, though. > Unless and until that change is made, we need to keep supporting the > use of ORDINARY_LINK, which means that one way or another configure.in > must decide the value of ORDINARY_LINK. I doubt anyone disputes that. It's a question of the most maintainable way to do it. Here's another example of the difficulty of understanding things if one was to improve matters. src/Makefile.in says: /* GNU libc requires ORDINARY_LINK so that its own crt0 is used. Linux is an exception because it uses a funny variant of GNU libc. */ I don't know about the first sentence, but I think the second isn't true on modern systems, and it's not clear whether it would be an advantage if the gnu-linux configuration was be changed for configurations using libc6.