tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkgsrc cross-compilation

Taylor R Campbell <> writes:

> My only reservation with the word `host-build' is that it ill matches
> the GNU cross-compilation nomenclature, in which `--build' and
> `--host' are what we (and, well, just about everyone else) currently
> call `host' and `target', respectively.  How about `native-build'
> instead, to avoid that name conflict?

I see your point.   But having had this rattle around in my head for so
long, I have come to the conclusion that if pkgsrc uses "HOST" and
"TARGET" as the only two words, that's fine.

For those not so steeped, autoconf/gcc uses:

  build: the machine you are running the cross build on
  host: the machine you are building the program to run on
  target: the machine the program you built builds binaries for

This is to support the "Canadian Cross", where you can on an i386
machine build a compiler to run on alpha which produces arm binaries.
That's pretty cool, but we don't really need it for the normal case of

So I've come around to the position that other than a few people who are
steeped in autoconf/gcc, people correctly understand "host" and
"target", and correct understanding is the point of naming.

> The patch I made last night got x11/xterm from modular built
> almost completely automatically, including all the xcb tools and stuff
> -- the only manual steps were setting up the NetBSD destdir and
> tooldir, and setting up the cross-libtool kludge.

That sounds excellent; the destdir/tooldir can be automated easily.

If you're feeling brave, you might try that on a Linux or Mac host.[>

> [Aside:  I wonder whether there is an important distinction between
> bootstrap depends and host-build depends.  As I implemented host-build
> it is semantically a bit different, but if -- after careful
> consideration, which I haven't done yet -- it turns out that the
> difference doesn't matter, it might be nice to reduce the number of
> concepts involved.  Something to consider later.]

I think the real difference is that bootstrap is special in that
building bootstrap tools cannot assume that pkgsrc is functional.   So
the difference between bootstrap depends and HOST_BUILD_DEPENDS is
exactly the differene between bootstrap and regular packages in the
native case.

>    Am I missing some complexity?
> A little: buildlink3 depmethod.  Some uses of buildlink3 really want
> HOST_BUILD_DEPENDS, or possibly in some cases both HOST_BUILD_DEPENDS
> and (BUILD_)DEPENDS, but at present, BUILDLINK_DEPMETHOD.mumble can be
> only `full' or `build'.  For now I've provisionally added `host-build'
> as another valid value, but we'll have to revisit that.

I would say that buildlink3 that is HOST_BUILD_DEPENDS is a bug.  If
that's what is wanted, it isn't being linked against, it's a build
tool.  If we decide that USE_TOOLS += foo means to use foo's bl3 with
type host-build, that's ok.  But we neeed to support a set, not an
exclusive option.

> Examples of buildlink3 dependencies that want HOST_BUILD_DEPENDS:
> lang/python/ with PYTHON_FOR_BUILD_ONLY
> textproc/xmlcatmgr/
> It may be that these should just use HOST_BUILD_DEPENDS directly
> instead of, or in addition to, buildlink3, and that buildlink3 makes
> sense only for, well, build and link stuff in the target.  I don't yet
> understand buildlink3 well enough to say.

I think bl3 should be only about target.  The main point is to create a
shadow tree of includes and libraries (and pkg-config) so that
information from the host does not leak into the build (e.g., configure
finding an optional library that is not a dependency but happens to be
installed).  The intended isolation is between the host environment
(which is the target os/cpu environment) and the target build
environment.  Once the host is not the same arch or os as target, this
matters even more, because in the native case a lot of leakage, even
though wrong, doesn't matter.

There is another issue, which is that some packages have scripts
"foo-config" that when called with --libs return libraries to link
against.  There, you want to run those on the host, hoping they will
produce the same answer as if they had been run on the target.  The
right answer is to fix their upstreams to use pkg-config and turn the
config info into data that can be manipulated without risk by a host

Attachment: pgpNyUjI8J8lm.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index