[ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1

Charles Wilson cygwin@cwilson.fastmail.fm
Tue Sep 14 15:47:00 GMT 2010

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


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

More information about the Cygwin mailing list