Re: Partial autoconf transition thoughts

Re: Partial autoconf transition thoughts

[Nathanael Nerode]

Alexandre said:
>I.e., assume you're always cross compiling?  That would be a
Actually, assume you're always Canadian cross compiling. :-)  Except 
when you aren't.

>reasonable approach too, but there are some tests that you can't
>possibly do in the cross case, autoconf lets you actually do them in
>the native case as long as you set a safe default or alternate test
>for the cross case.

And when I write my own tests for these circumstances, I would guard 
them by one of build=host or build=target, depending on which is correct 
under the circumstances.  

This generally tests in the correct situations, and is if anything too
conservative (assuming untestability when build=i686-pc-linux-gnu 
and host=i386-pc-linux-gnu).

I suppose the idea behind the proposal is that you can always 
force nativeness by not specifying 'host' (since it defaults to build); 
but there's no clear way to force 'crossness' when host=build.

But why would you *want* to?

Perhaps you have two machines with the same canonical name, but 
differing in the particular feature.  This is most likely due to a bug 
in config.guess or config.sub, which is Not Autoconf's Problem.  

Otherwise, the feature is probably one where I don't *want* autoconf to 
decide based on my particular build machine; it will presumably make 
the produced program quite unportable, and will likely break if I make 
some small change to my machine's configuration.  Such a feature 
probably deserves its own --with option and notes in the documentation, 
and should certainly be defaulted to the 'baseline' option, not to 
whatever's on my machine today.

So the only use case I can think of for 'forcing crossness' when 
build=host depends on either bugs in config.* or poor 'configure' 
design.

Hmm.  Now who should I say this to?

Akim, I guess, but he still hasn't done anything with the autoconf patch 
I sent him a long while ago.

--Nathanael

Re: Partial autoconf transition thoughts

[DJ Delorie]

> But why would you *want* to?

Actually, it came up recently.  Someone wanted to.

The other case I recall that it didn't get right is build==target but
build!=host, but that was some time ago and might be fixed now.

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

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        +

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

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

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

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        +

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

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

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

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

>> 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 seem to be very confused about the meaning of --exec-prefix.
--exec-prefix specifies where machine-dependent files should be
installed.  By definition, build files are not installed.  Host and
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.

> There is a lot of confusion in understanding what
> is build, host and target

It shows :-)

> (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?
E.g., have native tools for two different GNU/Linux architectures in a
single directory?

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.

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

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

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-<name> 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        +

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

On Jun 13, 2003, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

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

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

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

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

> (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 :-)

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

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

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.

> the other?  Well, then...  I guess you want to add build timestamps
> somewhere in the pathname or something.
> 
> More likely, I just misunderstand the scenario you have in mind :-)

 See my note above.  The second library is for binaries that want to run
on this build/host (i386-linux) system, but interpret different target
(mipsel-linux) binaries.  The third library is for linking binaries to be
run on another host system (mipsel-linux) and interpret its native
(mipsel-linux) binaries.  The third library is never used at the run time,
but it needs to exist for mipsel-linux-ld.

> My proposal back then was $exec_prefix/x-$target_alias for
> host-x-target libraries.  libraries for the target (i.e., not
> libraries for host applications to manipulate target binaries, but
> rather libraries containing code that will run on the target) would
> still be in $exec_prefix/$target_alias, where they're currently
> installed, but there's no reason why we couldn't move them to say
> $prefix/$target_alias (since they depend on target, and are totally
> independent of host), and use $exec_prefix/$target_alias for
> host-x-target binaries.

 It looks sane to me, but I think both host-x-target (or really
build-x-target; what about build-x-host-x-target? ;-) ) libraries and such
binaries should both be under $exec_prefix/x-$target_alias for consistency
then.  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 (where $prefix may
sometimes effectively be equal to $exec_prefix).  And native (i.e. 
build/host) libraries and binaries go straight under $exec_prefix. 

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

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

On Jun 13, 2003, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> 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
the other?  Well, then...  I guess you want to add build timestamps
somewhere in the pathname or something.

More likely, I just misunderstand the scenario you have in mind :-)

>> Anyway, after re-reading the thread, I remember why we chose to do it
>> the way we did it.  It does make sense, even thought I still find it
>> not ideal.

>  I am looking forward to seeing any proposals for improvements.

My proposal back then was $exec_prefix/x-$target_alias for
host-x-target libraries.  libraries for the target (i.e., not
libraries for host applications to manipulate target binaries, but
rather libraries containing code that will run on the target) would
still be in $exec_prefix/$target_alias, where they're currently
installed, but there's no reason why we couldn't move them to say
$prefix/$target_alias (since they depend on target, and are totally
independent of host), and use $exec_prefix/$target_alias for
host-x-target binaries.

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

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

On 13 Jun 2003, Alexandre Oliva wrote:

> >  OK, then what about the following example: on an i386-linux system I have
> > three shared binaries of libbfd, one is for i386-linux host and i386-linux
> > target, another one is for i386-linux host and mipsel-linux target and the
> > last one is for mipsel-linux host and mipsel-linux target.
> 
> $(exec_prefix)/$(target_alias) should place them in different
> directories.

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

> Anyway, after re-reading the thread, I remember why we chose to do it
> the way we did it.  It does make sense, even thought I still find it
> not ideal.

 I am looking forward to seeing any proposals for improvements.

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

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

On Jun 13, 2003, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

>  OK, then what about the following example: on an i386-linux system I have
> three shared binaries of libbfd, one is for i386-linux host and i386-linux
> target, another one is for i386-linux host and mipsel-linux target and the
> last one is for mipsel-linux host and mipsel-linux target.

$(exec_prefix)/$(target_alias) should place them in different
directories.

>  Anyway see 'http://sources.redhat.com/ml/binutils/2002-05/msg00184.html'
> and its follow ups for the origin of the choice -- as you took part in the
> discussion, I'm actually surprised you are not aware of the current setup.

/me claims faulty memory, in self defense :-)

/me notes that the original thread subject was bfd.h, and
$(includedir) is part of $(prefix), not $(exec_prefix) like $(libdir).

Anyway, after re-reading the thread, I remember why we chose to do it
the way we did it.  It does make sense, even thought I still find it
not ideal.

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

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

On 12 Jun 2003, Alexandre Oliva wrote:

> >  That's the place for libbfd for the host
> 
> Exactly.  $exec_prefix is already supposed to be host-specific, so you
> don't need $host_alias there again.  If you build bfd for other
> targets, target_alias will be different from host_alias, and
> everything is fine, each libbfd will be in a separate directory.
> Unless you start building different libbfds for the same pair
> (host,target), exec_prefix and target[_alias] should be enough to keep
> them apart.

 OK, then what about the following example: on an i386-linux system I have
three shared binaries of libbfd, one is for i386-linux host and i386-linux
target, another one is for i386-linux host and mipsel-linux target and the
last one is for mipsel-linux host and mipsel-linux target.  Which one
should go where? 

 Anyway see 'http://sources.redhat.com/ml/binutils/2002-05/msg00184.html'
and its follow ups for the origin of the choice -- as you took part in the
discussion, I'm actually surprised you are not aware of the current setup.

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

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

On Jun 12, 2003, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

>> What's wrong with $exec_prefix/$target_alias/lib?  What "other" versions
>> of libbfd?

>  That's the place for libbfd for the host

Exactly.  $exec_prefix is already supposed to be host-specific, so you
don't need $host_alias there again.  If you build bfd for other
targets, target_alias will be different from host_alias, and
everything is fine, each libbfd will be in a separate directory.
Unless you start building different libbfds for the same pair
(host,target), exec_prefix and target[_alias] should be enough to keep
them apart.

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

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

On Thu, 12 Jun 2003, Bernd Jendrissek wrote:

> >  But libbfd is target-specific, so you can't install it directly in
> 
> That sounds like an artificial limitation.  Maybe it works best in
> single-target configuration, but I've been using it with --enable-targets=all
> for the last year or two.

 Not a limitation, but a configuration choice.  I don't want to enable all
targets and I want to keep all target configurations self contained --
suitable for binary packaging.

> > $exec_prefix/$target_alias/$host_alias/lib.  Of coures neither
> > $exec_prefix/lib nor $exec_prefix/$target_alias/lib can be used as they
> > (may) hold other versions of libbfd and $exec_prefix/$host_alias cannot
> > be, either, as it would work for a single target only. 
> 
> What's wrong with $exec_prefix/$target_alias/lib?  What "other" versions
> of libbfd?

 That's the place for libbfd for the host, e.g. assuming the build system
is i386-linux: 

- $exec_prefix/lib/libbfd.la: i386-linux host binary for i386-linux
target,

- $exec_prefix/alpha-linux/lib/libbfd.la: alpha-linux host binary for
alpha-linux target,

- $exec_prefix/i386-linux/alpha-linux/lib/libbfd.la: i386-linux host
binary for alpha-linux target,

- $exec_prefix/i386-linux/mipsel-linux/lib/libbfd.la: i386-linux host
binary for mipsel-linux target

- $exec_prefix/mipsel-linux/lib/libbfd.la: mipsel-linux host binary for
mipsel-linux target. 

> Again, $exec_prefix/lib works just fine here with --enable-targets=all'ed
> binutils.

 I suppose so, but I don't want such a configuration.

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

Re: Partial autoconf transition thoughts

[Bernd Jendrissek]

On Thu, Jun 12, 2003 at 01:22:11PM +0200, Maciej W. Rozycki wrote:
> On 11 Jun 2003, Alexandre Oliva wrote:
> > >  Well, see how AM_INSTALL_LIBBFD is defined. ;-)
> > 
> > Presumably you're configuring with --enable-shared
> > --enable-install-libbfd.  I'd never done that :-)
> > 
> > Anyway, $(exec_prefix)/$(host_alias) is entirely pointless.
> > $(exec_prefix) is already supposed to be host-specific.
> 
>  But libbfd is target-specific, so you can't install it directly in

That sounds like an artificial limitation.  Maybe it works best in
single-target configuration, but I've been using it with --enable-targets=all
for the last year or two.

But in Real Life (tm) I've had to LART my binutils build scripts quite a
bit to convince my first cross-binutils to use my *one* libbfd (in /usr/lib).

> $exec_prefix.  As the result of the discussion I wrote of, the current
> approach was selected from two alternatives: 
> $exec_prefix/$host_alias/$target_alias/lib and
> $exec_prefix/$target_alias/$host_alias/lib.  Of coures neither
> $exec_prefix/lib nor $exec_prefix/$target_alias/lib can be used as they
> (may) hold other versions of libbfd and $exec_prefix/$host_alias cannot
> be, either, as it would work for a single target only. 

What's wrong with $exec_prefix/$target_alias/lib?  What "other" versions
of libbfd?



Again, $exec_prefix/lib works just fine here with --enable-targets=all'ed
binutils.

(Unfortunately the binutils *tools* are still configured for a single
target, which is why I put them into per-target directories.)

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

On 11 Jun 2003, Alexandre Oliva wrote:

> >  Well, see how AM_INSTALL_LIBBFD is defined. ;-)
> 
> Presumably you're configuring with --enable-shared
> --enable-install-libbfd.  I'd never done that :-)
> 
> Anyway, $(exec_prefix)/$(host_alias) is entirely pointless.
> $(exec_prefix) is already supposed to be host-specific.

 But libbfd is target-specific, so you can't install it directly in
$exec_prefix.  As the result of the discussion I wrote of, the current
approach was selected from two alternatives: 
$exec_prefix/$host_alias/$target_alias/lib and
$exec_prefix/$target_alias/$host_alias/lib.  Of coures neither
$exec_prefix/lib nor $exec_prefix/$target_alias/lib can be used as they
(may) hold other versions of libbfd and $exec_prefix/$host_alias cannot
be, either, as it would work for a single target only. 

> >  Why is that so?  I am looking at what autoconf does right now and I can
> > see that $ac_cv_host_alias is set to $ac_cv_build_alias if $host_alias is
> > empty and $ac_cv_target_alias is set to ac_cv_host_alias if $target_alias
> > is empty.
> 
> Which autoconf are you looking at?

 2.57

> > I hope not for the lone reason of differing between
> > implied and user-specified values
> 
> This was the reason for the behavior change, yes.

 IMHO, it should be stated explicitly, e.g. $host_cross and $target_cross
be set to "yes" if --host and --target are specified by a user,
respectively, otherwise they should be set to "no" and
${build,host,target}_alias should be set to valid system names
unconditionally.  This should simplify the generated output and move the
decision on native vs cross to a single place. 

> >  That's a reasonable approach for now, but why can't autoconf be fixed
> > ultimately? 
> 
> I can't think of any reason for that.  But we're trying to move to
> autoconf 2.57, not some hacked version thereof, so we have to cope
> with its limitations for now.

 OK, so I assume that's more an accident during the transition to the new
setup of 2.5x than a design decision.  Good.

> >  Indeed, but I would prefer to see it done in autoconf so that it need not
> > be repeated locally elsewhere.
> 
> It feels like you're volunteering to convert Nathanael's macros into
> autoconf, do I read it right? :-D :-D

 I would actually do that a bit differetly, more or less as I stated
above, but I would of course look at the Nathanael's macros and reuse to
good bits.  Anyway don't hold your breath -- I lack time these days
desperately.  I'll look at this problem when I can afford.

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

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

On Jun 11, 2003, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

>  It's good we do that, but it's bad autoconf does not.  Any reasonable
> justification?

It just isn't there.  I don't remember whether Nathanael tried to
contribute his macros to autoconf.  I do agree they'd make sense.

>  Well, see how AM_INSTALL_LIBBFD is defined. ;-)

Presumably you're configuring with --enable-shared
--enable-install-libbfd.  I'd never done that :-)

Anyway, $(exec_prefix)/$(host_alias) is entirely pointless.
$(exec_prefix) is already supposed to be host-specific.

>  Why is that so?  I am looking at what autoconf does right now and I can
> see that $ac_cv_host_alias is set to $ac_cv_build_alias if $host_alias is
> empty and $ac_cv_target_alias is set to ac_cv_host_alias if $target_alias
> is empty.

Which autoconf are you looking at?

> I hope not for the lone reason of differing between
> implied and user-specified values

This was the reason for the behavior change, yes.

>  That's a reasonable approach for now, but why can't autoconf be fixed
> ultimately? 

I can't think of any reason for that.  But we're trying to move to
autoconf 2.57, not some hacked version thereof, so we have to cope
with its limitations for now.

>  Indeed, but I would prefer to see it done in autoconf so that it need not
> be repeated locally elsewhere.

It feels like you're volunteering to convert Nathanael's macros into
autoconf, do I read it right? :-D :-D

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

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

On 11 Jun 2003, Alexandre Oliva wrote:

> >  Agreed, as long as there is a way to have $host_alias and $target_alias
> > set up as desired. 
> 
> We (toplevel, not autoconf) call them $host_noncanonical and
> $target_noncanonical now.  autoconf no longer provides this feature.

 It's good we do that, but it's bad autoconf does not.  Any reasonable
justification?

> > $ locate libbfd-2.13.2.1.so
> > /usr/i386-linux/mips64el-linux/lib/libbfd-2.13.2.1.so
> > /usr/i386-linux/mipsel-linux/lib/libbfd-2.13.2.1.so
> > /usr/lib/libbfd-2.13.2.1.so
> 
> > Where does that "i386-linux" above come from, then?
> 
> Seems like an artifact of your install.  I don't think we use host in
> install pathnames by default.

 Well, see how AM_INSTALL_LIBBFD is defined. ;-)  There was a discussion
last year...

> >  Well, this is probably an option, but I don't know why such a
> > complication necessary.
> 
> It's necessary because of changes in autoconf that make the
> propagation of command-line flags from build to host and host to
> target not easily available.  If we want to avoid using the

 Why is that so?  I am looking at what autoconf does right now and I can
see that $ac_cv_host_alias is set to $ac_cv_build_alias if $host_alias is
empty and $ac_cv_target_alias is set to ac_cv_host_alias if $target_alias
is empty.  Why can't the same be done for $host_alias and $target_alias at
the same place?  I hope not for the lone reason of differing between
implied and user-specified values -- it can be trivially be done
differently and more explicitly => cleanlier. 

> canonicalized names, which we do, using the macros written by
> Nathanael is pretty much the only way to go.

 That's a reasonable approach for now, but why can't autoconf be fixed
ultimately? 

> > Have you seen the dependency graphs I sent yesterday?  I believe my
> > proposal is the simplest solution.
> 
> I believe Nathanael's macros are the implementation of the solution.
> BTW, we already use them.  See config/acx.m4.

 Indeed, but I would prefer to see it done in autoconf so that it need not
be repeated locally elsewhere.

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

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

On Jun 11, 2003, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

> On 10 Jun 2003, Alexandre Oliva wrote:
>> >  Well, if I specify --host, I mean I want to use a different alias than
>> > the one that is expanded by config.sub.
>> 
>> --host has absolutely nothing to do with config.sub.  --host defaults

>  Has it?  AFAIR, whatever you specify as --host gets passed through
> config.sub before it gets assigned to $host (I'm prepending that "$" now
> to disambiguate variable references).

Err...  Yes, that's correct.  Ok, they have something to do with each
other, after all :-)

>> to --build, that defaults to the output of config.guess.  If you want
>> to override --build, just do it, and it will be propagated to host as

>  But it will be substituted by config.sub first and the original value 
> won't be propagated to $host_alias, will it?

With autoconf 2.5x, $host_alias will be set to whatever is passed as
argument to --host.  If --host is not given, $host_alias will be
blank, and $host will be the canonicalized version of the build
machine.

>  Agreed, as long as there is a way to have $host_alias and $target_alias
> set up as desired. 

We (toplevel, not autoconf) call them $host_noncanonical and
$target_noncanonical now.  autoconf no longer provides this feature.

> $ locate libbfd-2.13.2.1.so
> /usr/i386-linux/mips64el-linux/lib/libbfd-2.13.2.1.so
> /usr/i386-linux/mipsel-linux/lib/libbfd-2.13.2.1.so
> /usr/lib/libbfd-2.13.2.1.so

> Where does that "i386-linux" above come from, then?

Seems like an artifact of your install.  I don't think we use host in
install pathnames by default.

>  Well, this is probably an option, but I don't know why such a
> complication necessary.

It's necessary because of changes in autoconf that make the
propagation of command-line flags from build to host and host to
target not easily available.  If we want to avoid using the
canonicalized names, which we do, using the macros written by
Nathanael is pretty much the only way to go.

> Have you seen the dependency graphs I sent yesterday?  I believe my
> proposal is the simplest solution.

I believe Nathanael's macros are the implementation of the solution.
BTW, we already use them.  See config/acx.m4.

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

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

On 10 Jun 2003, Alexandre Oliva wrote:

> >  Well, if I specify --host, I mean I want to use a different alias than
> > the one that is expanded by config.sub.
> 
> --host has absolutely nothing to do with config.sub.  --host defaults

 Has it?  AFAIR, whatever you specify as --host gets passed through
config.sub before it gets assigned to $host (I'm prepending that "$" now
to disambiguate variable references).

> to --build, that defaults to the output of config.guess.  If you want
> to override --build, just do it, and it will be propagated to host as

 But it will be substituted by config.sub first and the original value 
won't be propagated to $host_alias, will it?

> well.  If you mean to specify different --build and --hosts, that's a
> cross.  If you specify --build and --host and they're identical,
> that's a native for now, but it'll eventually be a cross because
> there's no point in specifying --host if you don't want a cross.

 Agreed, as long as there is a way to have $host_alias and $target_alias
set up as desired. 

> > The change is not purely internal
> > to the compilation process -- there are examples, binutils and gcc
> > inclusive, where this alias gets propagated to file names, e.g. as a
> > prefix to executables or as a name of the tooldir.
> 
> That's --target, something entirely different.

 Hmm:

$ locate libbfd-2.13.2.1.so
/usr/i386-linux/mips64el-linux/lib/libbfd-2.13.2.1.so
/usr/i386-linux/mipsel-linux/lib/libbfd-2.13.2.1.so
/usr/lib/libbfd-2.13.2.1.so
$ 

Where does that "i386-linux" above come from, then?  That's nitpicking
anyway -- the same comment applies to $target_alias equally well.

> >  I'd like to see this capability preserved, not necessarily exactly the
> > way it's being done now.  One possibility for host_alias and also
> > target_alias is to default to build_alias and host_alias instead of host
> > and target, respectively, as it happens now. 
> 
> Huh?  Where is it that host_alias defaults to build or build_alias?
> In autoconf, it defaults to neither.  If --host is not specified,
> host_alias remains blank, not the same as build_alias, not the same as

 That's an internal implementation detail -- I simplified to avoid
complicated dissertations.  AFAIK, if $host_alias is non-empty it is its
value that gets propagated to file names, otherwise the value of $host is
used (ditto about $target_alias and $target).  This is what I mean by
stating "$host_alias defaults to $host" (i.e. I am not really interested
in how autoconf handles ${build,host,target}_alias" internally, but in the
end result visible to a user).  And that's probably the source of
confusion.  And I am not sure why it needs to be done in such a
complicated way. 

> nonopt, not the same as the output of config.guess.  Nathan was kind
> enough to write macros that do exactly what you want, AFAICT, setting
> {build,host,target}_noncanonical, which is what we'd now use for what
> we used to use {build,host,target}_alias, whose meaning is slightly
> different in autoconf 2.5x.  I.e., it does what you already.

 Well, this is probably an option, but I don't know why such a
complication necessary.  Have you seen the dependency graphs I sent
yesterday?  I believe my proposal is the simplest solution. 

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

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

On Jun 10, 2003, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

>  Well, if I specify --host, I mean I want to use a different alias than
> the one that is expanded by config.sub.

--host has absolutely nothing to do with config.sub.  --host defaults
to --build, that defaults to the output of config.guess.  If you want
to override --build, just do it, and it will be propagated to host as
well.  If you mean to specify different --build and --hosts, that's a
cross.  If you specify --build and --host and they're identical,
that's a native for now, but it'll eventually be a cross because
there's no point in specifying --host if you don't want a cross.

> The change is not purely internal
> to the compilation process -- there are examples, binutils and gcc
> inclusive, where this alias gets propagated to file names, e.g. as a
> prefix to executables or as a name of the tooldir.

That's --target, something entirely different.

>  I'd like to see this capability preserved, not necessarily exactly the
> way it's being done now.  One possibility for host_alias and also
> target_alias is to default to build_alias and host_alias instead of host
> and target, respectively, as it happens now. 

Huh?  Where is it that host_alias defaults to build or build_alias?
In autoconf, it defaults to neither.  If --host is not specified,
host_alias remains blank, not the same as build_alias, not the same as
nonopt, not the same as the output of config.guess.  Nathan was kind
enough to write macros that do exactly what you want, AFAICT, setting
{build,host,target}_noncanonical, which is what we'd now use for what
we used to use {build,host,target}_alias, whose meaning is slightly
different in autoconf 2.5x.  I.e., it does what you already.

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

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

On Tue, 10 Jun 2003, Andreas Schwab wrote:

> |>  Well, if I specify --host, I mean I want to use a different alias than
> |> the one that is expanded by config.sub.
> 
> I think you are supposed to use --build instead.

 But then host (correctly) defaults to build but host_alias (incorrectly) 
defaults to host.  I mean the current dependency between variables in
autoconf is as follows ("(sub)" meaning passing through config.sub): 

                guess
                   |
override -(sub)-+  |
|               |  |
v               v  v
build_alias <-- build
                   |
override -(sub)-+  |
|               |  |
v               v  v
host_alias <--- host
                   |
override -(sub)-+  |
|               |  |
v               v  v
target_alias <- target

And I would like to see it as follows:

            guess
            |
            v
override -> build_alias --(sub)-> build
            |
            v
override -> host_alias ---(sub)-> host
            |
            v
override -> target_alias -(sub)-> target

I think it makes sense and the dependencies seem even simpler. 

  Maciej

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

Re: Partial autoconf transition thoughts

[Andreas Schwab]

"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:

|>  Well, if I specify --host, I mean I want to use a different alias than
|> the one that is expanded by config.sub.

I think you are supposed to use --build instead.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Partial autoconf transition thoughts

[Maciej W. Rozycki]

On 9 Jun 2003, Alexandre Oliva wrote:

> >>> 4.  Specify the same thing for both
> >>> 2.13: Both will be overridden; test $CC for cross mode.
> >>> 2.57: Both will be overridden, will build natively.
> >> 
> >> Except that building natively is deprecated, and autoconf people have
> >> already pushed for removing this alternative.  We probably don't want
> > Whaaaat?  This seems like a rather dumb idea with no serious benefit.
> 
> Be my guest in pushing against this.  I tried it, and gave up.  The
> idea that won was that, if you specify --host, you mean to cross
> compile, even if you specify the same triplet that you specify for
> --build.  I can't really say it's a bad idea, it just looks bad
> because it's different from what we've had for a long time.  The
> current test for $build = $host is there to ease the transition, and
> it will go away in autoconf 3.0, whenever that comes out, hopefully
> 5-10 years from now.

 Well, if I specify --host, I mean I want to use a different alias than
the one that is expanded by config.sub.  The change is not purely internal
to the compilation process -- there are examples, binutils and gcc
inclusive, where this alias gets propagated to file names, e.g. as a
prefix to executables or as a name of the tooldir.

 I'd like to see this capability preserved, not necessarily exactly the
way it's being done now.  One possibility for host_alias and also
target_alias is to default to build_alias and host_alias instead of host
and target, respectively, as it happens now. 

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

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

On Jun  9, 2003, Nathanael Nerode <neroden@twcny.rr.com> wrote:

> Alexandre Oliva said:
>> On Jun  9, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:
>> 
>>> 4.  Specify the same thing for both
>>> 2.13: Both will be overridden; test $CC for cross mode.
>>> 2.57: Both will be overridden, will build natively.
>> 
>> Except that building natively is deprecated, and autoconf people have
>> already pushed for removing this alternative.  We probably don't want
> Whaaaat?  This seems like a rather dumb idea with no serious benefit.

Be my guest in pushing against this.  I tried it, and gave up.  The
idea that won was that, if you specify --host, you mean to cross
compile, even if you specify the same triplet that you specify for
--build.  I can't really say it's a bad idea, it just looks bad
because it's different from what we've had for a long time.  The
current test for $build = $host is there to ease the transition, and
it will go away in autoconf 3.0, whenever that comes out, hopefully
5-10 years from now.

> Let's look at this another way.  What are the *differences* between a
> build=host compilation and a build!=host compilation?

You can't run tests in the latter case, you can't assume that the
presence of file or device names in the build machiine reflects what's
going to be in the host machine.  I'm probably forgetting other
issues.

> I proceed on the principle that there are no real, fundamental 
> differences between a native configuration and a cross configuration, 
> and this generally creates the cleanest configury code.

I.e., assume you're always cross compiling?  That would be a
reasonable approach too, but there are some tests that you can't
possibly do in the cross case, autoconf lets you actually do them in
the native case as long as you set a safe default or alternate test
for the cross case.

> Absolutely.  We're already passing a complete set down to the 'target' 
> directories and to the 'build' directories.  I think we should also pass 
> a complete set down to the 'host' directories, and they should be bright 
> enough to understand that if build=host, build=host.  (Regardless of 
> what some autoconf people may be advocating.)

autoconf is not going to support this, so we have two options: stop
using autoconf, or following their lead.  I'm for the latter.  As much
as I've disliked the transition path, I do think their goal was a
perfectly reasonable one, and wish it had been like that from the
beginning.

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

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

On Jun  9, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:

> I understand that, and how to do it.  But _what_ different arguments do
> you want?  What's the mapping?

To autoconf 2.5x directories, pass exactly what the user specified.
To 2.13 ones, expand --build, --host and --target per 2.5x rules and
pass them all.  Then we can switch the toplevel to 2.5x without any
behavior changes.

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

Re: Partial autoconf transition thoughts

[Nathanael Nerode]

Alexandre Oliva said:
>On Jun  9, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:
>
>> 4.  Specify the same thing for both
>>       2.13: Both will be overridden; test $CC for cross mode.
>>       2.57: Both will be overridden, will build natively.
>
>Except that building natively is deprecated, and autoconf people have
>already pushed for removing this alternative.  We probably don't want
Whaaaat?  This seems like a rather dumb idea with no serious benefit.

--
Let's look at this another way.  What are the *differences* between a
build=host compilation and a build!=host compilation?

1. Certain tools used while building have different names.
I have effectively isolated this issue into macros in config/acx.m4.
They can be improved if necessary, but they're already quite clever.
More importantly, *we* have control over these and can make them decide
based on *our* choice of when it's appropriate.

2. Testing can be done on the build machine.
Not a configuration issue!

3. Certain headers are to be found in a different place.
This is a legitimate difference, which might induce a desire for 
'cross-building' when build=host, but it can be specified explicitly in 
other ways already, I believe.

4. Certain libraries are found in different places.  In the case of 
static linking, this is the same as the above.  In the case of dynamic 
linking, this should be manually overridable (and it seems to be 
moderately hit-and-miss in the cross case anyway, given 
inconsistent dynamic library naming and locating schemes).  

I can think of no other differences.

I proceed on the principle that there are no real, fundamental 
differences between a native configuration and a cross configuration, 
and this generally creates the cleanest configury code.


>What configure arguments?  Did you pass i386-linux in the command
>line?  Maybe one of --build or --host?  The worst case to handle IMO
>is that of passing --build, since then autoconf 2.13 directories will
>guess --host from config.guess, whereas autoconf 2.57 will default
>host to build.  If they're different, we get an inconsistent build
>across directories.  That's why I think we should resolve the flags in
>the top level, and decide what to pass to each sub-directory.

Absolutely.  We're already passing a complete set down to the 'target' 
directories and to the 'build' directories.  I think we should also pass 
a complete set down to the 'host' directories, and they should be bright 
enough to understand that if build=host, build=host.  (Regardless of 
what some autoconf people may be advocating.)

--Nathanael

Re: Partial autoconf transition thoughts

[Daniel Jacobowitz]

On Mon, Jun 09, 2003 at 07:34:00PM -0300, Alexandre Oliva wrote:
> On Jun  9, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > 4.  Specify the same thing for both
> > 	2.13: Both will be overridden; test $CC for cross mode.
> > 	2.57: Both will be overridden, will build natively.
> 
> Except that building natively is deprecated, and autoconf people have
> already pushed for removing this alternative.  We probably don't want
> to rely on it, unless the entire transition is going to be *very*
> short, and I don't think it can possibly be, since we're not going to
> have simultaneous releases of all of gcc, binutils, gdb and newlib,
> such that one could take all of them after the conversion and build a
> unified tree.

As I told Alex on IRC, I was looking at the upgrading-from-2.13 section
of the manual (where it isn't clear that this is deprecated) and the
generated configures (where it obviously works).

My instinct is to rely upon this deprecated feature of 2.57 as it is
easy to remove once we have transitioned all directories, which I
expect to be fairly quick.

> > So I guess I don't see what the problem is with doing one directory at a
> > time.
> 
> There are also libtool issues.  We want to use a single libtool.m4,
> and you say our current libtool.m4 doesn't work with autoconf 2.5x
> (did I misunderstand?), and this was a problem I didn't know about
> before.

Nope, pilot error on my part.  It works fine here.  I even did both
autoconf and automake in the gas directory.

> > There are existence proofs that this (mostly!) works -
> > readline has been using autoconf 2.57 since its last import.
> 
> I've heard people complain it was being configured as if for cross
> compilation even on native builds.

Has never happened to me.

> > Could someone who thinks this won't work please speak up, before I
> > waste a lot of time?
> 
> It should mostly work, but I still think we should pass different
> arguments to sub-configures depending on which version of autoconf was
> used to configure them.

I understand that, and how to do it.  But _what_ different arguments do
you want?  What's the mapping?

When I sat down to work out the mapping I produced my original table
and decided I didn't need a mapping at all.

> > I tested a native build on i386-linux
> 
> What configure arguments?  Did you pass i386-linux in the command
> line?  Maybe one of --build or --host?  The worst case to handle IMO
> is that of passing --build, since then autoconf 2.13 directories will
> guess --host from config.guess, whereas autoconf 2.57 will default
> host to build.  If they're different, we get an inconsistent build
> across directories.  That's why I think we should resolve the flags in
> the top level, and decide what to pass to each sub-directory.

I jut retried these:
--build=i686-linux --host=i686-linux
--build=i686-linux
--host=i686-linux
i686-linux
<none>

All five worked fine.  Perhaps I'll do libiberty next.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Partial autoconf transition thoughts

[Alexandre Oliva]

On Jun  9, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:

> 4.  Specify the same thing for both
> 	2.13: Both will be overridden; test $CC for cross mode.
> 	2.57: Both will be overridden, will build natively.

Except that building natively is deprecated, and autoconf people have
already pushed for removing this alternative.  We probably don't want
to rely on it, unless the entire transition is going to be *very*
short, and I don't think it can possibly be, since we're not going to
have simultaneous releases of all of gcc, binutils, gdb and newlib,
such that one could take all of them after the conversion and build a
unified tree.

> So I guess I don't see what the problem is with doing one directory at a
> time.

There are also libtool issues.  We want to use a single libtool.m4,
and you say our current libtool.m4 doesn't work with autoconf 2.5x
(did I misunderstand?), and this was a problem I didn't know about
before.

> There are existence proofs that this (mostly!) works -
> readline has been using autoconf 2.57 since its last import.

I've heard people complain it was being configured as if for cross
compilation even on native builds.

> Could someone who thinks this won't work please speak up, before I
> waste a lot of time?

It should mostly work, but I still think we should pass different
arguments to sub-configures depending on which version of autoconf was
used to configure them.

> I tested a native build on i386-linux

What configure arguments?  Did you pass i386-linux in the command
line?  Maybe one of --build or --host?  The worst case to handle IMO
is that of passing --build, since then autoconf 2.13 directories will
guess --host from config.guess, whereas autoconf 2.57 will default
host to build.  If they're different, we get an inconsistent build
across directories.  That's why I think we should resolve the flags in
the top level, and decide what to pass to each sub-directory.

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

Re: Partial autoconf transition thoughts

[Andrew Cagney]

> readline has been using autoconf 2.57 since its last import.

Shhhhhh, you're not ment to be telling people this :-^

Partial autoconf transition thoughts

[Daniel Jacobowitz]

[Sorry for the cross posting; I'm waiting for Zack et al. to figure out
where the new list should be.]

I spent some time today reviewing the --host/--build issues.  Fortunately,
target isn't relevant to autoconf's choices at this stage.

Consider the options:

	Build	Host
1	-	-
2	-	A
3	A	-
4	A	A
5	A	B

With plain target ("nonopt"), configure will act as if any unspecified
options had been given on the command line with the plain target as a value.

1.  Native build
	2.13: Native-build a compiler to run on the local system; test 
	      $CC for cross mode.
	2.57: Native-build a compiler to run on the local system
2.  Specify only host
	2.13: Assume that $build is $host; test $CC for cross mode.
	2.57: Same, but considered "deprecated", according to the manual.
	      However, based on generated configure, build will be guessed,
	      and cross compilation will be tested by running a program.
3.  Specify only build
	2.13: Host will be guessed; test $CC for cross mode.
	2.57: Host will default to $build, will build natively.
4.  Specify the same thing for both
	2.13: Both will be overridden; test $CC for cross mode.
	2.57: Both will be overridden, will build natively.
5.  Specify both different.
	2.13: Both will be overridden, test $CC for cross mode.
	2.57: Both will be overridden, will enter cross mode.


So I guess I don't see what the problem is with doing one directory at a
time.  If you want to build a compiler that runs on the build machine, then
we can always pass $build and $host to subdirectories with the same value;
if you want to build a compiler that runs on another machine, require the
user to specify --build and --host differently and always pass those to
subdirectories, and as long as $CC is a cross compiler both autoconfs will
do the right thing.  There are existence proofs that this (mostly!) works -
readline has been using autoconf 2.57 since its last import.  The readline
configure has issues cross compiling though, so don't treat it as an
example.

Could someone who thinks this won't work please speak up, before I waste a
lot of time?


As a proof of concept, I took gas/, and did a trivial convertion (with a
little help from Klee's patches:
  http://sources.redhat.com/ml/sid/2003-q1/msg00003.html
but not using some of the tricky bits).  The results were fine.  I tested a
native build on i386-linux and a --build=i686-pc-linux-gnu
--host=mipsel-hardhat-linux-gnu build, because that's what I had handy. 
What other cases are tricky and meaningful?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer