mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mingw-cross-env-list] /usr/bin vs /usr/$TARGET/bin


From: Dmitry Groshev
Subject: [Mingw-cross-env-list] /usr/bin vs /usr/$TARGET/bin
Date: Thu, 13 Jan 2011 04:08:04 +0300

Hello!

When trying to use mingw-cross-env built compiler in place of my own
cross-MinGW build, I noticed a deficiency which causes problems when
building some packages.
The most notable one is 'zlib' failing to build the way it's designed
to (using 'win32/Makefile.gcc'), where mingw-cross-env has to resort
to patching the configure script and then doing the build "the *nix
way".
Another, in my case, is an old GTK+ version (2.6.7) failing to compile.

The problem with GTK+ is caused by its trying to run 'windres' by its
short name, with no such thing present in PATH. After first
encountering this problem, I fixed problems of this sort once and for
all in my cross-MinGW SlackBuild script, simply by populating
$PREFIX/$TARGET/bin with symlinks to corresponding binares from
$PREFIX/bin so that '$PREFIX/$TARGET/bin/windres' is a symlink to
'$PREFIX/bin/$TARGET-windres', etc.:

cd $PKG$PREFIX/$TARGET/bin || exit 1
for BINARY in $PKG$PREFIX/bin/$TARGET-*
do
        ln -sf ../../bin/${BINARY##*/} ${BINARY##*/$TARGET-}
done

And, as I learned later, as a side-effect this also solves the zlib
build problem - while a copied 'gcc' binary cannot find 'cc1' and
fails, a symlinked one _can_, and works perfectly.

If mingw-cross-env would do such symlinking after building 'binutils'
and 'gcc' packages, not only would it prevent all problems of the
above sort, but also save about 30 Mb of wasted diskspace :-) by
replacing redundant and harmful identical copies of binaries with
symlinks.


-- 
-= With best regards, Dmitry Groshev =-



reply via email to

[Prev in Thread] Current Thread [Next in Thread]