2009/11/4 Linda Walsh:
>> C: and C:\ aren't the same thing in DOS/cmd.exe. C: means the current
>> directory of the C drive, whereas C:\ means the root directory of the
>> C drive. Within each cmd.exe session, each drive has its own current
>> directory.
>
> ---
> Right. That's a cmd.exe-is
On 11/03/2009 10:54 PM, David T-G wrote:
Hi, all --
I am having a terrible time trying to install cygwin on our new Acer
AspireOne netbook (Win XP SP3 @ 1G). I have tried downloading to a local
directory (my usual preference), installing from the 'net, and -- most
interestingly, to me -- instal
Hi, all --
I am having a terrible time trying to install cygwin on our new Acer
AspireOne netbook (Win XP SP3 @ 1G). I have tried downloading to a local
directory (my usual preference), installing from the 'net, and -- most
interestingly, to me -- installing from a copied download tree from
anoth
On 03/11/2009 19:13, Jim Reisert AD1C wrote:
Unfortunately, once I installed this version, I couldn't get the
Cygwin/X server to start (using 1.7.1). I had to roll back to
1.7.0-62
This is quite probably the same problem as [1], a consequence of the change in
default locale to C.UTF-8 (and so
Andy Koppe wrote:
C: and C:\ aren't the same thing in DOS/cmd.exe. C: means the current
directory of the C drive, whereas C:\ means the root directory of the
C drive. Within each cmd.exe session, each drive has its own current
directory.
---
Right. That's a cmd.exe-ism -- As Christofph
RCS co -l fails if the ,v file is not owned by the user.
I get a permission denied error.
In my case, the RCS directory is on samba.
It seems to fix it if in conf.h I change
#define bad_b_rename 1
The flag makes it delete the target(*,v) before renaming the work file
(,*,v -> *,v)
Thanks
GNOME Evolution contains several interdependent libraries, so on
Cygwin/MinGW the build creates artificial import libraries with dlltool
from .def files. While trying to build 2.28 I came across a possible
incompatibility between the implib generated by dlltool and auto-import
linkage:
$ gcc
During the brief period I ran Windows Vista, it was recommended to run
rebaseall.
Now that I'm running Windows 7 and Cygwin 1.7, seemingly without
problems, is there any reason/need/advantage to running it?
Thanks - Jim
--
Jim Reisert AD1C, , http://www.ad1c.us
--
Problem reports: http:/
On 11/03/2009 08:33 PM, Yeng Chen wrote:
RCS co -l fails if the ,v file is not owned by the user.
I get a permission denied error.
In my case, the RCS directory is on samba.
It seems to fix it if in conf.h I change
#define bad_b_rename 1
The flag makes it delete the target(*,v) before renaming
Corinna Vinschen wrote:
For 1.7 our choice is to keep dlopen() checking for the .dll suffix to
be more Windows-like, or to be more Linux-like by dropping the check for
the .dll suffix so that dlopen() fails if the filename isn't specified
fully.
---
Does anybody know such a tool? If so, is the
Hi All,
I prepared a (very preliminary) source package for
Automatically Tuned Linear Algebra Software (ATLAS).
It is a fast alternative to the reference BLAS/LAPACK build.
ATLAS 3.9.16 packages, source and Core232SSE3 lib,
for cygwin-1.7 are at
http://matzeri.altervista.org/cygwin-1.7/atlas/
Corinna Vinschen wrote:
> On Nov 2 20:05, Eric Blake wrote:
>> According to Corinna Vinschen on 11/2/2009 9:48 AM:
>>> While we tend to change the implementation to be more Linux-like,
>>> there could be some tools out there which erroneously depend on the
>>> Windows-like behaviour of Cygwin's dl
I'm up and running again, thanks!
On Tue, Nov 3, 2009 at 12:54 PM, Christopher Faylor
wrote:
> On Tue, Nov 03, 2009 at 07:50:41PM +, Jon TURNEY wrote:
>>On 03/11/2009 19:13, Jim Reisert AD1C wrote:
>>>Unfortunately, once I installed this version, I couldn't get the
>>>Cygwin/X server to star
On Tue, Nov 03, 2009 at 07:50:41PM +, Jon TURNEY wrote:
>On 03/11/2009 19:13, Jim Reisert AD1C wrote:
>>Unfortunately, once I installed this version, I couldn't get the
>>Cygwin/X server to start (using 1.7.1). I had to roll back to 1.7.0-62
>
>This is quite probably the same problem as [1], a
Unfortunately, once I installed this version, I couldn't get the
Cygwin/X server to start (using 1.7.1). I had to roll back to
1.7.0-62
I can provide debug info if someone tells me what is needed.
- Jim
On Tue, Nov 3, 2009 at 7:54 AM, Corinna Vinschen
wrote:
> Hi folks,
>
>
> I just uploaded a
On 11/03/2009 06:41 PM, Jim Reisert AD1C wrote:
During the brief period I ran Windows Vista, it was recommended to run
rebaseall.
Now that I'm running Windows 7 and Cygwin 1.7, seemingly without
problems, is there any reason/need/advantage to running it?
Not generally, no. You should only run
On Mon, Nov 2, 2009 at 22:39, Chris Cormie wrote:
> Christopher Faylor wrote:
>>
>> On Mon, Nov 02, 2009 at 02:25:03PM +1100, Chris Cormie wrote:
There are barriers to implementing rpm in Cygwin, the most frequently
mentioned being the fact that a cygwin process can't easily replace
On Nov 3 16:54, Corinna Vinschen wrote:
> On Nov 3 16:44, Corinna Vinschen wrote:
> > $ ./DefDosDevice X: '\??\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
> > $ cd /mnt/x
>
> Oops... replace /mnt/x with /cygdrive/x. I have changed my cygdrive
> prefix to /mnt locally. Sorry for any confusi
On Nov 3 16:44, Corinna Vinschen wrote:
> $ ./DefDosDevice X: '\??\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
> $ cd /mnt/x
Oops... replace /mnt/x with /cygdrive/x. I have changed my cygdrive
prefix to /mnt locally. Sorry for any confusion.
Corinna
--
Corinna Vinschen
On Nov 3 01:49, Jeffrey J. Kosowsky wrote:
> I know that there have been multiple threads about the pros/cons of
> being able to access XP/Vista style \\?\GLOBALROOT paths.
>
> However, not being able to access them limits one's abilities to use
> things like shadow copies since they create shado
Hi folks,
I just uploaded a new Cygwin 1.7 test release, 1.7.0-63.
Changes in relation to 1.7.0-62:
- Add a bigger patch which allows by default to run multiple Cygwin
installations in parallel without interferring and without interaction
between processes
Bonjour Monsieur.
Je tiens à appliquer par ce moyen pour votre coopération pour assurer la
possibilité d'investir et faire des affaires avec vous dans votre pays, j'ai
reçu votre contact dans la chambre de commerce et d'industrie du Ghana. Je prie
et choisi votre nom entre d'autres noms en
Marcel Rutten wrote:
> building the toolchain is done in 4 steps:
>
> 1 build binutils,
> 2 build gcc stage 1, a barebones gcc, for building glibc
> 3 build glibc
> 4 build gcc stage 2, with c and c++ support.
>
> Things go wrong in step 3, the linker starts complaining about
> undefined referen
I just installed cygwin
I get the following errors when I run the batch file
bash: /usr/bin/tr: No such file or directory
bash: /usr/bin/sed: No such file or directory
Your group is currently "mkpasswd". This indicates that
the /etc/passwd (and possibly /etc/group) files should be rebuilt.
Se
On Tue, Nov 03, 2009 at 11:58:53AM +0100, Laurent Najman wrote:
>The parenthood seems to be lost when the parent is execed. Here is a
>sample code
Yes, it's a longstanding limitation of Cygwin that an execed process
does not remember the child processes associated with the previous pid.
Sorry.
Dear all,
I am trying to set up a toolchain for an ARM platform
(arm-linux-gnueabi, my TV) using cygwin, without much success so far.
The tools I'm using are:
binutils 20080624-2
gcc4 4.3.2-2
The toolchain code consists of:
gcc 4.2.0, glibc 2.5.90, binutils 2.17.50,
Hi,
The parenthood seems to be lost when the parent is execed.
Here is a sample code
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
int status;
if (argc > 1) {
printf ("Execed Parent: Cygwin: %d Windows: %lu \n",
getpid (), GetCurrentProcessId
Andy Koppe schrieb:
2009/11/1 Hans Horn:
I think I figured it out myself; seemingly I need to have /etc/alternatives
in my path before /usr/bin.
No, that shouldn't be necessary. Thes issue is with this:
lrwxrwxrwx 1 Hans None9 Jul 14 16:30 /usr/bin/gcc.exe -> gcc-3.exe
That
On Nov 2 20:05, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Corinna Vinschen on 11/2/2009 9:48 AM:
> > Weird question, right?
> >
> > Here's the problem.
> >
> > Assume you have a file "foo.so" on Linux. If you call
> >
> > dlopen ("./foo.so", RTLD_L
On 03/11/2009 02:21, Thomas Wolff wrote:
In terms of compatibility and least surprising behavior, what about
accepting dlopen ("bla.so") and looking for "bla.dll"?
No, Ruby and Apache2 (among others) use .so on all platforms, including
native Win32.
Yaakov
--
Problem reports: http://
Corinna Vinschen schrieb:
On Nov 2 14:17, Larry Hall (Cygwin) wrote:
On 11/02/2009 11:48 AM, Corinna Vinschen wrote:
For 1.7 our choice is to keep dlopen() checking for the .dll suffix to
be more Windows-like, or to be more Linux-like by dropping the check for
the .dll suffix so that d
31 matches
Mail list logo
