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

   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
+++	2010-07-17 08:55:36.182600000 -0400
@@ -135,6 +135,10 @@

 __host_prefix() {
 	local prefix
x"${CYGPORT_OVERRIDE_PREFIX:0:1}" == x"/" ]
+	then
+	else

 	# FIXME: certainly other exceptions exist?
 	case ${CHOST} in
@@ -142,6 +146,7 @@
 		*)                prefix=/usr ;;

+	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
   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:
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
6. Ditto, wrt to the mingw-w32api package.

No issues.

I needed to change cygport:

-       mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib/libgcc_s.a
+       mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib64/libgcc_s.a

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?

Before starting the binutils/gcc build, you MUST use setup.exe to remove
and then manually delete the following symlinks (because the uninstall
(preremove) scripts above don't take care of it):
However, given the dependency structure of the gcc3 packages, this means
you pretty much have to also remove, using setup,

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-shared (but that's okay, as it is default)
	(also, --disable-werror, and language Ada)
The following flags are used here, but not in the official mingw compiler:
Any particular reason for these descrepancies?

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.

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
#       mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib32/libgcc_s.a

Because there doesn't seem to be any libgcc_s.a file anywhere in the
build or install trees:

mv: cannot stat
No such file or directory

Anyway, building binutils and gcc went mostly ok, but building glibc did
not. First, I got this error:

echo '' >
mv -f
mv -f
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../sysdeps/i386/elf -I../nptl/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
mv: cannot stat
No such file or directory
make[2]: ***
Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
make[1]: *** [dlfcn/subdir_lib] Error 2
make[1]: Leaving directory

which looked like a -jN problem to me.  So, I started again with -j1,
but that failed liked this when trying to link

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 = . -
i686-pc-linux-gnu-gcc   -nostdlib -nostartfiles -shared -o
/usr/src/devel/cross/linux/linux-i686-glibc-2.11.2-1/build/elf/  \
                  -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/
                  -Wl, -T
In function `.L125':
rtld.c:(.text+0x1149): undefined reference to `__open'
rtld.c:(.text+0x1328): undefined reference to `__access'
In function `dl_main':
rtld.c:(.text+0x225a): undefined reference to `__access'
In function `lose':
dl-load.c:(.text+0x4c08): undefined reference to `__close'
In function `open_verify':
dl-load.c:(.text+0x4d72): undefined reference to `__open'
dl-load.c:(.text+0x4d86): undefined reference to `rtld_errno'
relocation R_386_GOTOFF against undefined hidden symbol `rtld_errno' can
not be used when making a shared object
final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: ***
Error 1
make[2]: Leaving directory
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory
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.


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