This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: cygport cross-compiling APIs


I think I'm getting close to nailing down cross-compiling support in
cygport.

Throughout, the prefix=/usr assumption has been removed; *-*-mingw*
hosts use /mingw, everything else is /usr for now.  (Anyone know any
specific systems where that's not the case?)  Cross-compiled packages
are properly strip(1)ed with the correct binutils.  Libtool fixup puts
non-native DLLs into $CROSS_HOST/prefix/bin if not already there, and
doesn't move non-PE libs but still removes static modules.  Also,
package dependencies for mingw* and linux* cross-compiles are supported.
While I was at it, some initial work was done to make adapting to a
possible future x86_64-pc-cygwin easier as well.

Here's what the API looks like so far:

toolchain.cygclass: for building binutils/gcc/gdb (cross-)compilers
* TOOLCHAIN_TARGET: the target triplet (defined in .cygport BEFORE
"inherit toolchain")
* toolchain_compile(): runs cygconf with --build/host/target and
--with-sysroot, followed by cygmake
* src_compile(): just toolchain_compile; no cygautoreconf (these
packages don't autoreconf easily)

cross.cygclass: for cross-compiling
* CROSS_HOST: the host triplet (defined in .cygport BEFORE "inherit
cross")
* CROSS_SYSROOT: the host sys-root (== /usr/${CROSS_HOST}/sys-root)
* CC/CXX/F77/FC are $host-prefixed
* PKG_CONFIG_LIBDIR and PKG_CONFIG_SYSROOT_DIR are set for pkg-config
* cygconf automatically adds --build/host/target

I implemented the cygconf hook instead of a separate cross_compile() so
that other cygconf-based cygclasses would benefit.  For example, a
mingw64-x86_64-glib2.0 would "inherit cross gnome2", where
gnome2_compile calls cygconf.

Right now my dilemma is with the cross.cygclass install functions.  I'm
not sure whether cyginstall/do*/new* should just flip personality to
install under $CROSS_SYSROOT (much like cygconf does), or whether to
implement separate docross{bin,include,lib,...} functions.  My reason
for considering the former is that it would reduce duplicate code and
avoid easy mistakes (e.g. installing cross-compiled stuff into native
directories).  It would also make it easier to take a native .cygport,
rename it, define CROSS_HOST and inherit cross, and build.  OTOH I'm not
sure whether the more manually-controlled dodir, exe/insinto, doexe/ins,
and newexe/ins should also imply $CROSS_SYSROOT or not: IOW, is there
any case where a cross-compiled package would legitimately install
anything outside of $CROSS_SYSROOT (besides the standard docs).  I also
wonder if that would itself be confusing.

As for the package naming scheme -- which is not being enforced by
cygport itself -- my thoughts are OS[-CPU]-PACKAGE, IOW:

mingw64-i686-binutils
mingw64-i686-gcc
mingw64-i686-pthreads
mingw64-i686-runtime
mingw64-i686-zlib

mingw64-x86_64-binutils
mingw64-x86_64-gcc
mingw64-x86_64-pthreads
mingw64-x86_64-runtime
mingw64-x86_64-zlib

linux-i686-binutils
linux-i686-gcc
linux-i686-glibc (not built yet; borrowed from Fedora for bootstrapping)
linux-i686-kernel-headers (ditto)
linux-i686-zlib

(none of these are built yet)
mingw-binutils
mingw-bzip2
mingw-gcc
mingw-runtime

And so on.  For simplicity, none of these are multilib, and the
conflicting binutils/gcc locales/info/etc. are removed, for reasons
stated in earlier discussions.

Note that I'm *not* breaking out separate lib/devel packages, because if
you think about the reasons for these splits with native packages,
within the context of cross-compiling they doesn't make sense.

Comments welcome, but let's not bikeshed this.  Hopefully this week or
next I can document this all, clean up the patches, and publish a beta
cygport and .cygport drafts.


Yaakov



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]