From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23031 invoked by alias); 27 Jun 2003 19:27:24 -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 22756 invoked from network); 27 Jun 2003 19:27:21 -0000 Received: from unknown (HELO delta.ds2.pg.gda.pl) (213.192.72.1) by sources.redhat.com with SMTP; 27 Jun 2003 19:27:21 -0000 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA01696; Fri, 27 Jun 2003 21:28:16 +0200 (MET DST) X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs Date: Sat, 28 Jun 2003 00:35:00 -0000 From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Alexandre Oliva cc: gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: Partial autoconf transition thoughts In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-06/txt/msg00516.txt.bz2 On 26 Jun 2003, Alexandre Oliva 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. Hmm, what libraries in the target format do you mean exactly? About the only ones that come to my mind is libgcc and friends, but these are installed elsewhere anyway. Other libraries are in the host format and there is no way to guess a user's intent for them, i.e. whether they will be used for cross-linking only or natively. > > 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. Well, I trim host libraries to lone headers and library objects, so it's actually alike to me whichever of $prefix or $exec_prefix I override, except as headers are sometimes host-specific, they do really want to go to a host-specific location. > > 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}. Yes, it is target-specific, specifically BFD_ARCH_SIZE may differ and the BFD's ABI depends on it -- versions build with different BFD_ARCH_SIZE are binary incompatible. > >> > 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 :-) Certainly I didn't -- do I look insane? > >> 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. I see. It should be fine if you set $exec_prefix to something different from $prefix, possibly $prefix/$host_alias. You'd need to adjust $PATH and possibly $LD_LIBRARY_PATH (or ld.so.conf, or use the RPATH ELF attribute unconditionally, etc.) for a non-standard directory layout. I haven't tried that -- I have $prefix and $exec_prefix both set to /usr. > > 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. These are libraries for the respective hosts and not targets (glibc does not recognize the concept of a target -- it doesn't handle binaries with the exception of ld.so and libdl which only work natively). They should work just fine with the setup outlined above, except that they would be used for the build as well then. It looks like a nice idea, actually. > > 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. But I've overridden $prefix above to install them in /usr/$host_alias and you complained. Now I'm confused... > > 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. Agreed, but with my note about libraries above -- they are noarch when used for cross-linking but pretty much arch-dependent if used natively. Actually the difference only exists for shared objects and I think at least for ELF it could be solved with appropriate symlinks, but it would also introduce unnecessary confusion for most people who are not interested in cross-compilation. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +