Re: Partial autoconf transition thoughts

Maciej W. Rozycki
2003-06-27T19:27:24Z

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/<host_alias>
>
> 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 +