From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5700 invoked by alias); 31 Jul 2006 17:33:18 -0000 Received: (qmail 5635 invoked by uid 22791); 31 Jul 2006 17:33:17 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 31 Jul 2006 17:33:15 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G7bdg-0002tf-L1; Mon, 31 Jul 2006 13:33:12 -0400 Date: Mon, 31 Jul 2006 17:33:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Add expat to the GDB sources Message-ID: <20060731173312.GA10875@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20060718134048.GA15685@nevyn.them.org> <20060723224032.GA5168@trixie.casa.cgf.cx> <200607232318.k6NNIV28004376@elgar.sibelius.xs4all.nl> <20060724152438.GA17094@trixie.casa.cgf.cx> <20060724195118.GE13612@nevyn.them.org> <20060724214157.GC25632@trixie.casa.cgf.cx> <200607242229.k6OMTR1a022831@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607242229.k6OMTR1a022831@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00433.txt.bz2 On Tue, Jul 25, 2006 at 12:29:28AM +0200, Mark Kettenis wrote: > > But, where does this philosophy end? Are you *really* advocating that > > every shipping package should include the source code of any libraries > > that they use? So gdb should also include ncurses? > > The philosophy has always been that one should be able to build a GNU > toolchain without any external dependencies, to be able to bootstrap > into a situation wher you can use the toolchain to build other Free > Software. (I don't think toolchain in this sense includes GDB.) Before I work on alternatives for using expat, which I'll be doing later this afternoon, let me update us on the GNU philosophy on such issues: http://www.gnu.org/prep/maintain/html_node/External-Libraries.html#External-Libraries (quoted below) While this is not explicit, RMS has made clear that he also disapproves of GNU packages including other GNU packages without special permission permission from the FSF, especially if they have local modifications. Which we do. We have our own fork of readline. Examples: - Fastjar was removed from GCC by FSF request; this is an equivalent issue to expat. So we should not bundle expat. - libgcc-math was removed from GCC by FSF request, because it duplicated and slightly modified code from glibc; I believe this is equivalent to readline. - Soft-fp code from GCC was imported for use in the GCC runtime libraries on non-glibc systems, but only after direct permission from RMS. I realize this is somewhat inconvenient for users of GDB, but I think that if we asked the FSF, they would request we stop bundling readline, and not bundle expat. As for optional versus required, I don't think there's a relevant FSF position. However, I very much wanted to use the XML target descriptions in some cases to replace the C-coded ones. So obviously I prefer to require expat. ==== So the thing to do in this case is to make your program use the module, but not consider it a part of your program. There are two reasonable methods of doing this: 1. Assume the module is already installed on the system, and use it when linking your program. This is only reasonable if the module really has the form of a library. 2. Include the module in your package, putting the source in a separate subdirectory whose README file says, This is not part of the GNU FOO program, but is used with GNU FOO. Then set up your makefiles to build this module and link it into the executable. For this method, it is not necessary to treat the module as a library and make a .a file from it. You can link with the .o files directly in the usual manner. Both of these methods create an irregularity, and our lawyers have told us to minimize the amount of such irregularity. So consider using these methods only for general-purpose modules that were written for other programs and released separately for general use. For anything that was written as a contribution to your package, please get papers signed. ==== -- Daniel Jacobowitz CodeSourcery