[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dependencies: non-standard path to system headers
From: |
ineiev |
Subject: |
Re: Dependencies: non-standard path to system headers |
Date: |
Wed, 2 Jul 2008 13:03:38 +0400 |
On 7/1/08, Brian Dessent <address@hidden> wrote:
>The essential point is that using native Win32 tools with Cygwin causes
>problems. This is because Cygwin is designed to closely emulate a POSIX
>environment, and the tools aren't equipped to deal with Win32 paths with
>drive letters. This is not specific to 'make', it is a general fact of
>life with Cygwin.
Some strictly positive amount of interoperability exists.
When I gcc c:/cygwin/home/15-6-1/tmp/m/sample.c, it
produced a.exe (gcc 'c:\cygwin\home\15-6-1\tmp\m\sample.c', too).
sample.c contained
#include<stdio.h>
int
main(void)
{FILE*f=fopen("c:\\sample.txt","w");
if(f){fprintf(f,"no camel\n");fclose (f);}
else printf("fail\n");return 0;
}
, and when I ./a.exe, the named c:\sample.txt appeared
(I tried also "c:/sample.txt" with the same result).
>Since the codepaths of Cygwin ports of these tools
>are the same as the *nix codepaths, there is no guarantee that drive
>letters will work.
There is no guarantee that anything will work;^)
Actually the only thing that does not (in this case) is make.
>Now, in the specific case of GNU make there is a patch in upstream make
>to enable the handling of Win32 style paths even when built in unix
>mode. So you should just use a more recent 'make' from CVS and it
>should just work.
Interesting. I'll try. This is possibly the most simple way to fix this.
>But again I must emphasize that the core philosophy of Cygwin is to be
>able to build *nix tools for Windows without source modification, or
>with very minimal modification. You shouldn't be surprised then that
>these tools don't cope with Win32 paths because they wouldn't cope with
>drive letters when built under linux either, and it's the same
>codepath. In other words, Cygwin exists specfically so that things like
>dealing with Win32 paths need NOT be added to the code -- the tools
>don't need to be "ported to Win32" they just need to be recompiled.
In my real life I need an access to RS-232 UARTs. I use W5s API,
because termios won't do it on Cygwin.
>This is far from the only example where you will encounter this clash if
>you continue to mix native apps with Cygwin tools.
The life is hard.
Best regards,
Ineiev