[ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
Tue Sep 14 11:11:00 GMT 2010
On 9/14/2010 16:03, Corinna Vinschen wrote:
> On Sep 14 15:30, JonY wrote:
>> On 9/14/2010 15:29, Charles Wilson wrote:
>>> I don't know about Andy, but I sure do -- and I can reproduce his
>>> problem. I suspect there is a "bug" in how the cross tool locates the
>>> directory, given the mount structure:
>>> /usr/bin = /bin
>>> /usr/lib = /lib
>>> /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32
>>> because if I do THIS:
>>> mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32
>>> /bin/x86_64-w64-mingw32-gcc -o foo foo.c
>>> works, just as if I had invoked
>>> x86_64-w64-mingw32-gcc -o foo foo.c
>>> I say this is a "bug" in quotes, because...well, I'm not sure it fits
>>> the definition. It's *our* fault we use a wacky mount structure on cygwin...
>> So, if /usr/x86_64-w64-mingw32 actually exists, it works?
>> This looks bad, nonetheless.
>> Maybe we can fix cygwin by only redirecting known directories like,
>> /usr/bin and /usr/lib to those in /.
> Cygwin doesn't redirect any /usr dirs to /. There are default mount
> points for /usr/bin -> /bin and /usr/lib -> lib. That's all. The
> problematic path is generated in gcc itself.
What do you suggest the fix should be?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin