On 05/04/2011 03:58, Yaakov (Cygwin/X) wrote:
> On Mon, 2011-04-04 at 14:23 +0100, Jon TURNEY wrote:
>> I tried jhbuilding the entire X.Org stack using these, and while there are
>> several issues with cross-compiling that source which need fixing,
> Here's what I'm aware of, having built RPMs for the X.Org libraries:
> 1) src/util/makekeys in libX11 is a build-native noinst tool used in the
> buildsystem to create a file. Building it on Linux when cross-compiling
> for Cygwin required overriding X11_CFLAGS (which would get Cygwin's
> system headers instead of glibc's), EXEEXT, and LIBTOOL to
> use /usr/bin/libtool (native) instead of $(top_builddir)/libtool
> 2) Ditto for util/makestrs in libXt.
Have to put this stuff back into fontconfig as well, after commit 
"Make most generated-files cross-compiling-safe by simply including a copy in
the tarball." does not work well for cross-compiling from git :-)
> 3) As we discussed elsewhere, Mesa is clearly not intended for
> cross-compiling. mklib needs a patch to use cross-ar and cross-ranlib,
> and it still needs to be told what system to build for.
Yes, I'm ignoring mesa for the moment
> What else have you encountered?
In addition to those issues:
4) libXt contains an unguarded AC_HAVE_LIBRARY(ws2_32)
This is just wrong anyhow, but for some reason causes libtool to make libXt
and everything which links to it as a static libary only, which then causes
problems building various apps which link with libXaw7 and libXt, as these
cannot both co-exist as static libraries as they contain a DllMain...
5) Configuring fontconfig with
needed to patch that freetype-config, which at the moment unconditionally uses
pkg-config, so it checks PKG_CONFIG instead and so will use the cross
pkg-config if needed (it returns bogus paths if it uses the native pkg-config
and a native freetype-devel package isn't installed)
6) font-util macros needs patching so that all font packages don't try to run
mkfontdir when cross-compiling.
>> I also hit a couple of snags with the tool-chain:
>> 1) i686-pc-cygwin-pkg-config appears to be implemented as a script which
>> ultimately executes a macro from /etc/rpm/macros.cygwin, which sets
>> PKG_CONFIG_LIBDIR to the sysroot and unsets PKG_CONFIG_PATH and invokes the
>> native pkg-config.
>> Unfortunately, this seems to make it impossible to build package A and then
>> build package B which uses pkg-config to depend on A, without installing A
>> into your sysroot.
>> It looks like I'm not the only one to have tripped across this problem, see
>> e.g. ,.
> As I commented in RH bug 668171, it should be safe to allow
> PKG_CONFIG_PATH in the macro used by $host-pkg-config for cases such as
> this, while continuing to unset it in %_cygwin_env when building RPM
> packages. I've uploaded cygwin-filesystem-4-1 with this change (among
> others); please let me know if that works for you.
>> 2) Some X.Org components don't build with unresolved symbols at link time.
>> The link line generated by the cross-tools contains fewer libraries to that
>> generated by cygwin native tools, I think because the Fedora native pkg-config
>> wasn't configured with --enable-indirect-deps, which doesn't seem to have an
>> equivalent runtime flag.
> That sounds plausible. I didn't encounter this with the libraries, but
> you built the apps as well. I would say that any apps with inadequate
> deps should be fixed in the PKG_CHECK_MODULES call in configure.ac.
I'm not sure that's the correct solution as adding those additional, indirect
deps to PKG_CHECK_MODULES would lead to overlinking on ELF platforms?
Example: bdftopcf only has a PKG_CHECK_MODULES(BDFTOPCF, xfont), so the Fedora
native pkg-config generates BDFTOPCF_LIBS containing only -lXfont, and so
fails to link with unresolved symbols from zlib, required by libXfont.
I built a cross pkg-config with the following configuration, which seems to
./configure --enable-indirect-deps --prefix=/usr
(although it should also have /usr/i686-pc-cygwin/sys-root/usr/share/pkgconfig
and /usr/share/pkgconfig in the default pc-path, I wasn't sure of the syntax
to achieve that :-))