On 7/15/2010 1:50 PM, Yaakov (Cygwin/X) wrote:
> As promised, here is my response to the mingw-w64 ITP.
>
> cygport now supports several scenarios:
>
> 1) Cygwin-hosted (cross-)compilers, via toolchain.cygclass
>
> This is exclusively for binutils, gcc, and gdb, either Cygwin-native or
> any other platform they support. The attached examples use a one-line
> patch to config.rpath to link dynamically with libintl, but do not ship
> the actual locale files, relying on the native versions' instead (as
> theirs would collide and refuse to relocate, as previously discussed).
>
> All cross-compilers use the default sysroot, /usr/$target/sys-root.
> MinGW libgcc and friends are relocated to the sysroot bindir, just as on
> Fedora.
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.
These notes are related to my experience rebuilding all four of the
*cross* toolchains and their core support libraries (runtime, w32api,
pthreads, etc).
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).
General toolchain cygclass notes:
=================================
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:
--- syntax.cygpart.old 2010-07-15 13:38:33.001000000 -0400
+++ syntax.cygpart.new 2010-07-17 08:47:30.539000000 -0400
@@ -139,6 +139,8 @@
# FIXME: certainly other exceptions exist?
case ${CHOST} in
*-*-mingw*) prefix=/mingw ;;
+ x86_64-w64-mingw*) prefix=/mingw64 ;;
+ i686-w64-mingw*) prefix=/mingw64-32 ;;
*) prefix=/usr ;;
esac
So we can easily adapt if the #mingw64 folks recommend something
different than /mingw. Let it go for now, but let's see what
#mingw64 have to say about that -- especially JonY, since he is
the person actually ITPing the mingw64* cross toolchains.
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.
Fortunately, that is also an easy change. For example:
--- syntax.cygpart.old 2010-07-15 13:38:33.001000000 -0400
+++ syntax.cygpart.new 2010-07-17 08:55:36.182600000 -0400
@@ -135,6 +135,10 @@
__host_prefix() {
local prefix
+ if [ -n "$CYGPORT_OVERRIDE_PREFIX" -a
x"${CYGPORT_OVERRIDE_PREFIX:0:1}" == x"/" ]
+ then
+ prefix=$CYGPORT_OVERRIDE_PREFIX
+ else
# FIXME: certainly other exceptions exist?
case ${CHOST} in
@@ -142,6 +146,7 @@
*) prefix=/usr ;;
esac
+ fi
echo -n ${prefix}
}
Dead horse issues, restating:
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
Maybe even ALL such documentation (e.g. by using --datarootdir), and
then *copies* of the man1 pages put in the usual /usr/share/man area.
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.
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. But, that's a
packager/maintainer decision, and has no impact on "cygport(1)"
itself. So table that discussion.
Toolchain bootstrap prep:
==============================
1. Using setup, uninstall existing mingw-runtime-3.18-1 package
(this one was in /usr/{include,lib}/mingw
2. Using setup, install the new mingw-runtime-3.18-1 package
(this one goes into /usr/i686-pc-mingw32/sys-root/mingw/{include,lib}
3. Manually installed new bootstrap packages:
mingw64-i686-pthreads-20100619-1.tar.bz2
mingw64-i686-runtime-20100702-1.tar.bz2
mingw64-x86_64-pthreads-20100619-1.tar.bz2
mingw64-x86_64-runtime-20100702-1.tar.bz2
mingw-w32api-3.14-1.tar.bz2
linux-i686-glibc-2.11.2-1.tar.bz2
linux-i686-kernel-headers-2.6.34.1-1.tar.bz2
4. After building each binutils/gcc package, rebuilt the corresponding
runtime package, manually removed the "bootstrap" version, and
installed the newly built one. Ditto the linux glibc and kernel-
headers packages. (Or, in the case of mingw-runtime, used setup to
manage the uninstall/reinstall process).
5. Then, rebuilt the each corresponding pthreads package, manually
removed the "bootstrap" version, and installed the newly built
one.
6. Ditto, wrt to the mingw-w32api package.
mingw64-i686
==============================
No issues.
mingw64-x86_64:
==============================
I needed to change 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}/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
mingw64-i686: usr/i686-w64-mingw32/lib/lib32/libiberty.a
mingw: usr/i686-pc-mingw32/lib/libiberty.a
linux: usr/i686-pc-linux-gnu/lib/libiberty.a
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?
mingw32
==============================
Before starting the binutils/gcc build, you MUST use setup.exe to remove
gcc-mingw-core
gcc-mingw-g++
gcc-mingw-java
gcc-mingw-objc
and then manually delete the following symlinks (because the uninstall
(preremove) scripts above don't take care of it):
/usr/i686-pc-mingw32/bin
/usr/i686-pc-mingw32/lib
/usr/i686-pc-mingw32/include
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?
The following flags are used in the official mingw compiler, but not here:
--enable-libstdcxx-debug
--enable-shared (but that's okay, as it is default)
--enable-libgomp
--disable-win32-registry
(also, --disable-werror, and language Ada)
The following flags are used here, but not in the official mingw compiler:
--disable-multilib
--enable-lto
--enable-fully-dynamic-strings
Any particular reason for these descrepancies?
I believe --enable-fully-dynamic-strings is correct, but apparently the
official mingw.org 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.
linux
==============================
Is it usual to build linux compilers with --enable-fully-dynamic-strings?
Had to install libelf0 and libelf0-devel packages, in order to build.
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:
mv: cannot stat
`/usr/src/devel/cross/linux/linux-i686-gcc-4.5.0-1/inst/usr/lib/gcc/i686-pc-linux-gnu/lib/libgcc_s.a':
No such file or directory
Anyway, building binutils and gcc went mostly ok, but building glibc did
not. First, I got this error:
echo '' >
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn/stamp.oST
mv -f
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn/stamp.osT
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn/stamp.os
mv -f
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn/stamp.oST
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn/stamp.oS
i686-pc-linux-gnu-gcc sdlclose.c -c -std=gnu99 -fgnu89-inline -O2 -Wall
-Winline -Wwrite-strings -fmerge-all-constants -pipe -Wstrict-prototypes
-mpreferred-stack-boundary=2 -I../include
-I/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn
-I/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build
-I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686
-I../sysdeps/unix/sysv/linux/i386/i686
-I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386
-I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread
-I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
-I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet
-I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv
-I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu
-I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686
-I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu
-I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32
-I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I.. -I../libio
-I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn/sdlclose.o
-MD -MP -MF
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn/sdlclose.o.dt
-MT
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn/sdlclose.o
mv: cannot stat
`/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn/stamp.oST':
No such file or directory
make[2]: ***
[/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/dlfcn/stamp.oS]
Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
`/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/src/glibc-2.11.2/dlfcn'
make[1]: *** [dlfcn/subdir_lib] Error 2
make[1]: Leaving directory
`/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/src/glibc-2.11.2'
which looked like a -jN problem to me. So, I started again with -j1,
but that failed liked this when trying to link ld.so:
i686-pc-linux-gnu-gcc -nostdlib -nostartfiles -shared \
-Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both
-Wl,-z,defs -Wl,--verbose 2>&1 | \
LC_ALL=C \
sed -e '/^=========/,/^=========/!d;/^=========/d' \
-e 's/\. = .* + SIZEOF_HEADERS;/& _begin = . -
SIZEOF_HEADERS;/' \
>
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/ld.so.lds
i686-pc-linux-gnu-gcc -nostdlib -nostartfiles -shared -o
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/ld.so \
-Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both
-Wl,-z,defs \
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/librtld.os -Wl,--version-script=/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/ld.map
\
-Wl,-soname=ld-linux.so.2 -T
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/ld.so.lds
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/librtld.os:
In function `.L125':
rtld.c:(.text+0x1149): undefined reference to `__open'
rtld.c:(.text+0x1328): undefined reference to `__access'
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/librtld.os:
In function `dl_main':
rtld.c:(.text+0x225a): undefined reference to `__access'
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/librtld.os:
In function `lose':
dl-load.c:(.text+0x4c08): undefined reference to `__close'
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/librtld.os:
In function `open_verify':
dl-load.c:(.text+0x4d72): undefined reference to `__open'
dl-load.c:(.text+0x4d86): undefined reference to `rtld_errno'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../i686-pc-linux-gnu/bin/ld:
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/librtld.os:
relocation R_386_GOTOFF against undefined hidden symbol `rtld_errno' can
not be used when making a shared object
/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../i686-pc-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: ***
[/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/ld.so]
Error 1
make[2]: Leaving directory
`/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/src/glibc-2.11.2/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory
`/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/src/glibc-2.11.2'
make: *** [all] Error 2
*** ERROR: make failed
Anyway, that's where I stopped for now. I'll post later after using the
mingw* toolchains to build the various cross packages...but I'm probably
not going to mess with the linux one any further.
--
Chuck