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

[Dmitry Groshev]

Hello!

You wrote:
> I haven't experienced similar problems, but I think symlinking is only
> a cover-up for underlying build/configure issues.

And I think when one cross-compiling setup works OK with unmodified
projects' files, while another setup cannot work without patching them
- from the user's standpoint not the projects, but something else
looks like having "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.

Myself, I could care less - workaround for such a halfbaked setup is
simple, and is now added to my cross-compiling script: creating such a
directory-of-symlinks inside the builddir, and inserting it at the
beginning of PATH when it's needed. But some other users may encounter
such problems too, and be unable to find the solution on their own.
I described the problem and the solution here, only because I thought
someone here would be interested in making things work out of the box
for other people. Sorry if I'm mistaken.

> 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.

By default it isn't needed in PATH, but for some packages, adding it
to the beginning of PATH is by far the easier, and more generic,
solution for the build problems, than identifying and patching the
"underlying build/configure issues" in each affected package.


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