Re: Partial autoconf transition thoughts

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

On 14 Jun 2003, Alexandre Oliva wrote:

> >> 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
> 
> I.e., you're using the binaries/libraries previously built specifying
> the build machine as the host.  Note that they may have very well been
> cross-built.  At this point, you're just using the build machine as a
> host for running a previously-built toolchain.  Why should it matter
> that you cross-built them on say x86_64-*-linux-gnu? :-)

 It doesn't matter -- it's the previous build machine.  When I run them,
the current build machine is one that was specified as the host when they
were configured. 

> >  I mean binaries for a given target and libraries/headers for the very
> > same host should be in the same directory tree.
> 
> This sounds good, but it would require us to introduce something like
> --target-exec-prefix, and to revamp the build machinery to take
> advantage of that.  Using --exec-prefix just won't cut it, since it's
> host-specific.

 Well, --target-exec-prefix isn't really needed as binaries for a given
target are already installed under $exec_prefix/$target_alias.  Unless
someone considers it inappropriate.  Note that it's the same as $tooldir,
so probably --tooldir would be an equally good option name.

 For host libraries to be installed on a different build I'm doing away
with specifying --prefix=/usr/<host_alias> -- this leads to libraries and
headers to be installed in $prefix/$host_alias.  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).  Otherwise specifying --exec-prefix
could suffice.  Packages built this way can be installed on any build
system (well, except when build == host, as such a package makes no sense
on them) and will correctly support the configured host system.  The
included libraries will never be run, of course. 

> > Native libraries (i.e. 
> > for the build) supporting the target (where target != build) should be
> > elsewhere
> 
> And they will: since they were built for a different host, they will
> have been installed in a different exec-prefix.

 Nope, they were built for the same host -- if you can run them on this
build machine, they also support linking for the host equal to the build.

> >  Host libraries must not be in $exec_prefix unless host == build.
> 
> You seem to be very confused about the meaning of --exec-prefix.

 I still believe I am not.  I think we are talking at different bands.

> --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.

 What is common are host files.  There are two kinds of these files --
ones that recognize a particular target and ones that don't.  The latter
are not a problem -- there is only a single version for each host.  The
former are as there can be multiple versions for a single host. 

> > 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. 

> > (e.g. rpm uses a --target option for what is named --host in
> > autoconf)
> 
> Indeed.
> 
> > They do work and there are no conflicts. 
> 
> Can you install binaries for two different machines in the same tree?

 What do you mean by "two different machines?"

 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.  They are in fact
"noarch" packages as they don't care of the build system.  Of course to do
any real work, they need to be complemented with appropriate toolchain
(that supports the target equal to the host of these libraries), e.g. 
mipsel-linux-gcc and alpha-linux-gcc for the specific build system (e.g. 
i386-linux) they will be used for. 

 Two different build machines?  Of course not -- only a single
architecture can match and packages for different build systems will
overlap.

> E.g., have native tools for two different GNU/Linux architectures in a
> single directory?

 These are two different build systems, so no, I can't.

> You'll see you actually need to specify different --exec-prefix in
> order to achieve this.  You'll see that, even if you cross-build one
> of these tools and build natively the other, the fact that they were
> cross- or natively-built doesn't matter at all.  What matters is the
> host they're supposed to run on, and the target.  --build only matters
> at build time.  Different --host flags imply different --exec-prefix,
> such that you can add $(bindir) = $(exec_prefix)/bin to host's PATH
> and find only binaries for the host machine.  It's that simple.

 I think I can see where the divergence lies.  I interpret the definitions
of a build, a host and a target very strictly, which means a slightly
different view of executables and libraries as libraries can be either
created or used and in the latter case a non conflicting place is needed
to handle different variations.

 The definition of a build covers everything that is run during a
compilation.  An executable for an i386-linux build is run during a
compilation.  A library for an i386-linux build is run during a
compilation. 

 The definition of a host covers everything that will be run at the
destination machine, i.e. that is used or created during a compilation. 
An executable for an i386-linux host is created during a compilation.  A
library for an i386-linux host is created during a compilation or an
existing one is used for linking.

 The definition of a target covers the data format to be interpreted by
the objects used or created during a compilation.  An executable for an
i386-linux target is created during a compilation.  A library for an
i386-linux target is created during a compilation or an existing one is
used for linking. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +