From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12337 invoked by alias); 14 Jun 2003 14:33:51 -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 11953 invoked from network); 14 Jun 2003 14:33:48 -0000 Received: from unknown (HELO delta.ds2.pg.gda.pl) (213.192.72.1) by sources.redhat.com with SMTP; 14 Jun 2003 14:33:48 -0000 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA03283; Sat, 14 Jun 2003 16:26:10 +0200 (MET DST) X-Authentication-Warning: delta.ds2.pg.gda.pl: macro owned process doing -bs Date: Sat, 14 Jun 2003 14:33:00 -0000 From: "Maciej W. Rozycki" To: Alexandre Oliva cc: Bernd Jendrissek , Nathanael Nerode , 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/msg00277.txt.bz2 On 13 Jun 2003, Alexandre Oliva wrote: > >> > OK, the first is a native one, so it goes to $exec_prefix, say: > >> > /usr/lib. The second one is a cross one, so it goes to > >> > $exec_prefix/$target_alias, say: /usr/mipsel-linux/lib. Finally, the last > >> > one is a cross one, too, so it goes to $exec_prefix/$target_alias, say: > >> > /usr/mipsel-linux/lib -- oops! -- the second one just got overwritten... > >> > >> Two crosses to the same target, and you don't want one to overwrite > > > ... from different hosts; only the build is the same. > > If it's for different hosts, then you also clobbered all binaries that > you'd installed in the same exec_prefix. Which is why in this case > you'd be better off using per-host exec_prefixes. That's exactly the > purpose behind the distinction between prefix and exec_prefix. Files > in prefix are host-independent, whereas those in exec_prefix are > host-specific. I smell a confusion here. My setup is essentially as follows: 1. I keep architecture-independent data in $prefix. 2. I keep build-specific data in $exec_prefix. 3. I keep host-specific data in $exec_prefix/$host_alias. 4. I keep target-specific data in $exec_prefix/$target_alias. Except from host-specific libraries that recognize a different target there is no conflict, as 3. above only contains libraries and headers (in lib and include subdirectories, respectively) and 4. above only contains executables (in a bin subdirectory). It seems to be the preferred setup now as cross-tools get installed there by default (with $target_alias- aliases also installed in $exec_prefix/bin) and they look for libraries and headers there by default, too. > > It looks sane to me, but I think both host-x-target (or really > > build-x-target; what about build-x-host-x-target? ;-) ) > > build is irrelevant at install time. If some package installs > binaries for the build machine, the package is broken. It's not relevant then indeed, but once run it's relevant again as you -- essentially when doing a compilation you run binaries/libraries for the build system, use headers and link against libraries for a host system and these headers and libraries can support yet another target system (not necessarily different from the build one). You can legitimately have a mipsel-linux host bfd library supporting the alpha-linux target installed on an i386-linux system and use that library for linking binaries to be run on a mipsel-linux host. > > libraries and such binaries should both be under > > $exec_prefix/x-$target_alias for consistency then. > > Nope. $exec_prefix/x-$target_alias would hold libraries containing > code that runs on the host (so exec_prefix, not host-independent > prefix), used to manipulate binaries in the target's format > (e.g. host-x-target libbfd). Compare this with binaries and libraries > in the target's format, that we currently install in > $exec_prefix/$target_alias, even though they aren't host-specific in > any way, and therefore they could legitimately be installed in > $prefix/$target_alias. The fact that they were build on a certain > host should be irrelevant. I mean binaries for a given target and libraries/headers for the very same host should be in the same directory tree. Native libraries (i.e. for the build) supporting the target (where target != build) should be elsewhere as they conflict with the respective libraries for the same host (whether their host == build or not). Native libraries supporting the build (which target == host == build) are in $exec_prefix. > > And host libraries (I suppose you mean that -- few libraries, such > > as bfd, actually recognize the existence of a target; I understand the > > naming can be confusing) may go to $prefix/$host_alias > > Host libraries *have* to be in $exec_prefix, and $host_alias is > therefore redundant. Host libraries must not be in $exec_prefix unless host == build. You cannot run a library that is for a different host. > > (where $prefix may sometimes effectively be equal to $exec_prefix) > > If you use the same exec_prefix for different hosts, you're already > toast. Get used to --exec-prefix=${prefix}/H-${host_alias} before > it's too late :-) I'm not near being toast at all and I use this setup successfully for about four years now. There is a lot of confusion in understanding what is build, host and target (e.g. rpm uses a --target option for what is named --host in autoconf) and I had troubles in the beginning, too. Not anymore. If still in doubt please feel free to visit my FTP site (ftp://ftp.ds2.pg.gda.pl/pub/macro) and see how various bits are laid out in my binary RPM packages. They do work and there are no conflicts. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +