From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7290 invoked by alias); 26 Jun 2003 07:24:49 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7268 invoked from network); 26 Jun 2003 07:24:47 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 26 Jun 2003 07:24:47 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva.cipe.redhat.com [10.0.1.10]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5Q7OeK20746; Thu, 26 Jun 2003 03:24:40 -0400 Received: from free.redhat.lsd.ic.unicamp.br (free.redhat.lsd.ic.unicamp.br [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.9/8.12.9) with ESMTP id h5Q7Od6r020961; Thu, 26 Jun 2003 04:24:39 -0300 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.9/8.12.9/Submit) id h5Q7OdeG020957; Thu, 26 Jun 2003 04:24:39 -0300 To: "Maciej W. Rozycki" Cc: gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: Partial autoconf transition thoughts References: From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Thu, 26 Jun 2003 07:24:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00482.txt.bz2 On Jun 14, 2003, "Maciej W. Rozycki" wrote: > Well, --target-exec-prefix isn't really needed as binaries for a given > target are already installed under $exec_prefix/$target_alias. The problem is precisely that we have, in the same directory, binaries in the host's format, that support the target binary format (e.g., bin/as, bin/ld), and libraries in the target format, that are installed inside exec_prefix even though they're in no way specific to the host on which they were build. They'd probably be better off in ${prefix}/${target_alias}, but --target-exec-prefix could override this. > For host libraries to be installed on a different build I'm doing away > with specifying --prefix=/usr/ prefix should not have to be host-specific. prefix is host-independent. exec_prefix is host-dependent. > I want headers to be > tightly coupled with their respective headers as there may be differences > across library versions and sometimes even differences between host > configurations (bfd.h is an example). This seems to imply that bfd.h is host-(and target?-)specific, and should therefore be installed somewhere in ${exec_prefix}, not in ${includedir}. >> --exec-prefix specifies where machine-dependent files should be >> installed. By definition, build files are not installed. Host and > Of course they don't. They already are installed. >> Target files are. Host files are machine-dependent, therefore they go >> in exec-prefix. Target files are host-independent, but they are >> machine-dependent, so there's room for installing them in either >> prefix or exec-prefix. > Pure target files are rare. An example are the files in > $exec_prefix/lib/ldscripts. I'm not writing of them as they are pretty > obvious to handle. Target files are machine-dependent, indeed, but they're dependent on the target machine, not on the host machine. Take, for example, libstdc++.a or libc.a, from a x-sh-elf build hosted on say both i686-pc-linux-gnu and i686-pc-freebsd. There's no reason to have two copies of these files, one in say (*) ${prefix}/H-i686-pc-linux-gnu/sh-elf/lib, another in ${prefix}/H-i686-pc-freebsd/sh-elf/lib. They might very well be in ${prefix}/sh-elf/lib or, maybe, ${prefix}/T-sh-elf/lib. The point is that we should have the same libc.a, regardless of whether it was built along with the i686-pc-linux-gnu, i686-pc-freebsd or yet another x-sh-elf toolchain that I haven't mentioned. (*) assume: prefix=/nfs/toolchains exec-prefix=${prefix}/H-${host_alias} Still, we do want assemblers and linkers for sh-elf to be in host-specific directories, which is why they get installed in ${exec_prefix} and, since they're target-specific, in the sub-directory thereof named after the target: ${exec_prefix}/${target_alias}. Note that, by using different exec-prefix for different hosts, we get binaries for i686-pc-linux-gnu and i686-pc-freebsd in separate directories, even if we use a shared install tree. >> > There is a lot of confusion in understanding what >> > is build, host and target >> >> It shows :-) > I don't think so. What I think is we both understand the meanings right, > but we have troubles communicating descriptions of specific circumstances. I'm trying to give specific examples in my e-mail, let's see whether it helps us communicate. I hope you didn't take any offense in my joke above, btw :-) >> Can you install binaries for two different machines in the same tree? > What do you mean by "two different machines?" A shared nfs directory containing toolchains for several different hosts and targets. Picture building crosses (and natives) hosted on a dozen different architectures, to a dozen different targets, all installed in a single directory tree, /nfs/toolchains. > Two different host machines? Of course I can. E.g. I have both a > mipsel-linux-glibc-devel and an alpha-linux-glibc-devel package installed. > They support development for their respective hosts. These are libraries for the targets. I was talking about binaries built for different hosts, i.e., that would enable you to use this (shared) /nfs/toolchains tree on machines of all these different host types, where they'd play the role of build machines. > They are in fact > "noarch" packages as they don't care of the build system. That's exactly why such packages should be in ${prefix}, not ${exec_prefix}. Anything that goes in ${exec_prefix} shouldn't be noarch. > I think I can see where the divergence lies. I interpret the definitions > of a build, a host and a target very strictly, Part of the problem is that it can't be that strict. See, when you configure a toolchain with --build=B --host=H --target=T, build, host and target make sense for this toolchain build. For the libraries built as part of the toolchain, you get --build=B --host=T [--with-cross-host=H]. So T is the library's host, since the target library is in T's format. Then, when you install this toolchain on a H machine and use it to create another program, you'll configure this program with --build=H --host=T. It shifts. You already knew that, but I wanted to point out that the definitions aren't all that strict. They change depending on how you look at it. What doesn't change is that ${prefix} should contain noarch files, whereas ${exec_prefix} should contain files that, should exec-prefix be equal to prefix, would (potentially) vary depending on which arch's package you've installed, i.e., depending on the host for which they were build. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer