Hi Jason,
per the discussion starting at
http://cygwin.com/ml/cygwin/2012-04/msg00443.html
I would like to apply the following patch to rebase and friends.
Thanks,
Corinna
ChangeLog:
* configure.ac (AC_INIT): Bump version to 4.2.0.
* configure: Regenerate.
*
On 2012-04-23 15:40, Chris Sutcliffe wrote:
Please upload:
Please leave 2.0.16-1 as previous and all other versions can be removed.
Done and done.
Yaakov
On Fri, Apr 20, 2012, at 19:53, Jon TURNEY wrote:
On 20/04/2012 11:43, Ronald Fischer wrote:
My setup so far (which is working well), was to use Xming as X-Server
and putty for logging into our Solaris hosts via ssh. Since I have
Cygwin installed, I thought I could use its ssh equally well,
Hi,
I try a fresh start, not being clear about my complete failure to get any
reply.
I use XWin and GNU emacs (X11 version).
My startup script is:
/usr/bin/startx /usr/bin/emacs -g 90x37+150+0 -- /usr/bin/X :0 -multiwindow
-clipboard
This used to work for a few years, but recently started to
Marc Girod wrote:
I used Gmane and uploaded my cygcheck.out.
Incidentally, I saw there:
Warning: There are multiple cygwin1.dlls on your path
So, I checked:
bin for d in $(echo $PATH | tr : '\n'); do if [ -r $d/cygwin1.dll ]; then
echo $d; fi; done
/usr/bin
/usr/bin
bin echo $PATH | tr
On 23/04/2012 12:55, Michel Bardiaux wrote:
Nothing much to add to the 2 attached files - except that my X worked
fine until the last update. Will try reverting to previous version.
From the log timestamps, this looks like a crash at startup. Is that correct?
Thanks very much for reporting
On 18/04/2012 19:48, Jörg Mensmann wrote:
I've now completed some additional tests, and it seems that the return
value of EnumDisplayMonitors() really depends on the return value of its
callback on my system. Here is the minimal test case:
Thanks for the test case.
Yes, you are quite correct.
Yes, it is a crash at startup.
I could not find XWin.exe.stackdump anywhere on my hard drive. I have
attached the bat script (renamed into .txt) used to start cygwin/X,
maybe I need to modify it.
Would it work to add
CYGWIN='error_start=c:\cygwin\bin\dumper.exe'
in the system environment
are failing?
[1] ftp://cygwin.com/pub/cygwinx/XWin.20120423-git-638383315ef51e46.exe.bz2
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http
On 4/23/2012 5:47 AM, Marc Girod wrote:
snip
Incidentally, I saw there:
Warning: There are multiple cygwin1.dlls on your path
So, I checked:
bin for d in $(echo $PATH | tr : '\n'); do if [ -r $d/cygwin1.dll ]; then
echo $d; fi; done
/usr/bin
/usr/bin
bin echo $PATH | tr : '\n'
problems with
processes started from .startxwinrc? I'm hoping it might help with the problem
I reported in
http://cygwin.com/ml/cygwin-xfree/2012-04/msg00050.html
BTW, I tried the snapshot at
ftp://cygwin.com/pub/cygwinx/XWin.20120423-git-638383315ef51e46.exe.bz2
and the resulting log has a lot
: 20120423-git-638383315ef51e46
XWin was started with the following command line:
XWin :0 -multiwindow -clipboard -nowgl -ac -unixkill -clipboard
-resize -engine 1 -emulate3buttons 100
ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1280 h 800
the
first case and the second in the attached log file.
So, I think xlaunch is ok, but this was a surprising
difference :-) ...
Regards -- Eliot Moss
PS -- I can confirm that adding /usr/bin solves the
problem with the current released XWin.exe as well as
with the 20120423 snapshot you asked me
CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: c...@sourceware.org 2012-04-23 15:18:54
Added files:
cygwin/release : 1.7.14
Log message:
add in preparation for release
Patches:
CVSROOT:/cvs/src
Module name:src
Changes by: yselkow...@sourceware.org 2012-04-23 16:46:46
Modified files:
winsup/doc : ChangeLog faq-programming.xml overview2.sgml
Log message:
* faq-programming.xml (faq.programming.objective-c): Update for gcc4.
CVSROOT:/cvs/src
Module name:src
Changes by: yselkow...@sourceware.org 2012-04-23 17:10:38
Modified files:
winsup/doc : ChangeLog faq-using.xml
Log message:
* faq-using.xml (faq.using.emacs, faq.using.xemacs): Change links
from
On 2012-04-23 10:37, Christopher Faylor wrote:
On Mon, Apr 23, 2012 at 04:52:54PM +0200, Michel Bardiaux wrote:
I *get* that. My problem was, the web is so cluttered with pages mentioning
the no-cygwin thing (including the cygwin FAQ!) that finding a good howto is
nearly impossible.
Is there a
On 2012-04-23 21:35, Yaakov (Cygwin/X) wrote:
On 2012-04-23 10:37, Christopher Faylor wrote:
Could someone provide some appropriate words?
Patch attached.
+paraThe copmilers provided by the literalmingw-gcc/literal,
compilers
Cheers,
Peter
On Mon, Apr 23, 2012 at 02:35:16PM -0500, Yaakov (Cygwin/X) wrote:
On 2012-04-23 10:37, Christopher Faylor wrote:
On Mon, Apr 23, 2012 at 04:52:54PM +0200, Michel Bardiaux wrote:
I *get* that. My problem was, the web is so cluttered with pages mentioning
the no-cygwin thing (including the
cygwin/doc/configure and cygwin/testsuite/configure are now the only
configure scripts in the winsup tree which were generated with
autoconf-2.5x. Any objections to regenerating them with 2.68?
Yaakov
On Mon, Apr 23, 2012 at 05:17:10PM -0500, Yaakov (Cygwin/X) wrote:
cygwin/doc/configure and cygwin/testsuite/configure are now the only
configure scripts in the winsup tree which were generated with
autoconf-2.5x. Any objections to regenerating them with 2.68?
No, go ahead.
cgf
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 embedded
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
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:
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
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 version:
On Mon, Apr 23, 2012 at 7:02 AM, Michel Bardiaux mbardi...@mediaxim.be 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
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 been
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 wont
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 default if the
[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:
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
shell is
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't work.
[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,noacl 0 0
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. This option is on
[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 years.
[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 create a
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 rephrase.
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-3 -mno-cygwin
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
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
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
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 first
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 to fail.
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 so
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 was
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 virtual
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 the
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
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 will be
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
far
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.
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 that I can
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
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't an
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
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? I
65 matches
Mail list logo
