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

[Tony Theodore]

On 13 January 2011 12:04, Dmitry Groshev <address@hidden> wrote:
> 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.

I haven't experienced similar problems, but I think symlinking is only
a cover-up for underlying build/configure issues. In my mind, this
directory ($PREFIX/$TARGET/bin) should only really have our test
programs (win32 executables) or cross-platform *config type scripts.
The *config scripts are really just a concession to how much time we
have to make every package cross-build friendly.

I'll have a look at gcc and binutils - my idea is for these to put
nothing in that directory. It shouldn't be in your path, most due to
the potential conflicts with un-prefixed native tools.

Cheers,

Tony