On 9/14/2010 7:18 AM, Corinna Vinschen wrote:
> On Sep 14 18:15, JonY wrote:
>> What do you suggest the fix should be?
>
> I really don't know, but it's certainly not a fix in Cygwin. The fact
> that /usr/bin is a mount point to /bin is nothing which wouldn't be
> allowed under Linux as well. There's a default mechanism in gcc which
> evaluates the paths to the tools, headers and libdb dirs by massaging
> the $prefix and $exec_prefix values in some way. I assume you can
> work around this issue by using slightly different values, but I'm
> not fluent enough with the path evaluationin gcc to suggest the
> correct solution, for a given value of "correct".
Actually, I don't think this "problem" is all that critical. I think
that in order to trigger it, you have to do some fairly unusual things:
set your $PATH so that /bin precedes /usr/bin (which, in most cases, has
zero effect...so why would you do that?), or deliberately invoke the
compiler by one of its full PATH specifications (that is not the "usual"
/usr/bin/ one).
I think I'd just put a note in the README, the "Port Notes" section,
like this:
=====
If you invoke the compiler or other tools using a path like this:
/bin/x86_64-w64-mingw32-gcc ...
rather than these
/usr/bin/x86_64-w64-mingw32-gcc ...
x86_64-w64-mingw32-gcc ...
you may see errors. If you must invoke the compiler using the /bin
formulation, you can avoid these errors by creating a temporary mount
point (or add the following to your ~/.bashrc):
mount -o bind /usr/x86_64-w32-mingw32 /x86_64-w32-mingw32
=====
This can certainly wait until the next normal package update. At least,
that's my opinion...
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
