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]

Re: cygport cross-compiling beta1

On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
> Overall, looks pretty good.  I haven't used the new cygport(1) to build
> *any* native cygwin packages yet, however; so I haven't tested how well
> the new toolchain.cygclass works building the native cygwin toolchain.

If TOOLCHAIN_TARGET="i686-pc-cygwin" then all toolchain.cygclass does is
provide a default src_compile().  The cross-compiling magic only kicks
in when $build != $host || $host != $target.

> I'll post more after I use the new tools to build the various non-core
> packages that exercise the cross.cygclass, such as linux-ncurses,
> mingw-bzip2, etc. I'll address issues with libtool/pkgconfig at that
> time, as well (short version: our version of pkgconfig claims to support
> sysroot via $PKG_CONFIG_SYSROOT_DIR, but newer versions have supposedly
> improved that support.  Also, there was one patch, and another promised,
> on libtool-patches addressing just this issue, in the last week).

Where is that discussion?  Fixing libtool is imperative to using the
sysroot the way I'm proposing; otherwise we'll be forced to actually
prepend $sysroot to $prefix.

> 1. As discussed previously, I disagree that all the mingw* toolchains
>    should use --prefix=/mingw; I think the mingw64 ones should use
>    different prefixes, since the mingw64 folks recommend "do not
>    install our stuff into C:\MinGW".  However, AFAIK they have not
>    made any official recommendation wrt cross environments and
>    sysroots.  Fortunately, this is an easy change.  For example:

/mingw is hard-coded in GCC as the default prefix for all mingw*
targets.  That means ($sysroot)/mingw/include and ($sysroot)/mingw/lib
are on the default search paths.  Using another prefix will force
everyone to use -I and -L flags where they otherwise wouldn't be

The opinions I heard on #mingw-w64 was that /mingw was a necessary evil.
IWO they don't "like" it, but it's hard to avoid.

FWIW the Fedora mingw64 packages also use $sysroot/mingw.

> 2. Furthermore, I think it is pretty likely that, for a linux $target,
>    users of a cross toolchain might want to compile for a $prefix
>    other than /usr (obviously the compiler's own core libs like glibc
>    should be in $sysroot/usr, to match the likely location of glibc on
>    the target).  But, for other packages (say, I want to cross-compile
>    my own version of linux-firefox or something)...maybe I don't have
>    root on the linux box and can't install in /usr (or maybe I'm using
>    canadian-cross.cygclass to build, on cygwin, a linux-hosted cygwin-
>    target cross compiler, and I don't want to install that in /usr on
>    the linux machine).  So, I think the ability to override $prefix is
>    necessary at least for the linux toolchain -- and, as I've mentioned
>    before, it is currently useful for the gcc-tool-* packages.

That depends on why you're cross-compiling.  The primary point of making
cross-compiled packages for a distro is not to use them on their host
but to use them for cross-compiling other software in the build's
sysroot, so you want those prefixes to match (think RPATH).  While you
could build that other software which you are going to use on the host
with cygport, that's a secondary benefit IMO (much like canadian-cross).

> 3. Toolchain Documentation (currently deleted during src_install): I
>    think the documentation specific to each cross compiler that
>    conflicts with the native compiler -- e.g. info files, man{2-7}
>    pages not renamed by 'make install' -- should go under
>       /usr/$target/share

Fedora's MinGW packaging policy says clearly that duplicate
documentation should not be included.  Inventing /usr/$target/share for
the sole purpose of info and man pages which won't be found by info or
man anyway doesn't make any sense to me.

> 4. NLS.  I think the cross toolchains should be compiled with
>    --disable-nls, if we can't figure out how to install and use the
>    correct .mo files associated with each compiler.  Otherwise, all such
>    cross compilers must be at exactly the same version as the native
>    one, because they will all share the native compiler's .mo files. I
>    don't think this situation (all compilers using same version) is
>    very likely.

With NLS you will still have at least partial translations, which is
better than nothing, no?

> 5. Packaging: I think that the languages for the compilers should be
>    split into separate packages, and that the language runtime DLLs
>    should have individual packages. Ditto with respect to other
>    packages which provide DLLs, like pthreads etc.

No, no, and NO.

> -       mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib/libgcc_s.a
> ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/${PV[1]}.*/
> +       mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib64/libgcc_s.a
> ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/${PV[1]}.*/


> Also, this packaging oddity:
> 	mingw64-x86_64: usr/x86_64-w64-mingw32/lib64/libiberty.a

x86_64-w64-mingw32 is potentially a multilib arch, hence the lib64.  If
the gcc were actually built multilib, you'd see a lib32 and lib64.

> 	mingw64-i686:   usr/i686-w64-mingw32/lib/lib32/libiberty.a

You mean /usr/i686-w64-mingw32/lib/libiberty.a?  The only way you would
get lib32/libiberty.a (not lib/lib32) is with multilib, which I disabled
in my builds.

> Why the differences? Where should libiberty.a actually live, relative to
> /usr/$target? Is it possible this library should actually get relocated
> to the sysroot?

These locations are correct; libiberty is installed in /usr/$target/lib
$suffix, and like other toolchain components don't get installed into
the sysroot.  This directory is also in the default search path, as you
can see with $target-gcc -print-search-dirs.

> However, given the dependency structure of the gcc3 packages, this means
> you pretty much have to also remove, using setup,
> 	gcc-core
> 	gcc-g++
> 	gcc-java
> 	gcc-objc
> Note that this conflict means that the current gcc-mingw* packages (and,
> thus, the gcc 3.x packages) conflict with the new mingw-gcc-* and
> mingw-binutils-* packages.  Also, this may have implications for the
> upgrade process, when the "real" mingw32-gcc cross toolchain is
> released.  Even if we mark the gcc (3) packages obsolete, we probably
> have to repackage them and their gcc-mingw* friends to fix this upgrade
> problem, and perhaps relieve the conflict. Somehow?

We can just remove the gcc-mingw* deps from gcc3*.  But the bigger
question is, do we still *need* gcc3 in the distro?

> The following flags are used in the official mingw compiler, but not here:
> 	--enable-libstdcxx-debug

Reading the description, I'm not so sure we need (or want) this.

> 	--enable-shared (but that's okay, as it is default)
> 	--enable-libgomp

AFAIK --enable-shared and --enable-libgomp are the defaults.

> 	--disable-win32-registry

Yes, we definitely want this.

> 	(also, --disable-werror,  and language Ada)

Just hadn't bothered with Ada, that's all.

> The following flags are used here, but not in the official mingw compiler:
> 	--disable-multilib
> 	--enable-lto

AFAIK these are actually the defaults.

> I believe --enable-fully-dynamic-strings is correct, but apparently the
> official 4.5.0 release does not use it.
> Because 'mingw-runtime' is an existing package, and the current version
> is 3.18-1, this new version should be -2.

Oops, missed that one.  But the mingw-runtime maintainer should take
care of that when we're up to pushing this.

> Is it usual to build linux compilers with --enable-fully-dynamic-strings?

Apparently not, thanks for catching that.

> Had to install libelf0 and libelf0-devel packages, in order to build.

Right, as LTO uses libelf on ELF targets.

> I don't think either of these two lines belong in the cygport:
>         mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib/libgcc_s.a
> ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/${PV[1]}.*/
> #       mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib32/libgcc_s.a
> ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/4.6.0/32/
> Because there doesn't seem to be any libgcc_s.a file anywhere in the
> build or install trees:

You are correct; copy-and-paste errors.

> Anyway, building binutils and gcc went mostly ok, but building glibc did
> not. 

I am unable to reproduce this, even after cleaning out my sysroot.
While I was at it, I did push an updated gcc and rebuilt glibc, in case
you want to try again.


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