headers
Larry Hall (Cygwin | 1 Feb 2010 02:13
Favicon

Re: Windows 7

On 01/29/2010 08:45 PM, Brian Wilson wrote:
> I had a similar problem upgrading on XP.  I think my issue was related to a
> heap space allocation issue which prevents the shell from running during the
> installation.  I found that failed installations left shell processes running,
> but not doing anything useful.
>
> Check the documentation as I believe there is a fix for the heap space issue.
> In my case, I killed these useless shells and that allowed the Cygwin bash
> shell to start up with out heap space errors.  I cleaned out the
> /etc/postinstall directory by removing any shell scripts (rm *.sh) and
> rerunning the setup.  Cygwin installed okay for me after that.

There's no reason to remove postinstall scripts and, in fact, very good reason
to not do so - your installation could be incomplete.  If things are working for
you and you have no complaints, there's no reason to revisit this issue but in
case others reading this thread thought this would be a good thing to try, I
wanted something on record that would recommend against it.

--

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Javier Sedano | 1 Feb 2010 07:20
Picon

Xwin report and partial solution

Hi, friends,

  yesterday I tried to run the cygwin X server, but it did not run.

  It cried about being unable to bind to the ipv6 address or so.

  Browsing the mail list I've seen several requests for help, but I
have not found the solution that I applied: install the ipv6 stack.
Once I installed the ipv6 stack on windows xp (the command to be run
is just "ipv6 install"; I don't know about other versions of windows),
Xwin runs without problems.

  I haven't seen anyone pointing to that solution.

  However, I'd like if the maintainer could remove such dependency...

Regards,

--

-- 
--
Javier Sedano
javier.sedano <at> gmail.com
Permalink | Reply | 3 comments |
headers
Carsten.Porzler | 1 Feb 2010 10:41
Picon

Re: Cygwin v.1.7.1/OpenSSH v.5.3: Userswitching by using LSA Authentication does not work: Problem solved!

Hello, Corinna,

excuse me (s. above!)!

cygwin-owner <at> cygwin.com schrieb am 29.01.2010 14:59:24:

> [Bild entfernt] 
> 
> Re: Cygwin v.1.7.1/OpenSSH v.5.3: Userswitching by using LSA 
> Authentication does not work...
> 
> Corinna Vinschen 
> 
> an:
> 
> cygwin
> 
> 29.01.2010 15:00
> 
> Gesendet von:
> 
> cygwin-owner <at> cygwin.com
> 
> Bitte Antwort an cygwin
> 
> On Jan 29 13:45, Carsten.Porzler <at> spb.de wrote:
> > > As a temporary workaround for 64 bit users, I uploaded a 
cyglsa64.dll
> > > for Cygwin 1.7.1:
> > >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Corinna Vinschen | 1 Feb 2010 11:38
Favicon

Re: Cygwin v.1.7.1/OpenSSH v.5.3: Userswitching by using LSA Authentication does not work: Problem solved!

On Feb  1 10:41, Carsten.Porzler <at> spb.de wrote:
> cygwin-owner <at> cygwin.com schrieb am 29.01.2010 14:59:24:
> > > But, it is necessary, that the logon user's primary group is the 
> > > Adminstrators group (544) within the passwd file. Ohterwise, the logon 
> 
> > > failed.
> > 
> > u!?  Not on my machine.  My acount has a normal domain account as
> > primary group.
> 
> It was a false alarm! There was something wrong with my installation. 
> After installation on another machine, everything is OK!
> 
> Nevertheless, could you care for the problem with the uncomplete output 
> during executing commands directly by using SSH? Or do I have to create a 
> bug report for this (as Larry Hall said in his email of January, 21st)?
> 
> You solved the problem in Cygwin v.1.7.0 about one and a half year ago.

I don't know what you're referring to.  Can you please point to the
thread in the cygwin ML archive(*)?  And, if I fixed it, how come that
you're still seeing it?

And if it's actually a generic problem, how come that neither Larry nor
I can reproduce it?  I tried with an ssh client from Cygwin against a
non-Cygwin sshd server, against a Windows sshd server using cyglsa, and
a Windows sshd server using the "passwordless w/ password"(**) method.
In all three cases I can't see this effect.  From my perspective it
looks like a local problem on your side.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew West | 1 Feb 2010 12:46
Picon

Re: dlclose not calling destructors of static variables.

On 29/01/2010 18:45, Christopher Faylor wrote:
> On Fri, Jan 29, 2010 at 02:30:48PM +0000, Andrew West wrote:
>    
>> On 29/01/2010 13:08, Dave Korn wrote:
>>      
>>> On 28/01/2010 11:21, Andrew West wrote:
>>>        
>>>> I seem to be having a problem with dlclose not calling the destructors
>>>> of statically declared variables.  I've attached a simple test case
>>>> which I compile as follows;
>>>>
>>>>          
>>> Thanks for the report and the STC; this should work.  I'll take a look
>>> at it over the weekend or the start of next week if nobody else gets
>>> there first.
>>>
>>>        
>> Thanks for looking into this, it looks a little more complex than I
>> first thought.
>>
>> I've tried calling __call_exitprocs during dlclose ( after run_dtors
>> for the unloading library ) just to see if I was thinking along the
>> right lines.  Unfortunately this didn't work as when the destructor is
>> registered with atexit it isn't associated with the loaded library but
>> with the main executable.
>>
>> Which brings me on to the bigger problem, the static variables are
>> registered with atexit rather than with __cxa_atexit which seems to be
>> a violation of the C++ standard (1).
>>
(Continue reading)

Permalink | Reply | 22 comments |
headers
DEWI - N. Zacharias | 1 Feb 2010 12:51
Picon
Favicon

Bash completion and symlinks problem


Hi all,

another problem after updating cgwin . The bash completion don't work for symlinks .

assume having a /cygdrive/c/bin directory which contains symlinks to scripts in a central directory on
our file sever say /cygdrive/x /centraltools/

eg.

 /cygdrive/c/bin/dosomething.pl -> /cygdrive/x /centraltools/dosomething.pl

The strange thing is, old links as well as new ones executed fine. Only they don't appear in the completion.

Can someone tell me why ??

Kindly regards
Norbert

--------------------------------------------------------------------------
Dipl. Phys.
Norbert Zacharias
Wind Measurements & Power Curve Measurements
DEWI GmbH
Ebertstrasse 96
26382 Wilhelmshaven
Germany

Tel.:   +49 4421 4808 876
(Continue reading)

Permalink | Reply | 11 comments |
headers
J J | 1 Feb 2010 14:49
Picon
Favicon

./configure on cygwin in window platform

Please help me out. I spent for three days but I still could install gcc in window on cygwin.

Problem is I could not install gcc file, (mingw-w64-trunk-snapshot-20091222.tar.bz2), on cygwin in
window platform.

I would like to unpack and intall gcc (mingw-w64-trunk-snapshot-20091222.tar.bz2) on cygwin on window
platform. I follow instruction posted on http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0.
The problem I have found out is I could not process the configure step as below. The result shows "No such
file or directory"

Steps:
$ mkdir build
$ cd build
$ ../gcc-*/configure --enable-languages=c,c++
$ make
$ make install

May it be because of (1) setting srcdir or objdir non-correctly or (2) else ?

What I have done are:
1. Download gcc file and load it into /usr/build. Build subfolder is created by me. --> ( equal to $ mkdir
build  and  $ cd build)
2. Unpack gcc tar.bz2 file (mingw-w64-trunk-snapshot-20091222.tar.bz2) on that location. --> It
generates trunk subfolder that contains some subfolder too.
3. $mkdir build  and $cd build --> current location is urs/build
4. $ ../trunk/configure --enable-languages=c,c++  --> It does not work. Error = "No such file or directory"

Comparing to what you recommend on http://gcc.gnu.org/install/configure.html ,

To configure GCC:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Vincent Richomme | 1 Feb 2010 14:58
Favicon

Re: ./configure on cygwin in window platform

> Please help me out. I spent for three days but I still could install gcc
> in window on cygwin.
> 
> Problem is I could not install gcc file,
> (mingw-w64-trunk-snapshot-20091222.tar.bz2), on cygwin in window
platform.
> 
> I would like to unpack and intall gcc
> (mingw-w64-trunk-snapshot-20091222.tar.bz2) on cygwin on window
platform. I
> follow instruction posted on
> http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0. The problem I
have
> found out is I could not process the configure step as below. The result
> shows "No such file or directory"
>  
> Steps:
> $ mkdir build
> $ cd build
> $ ../gcc-*/configure --enable-languages=c,c++
> $ make
> $ make install
>  
> May it be because of (1) setting srcdir or objdir non-correctly or (2)
> else ?
>  
> What I have done are:
> 1. Download gcc file and load it into /usr/build. Build subfolder is
> created by me. --> ( equal to $ mkdir build  and  $ cd build)
> 2. Unpack gcc tar.bz2 file (mingw-w64-trunk-snapshot-20091222.tar.bz2)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Schulman | 1 Feb 2010 15:18
Picon

Re: Putting a cygwin installation under bzr VCS ?

> So, what do you think about putting one standard installation under
> bzr (Windows)
> control and then pulling in changes from the different PC's when they are ready
> for it ?

That seems like a workable approach.  A disadvantage is that by putting all
of those binaries into bzr, you'd get a large .bzr directory, with all of
the previous versions of every binary.  However, that would only be true on
the master host.  On the slave hosts you could use lightweight checkouts
and so not take up all of the extra space there for history.

A lighter-weight approach would be to use rsync or unison instead, to
synchronize the satellite hosts to the master.  That would avoid the space
and work overhead of keeping the version control history, but you'd lose
the ability to roll back changes if for some reason they created problems.
Permalink | Reply | 0 comments |
headers
Dave Korn | 1 Feb 2010 15:56

Re: dlclose not calling destructors of static variables.

On 01/02/2010 11:46, Andrew West wrote:

> I checked out the changes and it still crashed for me. Digging into it
> the destructor for testlib fell outside of dll_end ( m.AllocationBase +
> m.RegionSize ). On a whim I change m.AllocationBase to m.BaseAddress and
> that seemed to fix it for me! The destructor ran on dlclose and the
> testrunner.exe didn't segfault.

  As promised, I'm working on the other half of this problem.

> On 29/01/2010 18:45, Christopher Faylor wrote:
> 
>> I agree with your assessment here.  I've checked in a change which works
>> around the problem you've uncovered but it is not foolproof.  

  It's definitely the right thing to do, we'll need it for a while to support
any existing DLLs with ctors.  (We did touch on this whole area briefly back
when sorting out the mallocwrapper stuff w.r.t dlopen/close, and I looked at
it briefly then but we were trying to stabilise for 1.7.1 at the time.)

  Doesn't remove_dll_atexit() need some locking, though?

> It should
>> fix the immediate problem but, in the long run, I agree that gcc should
>> be emitting code which calls __cxa_atexit.  Of course I have no idea
>> what the other ramifications of doing that might be.  Hopefully Dave can
>> enlighten us.

  I'm doing a patch this afternoon to add the necessary support in the DLL and
CRT.  Once that's in, people could start using it straight away by adding
(Continue reading)

Permalink | Reply | 0 comments |

Gmane