Re: Partial autoconf transition thoughts

Alexandre Oliva
2003-06-26T07:24:49Z

On Jun 14, 2003, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> 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/<host_alias>

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