Hello,
On Fri, Apr 13, 2012 at 12:01:59AM -0400, Charles Wilson wrote:
>> CHANGES (from cygutils-1.4.10-1)
>>
>> * fix bug where readshortcut --raw was always "on"
>> * corrected longstanding issue with lpr printer name normalization
>> * readshortcut now handles
Just performed a routine update to cygwin, which resulted in the updated
XWin.exe being quarantined due to a virus threat.
Details:
setup.exe version: 2.769
source: http://cygwin.xl-mirror.nl
xorg-servers-common version:1.12.0-4
Symantec Endpoint Protect
On 2012-04-23 03:28, Watts, Simon (UK) wrote:
Just performed a routine update to cygwin, which resulted in the updated
> XWin.exe being quarantined due to a virus threat.
http://cygwin.com/faq/faq-nochunks.html#faq.setup.virus
Yaakov
Cygwin/X
--
Problem reports: http://cygwin.com/probl
I've noticed that on windows 7, even if we protect a folder by selecting
"delete - Deny" in permissions, cygwin doesn't care and it allows to
continue with rm. I think this is not good. I can think of other ways like
creating a lock file in my scripts but that wont be a clean way. Isn't there
any
[snip]
> lgiambro@lorien ~
> $ cat len.sh
> #!/bin/sh
> echo it works
And man sh states " --norc Do not read and execute the personal
initialization file ~/.bashrc if the
shell is interactive. This option is on by default if the
shell is invoked
as sh."
Which el
Greetings, Watts, Simon (UK)!
> Just performed a routine update to cygwin, which resulted in the updated
> XWin.exe being quarantined due to a virus threat.
> Details:
> setup.exe version: 2.769
> source: http://cygwin.xl-mirror.nl
> xorg-servers-common vers
On Mon, Apr 23, 2012 at 7:02 AM, Michel Bardiaux wrote:
> [snip]
>
>> lgiambro@lorien ~
>> $ cat len.sh
>> #!/bin/sh
>> echo it works
>
> And man sh states " --norc Do not read and execute the personal
> initialization file ~/.bashrc if the
> shell is interactive. This option is
A number of open-source projects (a.o. libav) indicate the use of
-mnocygwin to build, on cygwin, libraries or executables that do not
need the cygwin dll Section 6.10 of the FAQ also says so, but also
states "This section has not yet been updated for the latest net
release.". And indeed, gcc 4.5.3
On Mon, Apr 23, 2012 at 7:35 AM, Michel Bardiaux wrote:
> A number of open-source projects (a.o. libav) indicate the use of
> -mnocygwin to build, on cygwin, libraries or executables that do not
> need the cygwin dll Section 6.10 of the FAQ also says so, but also
> states "This section has not yet
Greetings, pen!
> I've noticed that on windows 7, even if we protect a folder by selecting
> "delete - Deny" in permissions, cygwin doesn't care and it allows to
> continue with rm.
Stop working under administrative account, then.
--
WBR,
Andrey Repin (anrdae...@freemail.ru) 23.04.2012, <15:41>
On Apr 23 02:23, pen wrote:
>
> I've noticed that on windows 7, even if we protect a folder by selecting
> "delete - Deny" in permissions, cygwin doesn't care and it allows to
> continue with rm. I think this is not good. I can think of other ways like
> creating a lock file in my scripts but that
On Apr 23 13:02, Michel Bardiaux wrote:
> [snip]
>
> > lgiambro@lorien ~
> > $ cat len.sh
> > #!/bin/sh
> > echo it works
>
> And man sh states " --norc Do not read and execute the personal
> initialization file ~/.bashrc if the
> shell is interactive. This option is on by defa
[snip]
> You could mount the samba share with "noacl",
> see http://cygwin.com/cygwin-ug-net/using.html#mount-table
> Corinna
Thanks for the suggestion. I have added this to /etc/fstab:
Y: /cygdrive/y smbfs binary,noacl,auto 0 0
Closed all cygwin windows, reopened one (mintty), mount says:
C:/
On Apr 23 13:53, Corinna Vinschen wrote:
> On Apr 23 13:02, Michel Bardiaux wrote:
> > [snip]
> >
> > > lgiambro@lorien ~
> > > $ cat len.sh
> > > #!/bin/sh
> > > echo it works
> >
> > And man sh states " --norc Do not read and execute the personal
> > initialization file ~/.bashrc if the
> >
On Apr 23 14:26, Michel Bardiaux wrote:
> [snip]
>
> > You could mount the samba share with "noacl",
> > see http://cygwin.com/cygwin-ug-net/using.html#mount-table
> > Corinna
>
> Thanks for the suggestion. I have added this to /etc/fstab:
>
> Y: /cygdrive/y smbfs binary,noacl,auto 0 0
That won
[snip]
>> Y: /cygdrive/y smbfs binary,noacl,auto 0 0
> That won't work. Don't try to overload the cygdrive prefix for single
> drives, that's not supported.
Ooops. How do I restore the normal default? It no longer appears in 'mount'.
> Use something like
> Y: /my_y_drive whatever binary,noac
Sorry, forgot to change the recipient.
-Original Message-
> [snip]
>
>> lgiambro@lorien ~
>> $ cat len.sh
>> #!/bin/sh
>> echo it works
>
> And man sh states " --norc Do not read and execute the personal
> initialization file ~/.bashrc if the
> shell is interactive. Thi
[snip]
> Sure, --host=i686-pc-mingw32 or some other appropriate host string during
> configure.
> You'll need to make sure you have the appropriate files for cross compiling.
> The -mno-cygwin has been gone for some months moving into years.
That much I could guess. I am pretty sure I could
On Mon, Apr 23, 2012 at 9:09 AM, Michel Bardiaux wrote:
> [snip]
>
>> Sure, --host=i686-pc-mingw32 or some other appropriate host string during
>> configure.
>> You'll need to make sure you have the appropriate files for cross compiling.
>> The -mno-cygwin has been gone for some months moving into
[snip]
> That is the "general solution". The error message was appropriate and gave a
> clue. Beyond that
> you'll need to communicate a patch to the maintainers of the package that is
> still using -mno-cygwin.
Let me rephrase.
gcc-3 -mno-cygwin -o foo.exe foo.c
under cygwin, works to crea
Hi,
On Mon, Apr 23, 2012 at 3:56 PM, Michel Bardiaux wrote:
> [snip]
>
>> That is the "general solution". The error message was appropriate and gave
>> a clue. Beyond that
>> you'll need to communicate a patch to the maintainers of the package that is
>> still using -mno-cygwin.
>
> Let me re
On Apr 23 15:56, Michel Bardiaux wrote:
> [snip]
>
> > That is the "general solution". The error message was appropriate and gave
> > a clue. Beyond that
> > you'll need to communicate a patch to the maintainers of the package that
> > is still using -mno-cygwin.
>
> Let me rephrase.
>
> gcc
On 23/04/2012 9:56 AM, Michel Bardiaux wrote:
[snip]
That is the "general solution". The error message was appropriate and gave a
clue. Beyond that
you'll need to communicate a patch to the maintainers of the package that is
still using -mno-cygwin.
Let me rephrase.
gcc-3 -mno-cygwin -o f
Perhaps I did not make it clear enough, but these issues still exist as far
as I can tell. I have clean Windows 7 and Windows XP virtual machines, and
a clean install of Cygwin that was updated at the time I sent my original
message. Both issues I described still exist. This is why I wrote the
m
On Apr 23 14:23, James Johnston wrote:
> Perhaps I did not make it clear enough, but these issues still exist as far
> as I can tell. I have clean Windows 7 and Windows XP virtual machines, and
> a clean install of Cygwin that was updated at the time I sent my original
> message. Both issues I de
> As Earnie wrote, now you should use the appropriate mingw32 or mingw64 cross
> compiler,
> both of which are available as part of the Cygwin distro.
> This *is* the general solution.
I *get* that. My problem was, the web is so cluttered with pages mentioning the
no-cygwin thing (including the
On 04/23/2012 08:51 AM, Corinna Vinschen wrote:
>> If having Windows randomly rebase cygreadline7.dll in a child process via
>> ASLR is not a problem, I'd simply be interested to know why. I thought
>> *any* Cygwin DLL relocating itself would cause fork to fail.
>
> Yes, it is a problem in the fi
On Apr 23 08:54, Eric Blake wrote:
> On 04/23/2012 08:51 AM, Corinna Vinschen wrote:
> >> If having Windows randomly rebase cygreadline7.dll in a child process via
> >> ASLR is not a problem, I'd simply be interested to know why. I thought
> >> *any* Cygwin DLL relocating itself would cause fork t
On Mon, Apr 23, 2012 at 04:52:54PM +0200, Michel Bardiaux wrote:
>> As Earnie wrote, now you should use the appropriate mingw32 or mingw64 cross
>> compiler,
>> both of which are available as part of the Cygwin distro.
>> This *is* the general solution.
>
>I *get* that. My problem was, the web is
On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote:
>On Apr 23 14:23, James Johnston wrote:
>> Perhaps I did not make it clear enough, but these issues still exist as far
>> as I can tell. I have clean Windows 7 and Windows XP virtual machines, and
>> a clean install of Cygwin that w
On Apr 23 11:44, Christopher Faylor wrote:
> On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote:
> >On Apr 23 14:23, James Johnston wrote:
> >> Perhaps I did not make it clear enough, but these issues still exist as far
> >> as I can tell. I have clean Windows 7 and Windows XP virtua
On 4/23/2012 11:58 AM, Corinna Vinschen wrote:
On Apr 23 11:44, Christopher Faylor wrote:
On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote:
On Apr 23 14:23, James Johnston wrote:
Perhaps I did not make it clear enough, but these issues still exist as far
as I can tell. I have
> -Original Message-
> Sent: Monday, April 23, 2012 14:51
> Subject: Re: Two probable basing issues causing fork failures: (1)
> cygreadline7.dll has ASLR enabled, (2) default base address conflicts with
> ASLR-relocated/system DLLs
>
> Yes, it is a problem in the first place if DLLs have
On Apr 23 12:20, Ken Brown wrote:
> On 4/23/2012 11:58 AM, Corinna Vinschen wrote:
> >In theory that's the job of peflags, not of rebase. And somebody could
> >want the ASLR flag to be set on certain DLLs. But probably we can safely
> >assume that the Cygwin distro DLLs should not have set the dy
On Apr 23 16:31, James Johnston wrote:
> > As for the address space, we should stick to using the addresses below
> > 0x7000, top-down. The reason is that we also need room for the
> > application heap. On 32 bit systems the heap will be placed at 0x2000
> > and in case it's too small it
On Mon, Apr 23, 2012 at 05:58:23PM +0200, Corinna Vinschen wrote:
>On Apr 23 11:44, Christopher Faylor wrote:
>> On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote:
>> >On Apr 23 14:23, James Johnston wrote:
>> >> Perhaps I did not make it clear enough, but these issues still exist as
On 4/20/2012 7:07 AM, Václav Zeman wrote:
This is a Windows thing.
Another aspect of the Windows Thing which I have not seen discussed yet
is the DLL load path: http://goo.gl/VA8yC
Since Windows looks for DLLs first in the *.exe directory, this is the
most reliable place to put them.
Opti
On 4/20/2012 1:06 PM, Jon TURNEY wrote:
'export EXECIGNORE=*.dll' is a cygwin extension to bash to tell it you don't
want to see those pesky dlls.
Is there a good reason this isn't in the stock /etc/bash.bashrc?
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Mon, Apr 23, 2012 at 01:02:39PM -0600, Warren Young wrote:
> On 4/20/2012 1:06 PM, Jon TURNEY wrote:
> >
> >'export EXECIGNORE=*.dll' is a cygwin extension to bash to tell it you don't
> >want to see those pesky dlls.
>
> Is there a good reason this isn't in the stock /etc/bash.bashrc?
Not tha
On 4/23/2012 3:01 PM, Warren Young wrote:
Options 2-5 in the list at the page linked above don't really apply here.
Cygwin purposely keeps itself nice and segregated from the rest of the
system, so installing DLLs under c:\Windows isn't an option, and CWD is
simply useless for our purpose here.
On 4/23/2012 2:15 PM, Larry Hall (Cygwin) wrote:
On 4/23/2012 3:01 PM, Warren Young wrote:
Options 2-5 in the list at the page linked above don't really apply here.
Cygwin purposely keeps itself nice and segregated from the rest of the
system, so installing DLLs under c:\Windows isn't an option,
On Mon, 23 Apr 2012, Larry Hall (Cygwin) wrote:
>
> On 4/23/2012 3:01 PM, Warren Young wrote:
> > Options 2-5 in the list at the page linked above don't really apply here.
> > Cygwin purposely keeps itself nice and segregated from the rest of the
> > system, so installing DLLs under c:\Windows isn
On 4/23/2012 6:12 PM, Richard Troy wrote:
what on earth would --login have to do with where
the dlls are found?
Without that, you don't run the profile files[*], so you get the Windows
PATH[**] which is clearly insufficient in your situation.
Somewhere in one of these files is a line of c
Hello!
I have a problem with Cygwin NFS server. I boot up my host PC and then
boot up ARM Linux embedded system, which then connects to my host over
NFS. An attempt to mount NFS resource produces "RPC error: connection
refused" until i restart portmap service on my host.
What can be wrong?
44 matches
Mail list logo
