gt;> I have hit an issue with thread-local storage variables on
>>>> Cygwin/AMD64, I do not see it with Cygwin/i686.
>>>
>>> This is also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697.
>>
Sorry, I'm not too familiar with the C++ internals, but I see you filed
a GCC bug report, thanks.
signature.asc
Description: OpenPGP digital signature
On 9 February 2016 at 15:23, Václav Haisman wrote:
> On 19 May 2015 at 10:52, Václav Haisman wrote:
>> On 19 January 2015 at 15:42, Václav Haisman wrote:
>>>
>>> Hi.
>>>
>>> I have hit an issue with thread-local storage variables on
>>> Cyg
On 19 May 2015 at 10:52, Václav Haisman wrote:
> On 19 January 2015 at 15:42, Václav Haisman wrote:
>>
>> Hi.
>>
>> I have hit an issue with thread-local storage variables on
>> Cygwin/AMD64, I do not see it with Cygwin/i686.
>>
>> I am having linkin
Forgot to say that I was running Cygwin 32bit, not 64bit. 64bit doesn't seem
to have the same problem.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.c
Hi,
First time mailing this list, so hopefully I followed the guidelines correctly.
I was able to simplify the problem I am having into a simple test.
I create a thread and in that thread use Popen to execute 'echo hello' but the
process ends up getting terminated with -11 most of the time and
On 19 January 2015 at 15:42, Václav Haisman wrote:
>
> Hi.
>
> I have hit an issue with thread-local storage variables on
> Cygwin/AMD64, I do not see it with Cygwin/i686.
>
> I am having linking issues when using `thread_local` keyword in Cygwin
> with its GCC 4.8.3 and GC
Hi.
I have hit an issue with thread-local storage variables on
Cygwin/AMD64, I do not see it with Cygwin/i686.
I am having linking issues when using `thread_local` keyword in Cygwin
with its GCC 4.8.3 and GCC 4.9.2. This is derived from log4cplus. The
test case is split into three files:
File
Hello,
Thanks for helping, I un-installed cygwin and installed it again and
the problem persists. Now the /home directory was not created
and the PATH variable is not initialised.
All the cygwin installation is as downloaded, there are no startup scripts
other than those provided so there
On 12 November 2006 19:16, Yuval Krymolowski wrote:
> Hello,
>
> I am using the current 1.5.21 kernel with the configuration shown
> below (from cygcheck output). I run Windows XP x64 pro.
> Things worked ok on the 1.5.19 kernel but after upgrading I see that:
> - the cygwin window sta
Hello,
I am using the current 1.5.21 kernel with the configuration shown
below (from cygcheck output). I run Windows XP x64 pro.
Cygwin Configuration Diagnostics
Windows 2003 Server Ver 5.2 Build 3790 Service Pack 1
Running under WOW64 on AMD64
Things worked ok on the 1.5.19 kernel
At 02:19 AM 10/7/2005, you wrote:
>On Thu, 2005-10-06 at 22:02 -0700, Brian Dessent wrote:
>> I seriously doubt that vmware has anything to do with it. You need to
>> figure out why ld cannot be executed. Try -v.
>
>I have checked all the paths in the output and they exist. All
>executables that
At 02:19 AM 10/7/2005, you wrote:
>On Thu, 2005-10-06 at 22:02 -0700, Brian Dessent wrote:
>> I seriously doubt that vmware has anything to do with it. You need to
>> figure out why ld cannot be executed. Try -v.
>
>I have checked all the paths in the output and they exist. All
>executables that
On Fri, 7 Oct 2005, Joost Kraaijeveld wrote:
On Thu, 2005-10-06 at 12:16 -0400, Larry Hall wrote:
Sounds like a reinstallation of "binutils", at least, is in order. While
you're at it, reinstall gcc bits too.
A full reinstallation of Cygwin did not help.
I wonder if there is actually anyone
Hi James,
On Fri, 2005-10-07 at 04:45 -0700, James R. Phillips wrote:
> Joost Kraaijeveld wrote:
>
> [..]
> For the record, I do. Currently I run Debian 3.1 (sarge), with a linux
> 2.6.13.1 kernel. On top of this is vmware 5, installed using the
> vmware-any-any script. And on vmware is a win
Joost Kraaijeveld wrote:
[..]
> I wonder if there is actually anyone who is running W2K/Cygwin in VMWare
> on Linux?
For the record, I do. Currently I run Debian 3.1 (sarge), with a linux
2.6.13.1 kernel. On top of this is vmware 5, installed using the
vmware-any-any script. And on vmware is
On Thu, 2005-10-06 at 22:02 -0700, Brian Dessent wrote:
> I seriously doubt that vmware has anything to do with it. You need to
> figure out why ld cannot be executed. Try -v.
I have checked all the paths in the output and they exist. All
executables that are called seem to respond to running th
Joost Kraaijeveld wrote:
> > Sounds like a reinstallation of "binutils", at least, is in order. While
> > you're at it, reinstall gcc bits too.
> A full reinstallation of Cygwin did not help.
>
> I wonder if there is actually anyone who is running W2K/Cygwin in VMWare
> on Linux?
I seriously do
On Thu, 2005-10-06 at 12:16 -0400, Larry Hall wrote:
> Sounds like a reinstallation of "binutils", at least, is in order. While
> you're at it, reinstall gcc bits too.
A full reinstallation of Cygwin did not help.
I wonder if there is actually anyone who is running W2K/Cygwin in VMWare
on Linux?
At 11:03 AM 10/6/2005, you wrote:
>On Thu, 2005-10-06 at 10:15 -0400, Christopher Faylor wrote:
>> Look at the error in config.log.
>
>I have looked and is says:
>
>This file contains any messages produced by compilers while
>running configure, to aid debugging if configure makes a mistake.
>
>con
On Thu, 2005-10-06 at 10:15 -0400, Christopher Faylor wrote:
> Look at the error in config.log.
I have looked and is says:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
configure:1183: checking host system type
conf
On Thu, Oct 06, 2005 at 08:28:26AM +0200, Joost Kraaijeveld wrote:
>Hi,
>
>I am using a Debian 2.6.8-11-amd64-k8-smp hosted VMWare 5.0 with a W2K
>and Cygwin (latest version, all packages installed) as a guest OS.
>
>I want to compile MICO in the W2K virtual machine, using
Hi,
I am using a Debian 2.6.8-11-amd64-k8-smp hosted VMWare 5.0 with a W2K
and Cygwin (latest version, all packages installed) as a guest OS.
I want to compile MICO in the W2K virtual machine, using Cygwin. If I
run configure it stops after checking if the C compiler works with the
following
lavmart wrote:
> Will Cygwin run under Win64 beta?
Yes but you will probably have to use a recent snapshot.
> Will gcc currently in Cygwin produce AMD64 object
> code and executables
No, gcc does not support x64 under windows. Nor does binutils, AFAIK.
If you want to generate 64 bit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
lavmart wrote:
> Will Cygwin run under Win64 beta?
It already does, using WOW64 of course.
> Will gcc currently
> in Cygwin produce AMD64 object code and executables
> (command-line only, I want to run some benchmarks...?)
This, I&#x
Will Cygwin run under Win64 beta? Will gcc currently
in Cygwin produce AMD64 object code and executables
(command-line only, I want to run some benchmarks...?)
TIA, Oliver J.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com
Yea, that would help a great deal.
-Original Message-
From: Nathan Laredo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 3:08 PM
To: [EMAIL PROTECTED]; Benson Margulies; [EMAIL PROTECTED]
Subject: Re: Windows Server 2003 on AMD64 -- Making it work
Hi,
If you simply want to get
Hi,
If you simply want to get cygwin working on amd64 windows, create
a cygwin.cmd in addition to your current C:\cygwin\cygwin.bat and
make it do the following:
@echo off
C:\WINDOWS\SysWOW64\cmd.exe /c C:\cygwin\cygwin.bat
Then, point your cygwin icon/shortcuts at cygwin.cmd and you'll b
Benson Margulies wrote:
Would anyone be willing to elaborate on how the existing code is going
about accomplishing the task at hand? If not, at least knowing that this
is the goal of the exercise should make it easier to get a clue.
I believe that there is some documentation in a file in the CVS f
At 10:12 AM 1/18/2004, Benson Margulies wrote:
TWIMC,
Some time ago, I reported that fork() didn't work when running the
current cygwin distro on the AMD64 on Windows. At the time, I debugged
far enough to get an approximate picture of what Cygwin was doing with
VirtualXXX calls to impl
I've belatedly located Corinna Vinschen's email message about the
requirement for the stack address in fork.
Would anyone be willing to elaborate on how the existing code is going
about accomplishing the task at hand? If not, at least knowing that this
is the goal of the exercise should make it e
I see that I missed a message. Corinna's message indicates that the
intention is that the stack location of the child be identical to the
parent, for pretty self-evident fork-semantics-reasons. I'll take
another dip into the code and see if I can figure something out.
--
Unsubscribe info: ht
At 01:12 PM 1/18/2004, Benson Margulies you wrote:
>TWIMC,
>
>Some time ago, I reported that fork() didn't work when running the
>current cygwin distro on the AMD64 on Windows. At the time, I debugged
>far enough to get an approximate picture of what Cygwin was doing with
TWIMC,
Some time ago, I reported that fork() didn't work when running the
current cygwin distro on the AMD64 on Windows. At the time, I debugged
far enough to get an approximate picture of what Cygwin was doing with
VirtualXXX calls to implement fork, and I posted some questions in the
hop
On Dec 9 12:55, Benson Margulies wrote:
> I assume that there's a very strong reason why this code can't just
> allocate a stack any-old-place (calling VirtualAlloc with first arg 0)
> and use it. What I don't understand is the nature of the constraints. If
> the parent needs to know, why not have
This looks like a logic error in fork.cc/dcrt0.cc to me, but I'm
probably not understanding something.
alloc_stack_hard_way assumes that the memory at ci->stacktop is
available. ci->stacktop is set to be the region of memory that contains
a stack variable in the parent process at the time that sta
The error message rather unambiguously indicates that VirtualAlloc is
returning 0 with GetLastError() == 0. The call in question calls
VirtualAlloc with parameters derived from a call to VirtualQuery against
some stack storage. It seems that this version of Windows is not
altogether pleased to see
cc: (bcc: Jurgen Defurne/BRG/CE/PHILIPS)
Subject:Re: Memory Management on AMD64 in 32-bit mode
Classification:
On Mon, Dec 08, 2003 at 07:30:17PM -0500, Benson Margulies wrote:
>I happen to have access to a an AMD64 system running Windows. All the
>cygwin sh
On Mon, Dec 08, 2003 at 07:30:17PM -0500, Benson Margulies wrote:
>I happen to have access to a an AMD64 system running Windows. All the
>cygwin shells fail to fork with the following. I'd be willing to try
>coding and running a patch if the experts would care to offer an idea o
I happen to have access to a an AMD64 system running Windows. All the
cygwin shells fail to fork with the following. I'd be willing to try
coding and running a patch if the experts would care to offer an idea of
what to try.
$P$Gls
C:\cygwin\bin\zsh.exe: *** fork: can't reserve memory
39 matches
Mail list logo
