[ANNOUNCEMENT] Updated: mintty-0.3.7-1

[Andy Koppe]

MinTTY is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Its terminal emulation is largely
compatible with xterm, but it does not require an X server to be
running. It is based on code from PuTTY 0.60 by Simon Tatham and team.

This is a compatibility update.

CHANGES (since 0.3.6-1)
===
- The Home and End keys now send "PC-style" ^[[H and ^[[F instead of
VT220-style ^[[1~ and ~[[4~. This is for compatibility with xterm's
default configuration and the xterm termcap/terminfo entries, which
means that Home and End should work out-of-the box now in bash, i.e.
configuring them in ~/.inputrc is no longer necessary.
- The Reset menu command and the ^[c ('Full Reset') control sequence
now clear the scrollback as well as the screen.
- The manual page has gained a tip on using 'sh -c' for setting
environment variables in mintty shortcuts.

Details of these changes can be found at
http://code.google.com/p/mintty/issues/list?can=1&q=Milestone%3A0.3.7

QUESTIONS
=
MinTTY's project page is located at http://mintty.googlecode.com.
Please use the issue tracker there to report bugs or suggest
enhancements. Questions or comments can be sent to the MinTTY
discussion group at http://groups.google.com/group/mintty-discuss or
the Cygwin mailing list at cygwin@cygwin.com .



To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Then, run setup and answer all of the questions.

   *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

1.7 slow while accessing the netapp drive

[Pach Roman (DGS-EC/ESG3)]

I've just compared the speed of 1.5 and 1.7 while accessing the drive of the 
type 'netapp'.

The results for cygwin-1.5 (DLL version: 1.5.25) follow:
> mount
u: on /u type user (binmode)

> time ls -l /u
...
real0m1.063s
user0m0.046s
sys 0m0.031s

And now the same test for cygwin-1.7 (CYGWIN_NT-5.1 1.7.0(0.206/5/3) 2009-03-11 
14:08):
> mount
U: on /u type netapp (binary,noacl,user)

> time ls -l /u
...
real0m2.140s
user0m0.061s
sys 0m0.186s

The duration of 1.7 access to the netapp drive is the twice of 1.5.
Are there any reasons for this behavior?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [1.7] BUG: heap_chunk_in_mb=1536 breaks expect.

[Corinna Vinschen]

On Mar 15 22:53, Dave Korn wrote:
> 
>   Apologies for what is going to be quite light on details as bug reports go,
> but I've only just noticed it and I haven't got a simple testcase yet.
> 
>   As the subject line says, heap_chunk_in_mb=1536 breaks expect.  The
> situation that I'm seeing this in is when attempting to run the binutils
> testsuite.
> 
>   With heap_chunk_in_mb set to 1536, "make -k check" gets as far as the very
> first *.exp file in the binutils testsuite (binutils-all/ar.exp), and then
> sits there, spinning its wheels and eating CPU.  It doesn't happen if
> heap_chunk_in_mb is set to 1024, 1280, 1408, 1520 and the test run completes.
>  It does happen at 1535, and 1532.  At 1528 to 1530 it gets a few testcases
> further into the run before stalling.  Probably the exact cut-off point is
> environment-dependent.
> 
>   Sorry not to have much information, but at least there's a simple
> workaround: turn it down a bit.  If I find out more I'll report back.

The code handling heap_chunk_in_mb hasn't changed at all since 1.5.25,
except for the registry location where it's loaded from.  I'm wondering
if the mere size of the heap chunk is enough here to disturb
functionality which requires more memory in 1.7 than in 1.5.  For
instance, practically all file operations need more memory now (buffers
for conversion to UNICODE, enough room for long paths).  And 1.5 Gigs +
sizeof all DLLs + sizeof executable is quite easily filling up the 2
Gigs virtual mem size for the process.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: gdb crashes when debugging setup.exe

[ludo]

Dave Korn a écrit :
[...]

  Is maybe one of you using gcc-3 with stabs debug and the other using gcc-4
with dwarf-2 debug?



  I also forgot to ask, 1.5 or 1.7?
  

I use gcc 3 and gdb 6.8.0
it is the version 1.5 of setup (and I compile it with the gcc 3.4.4)

$ gcc --version
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gdb --version
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.7 slow while accessing the netapp drive

[Corinna Vinschen]

On Mar 16 10:10, Pach Roman (DGS-EC/ESG3) wrote:
> I've just compared the speed of 1.5 and 1.7 while accessing the drive of the 
> type 'netapp'.
> 
> The results for cygwin-1.5 (DLL version: 1.5.25) follow:
> > mount
> u: on /u type user (binmode)
> 
> > time ls -l /u
> ...
> real0m1.063s
> user0m0.046s
> sys 0m0.031s
> 
> And now the same test for cygwin-1.7 (CYGWIN_NT-5.1 1.7.0(0.206/5/3) 
> 2009-03-11 14:08):
> > mount
> U: on /u type netapp (binary,noacl,user)
> 
> > time ls -l /u
> ...
> real0m2.140s
> user0m0.061s
> sys 0m0.186s
> 
> The duration of 1.7 access to the netapp drive is the twice of 1.5.
> Are there any reasons for this behavior?

Probably, but I don't know them.  I have no netapp access.  If you're
interested to gain speed, you will have to debug this locally.
Typically file access in 1.7 should be a bit faster than on 1.5 and
netapp is practically handled like any FAT drive in 1.7.

Hmm, on second thought, there's a difference here.  File access in 1.7
is by default case-sensitive if your obcaseinsensitive kernel flag is
set 
(http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive).
Can you change your mount entry for your netapp drive so that you add
the option "posix=0" and restart your Cygwin session?  Does that help?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] New: {xz/liblzma0/liblzma-devel}-4.999.8beta-10

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Yaakov (Cygwin/X) on 3/15/2009 9:45 PM:
>>> should: .xz files are already being used by some upstream source
>>> distribution sites, including GNU FSF, and the new format includes
>>> features (such as internal integrity checks) that the old .lzma
>>> format lacks.
>> So if I'm reading this right, is the attached patch for cygport correct?
> 
> Oops, this would require a version bump for tar.  Eric??

Tar 1.22 has been released upstream which changes -J from lzma to xz.  I'm
working on packaging it, along with several other packages (my free time
has been limited lately).

- --
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm+PsYACgkQ84KuGfSFAYAdxACdHH+6ELjJvDaezl6oC/L6CRIw
xG4AoInm2fEDdQt2ho6kUzMys7+M7Av6
=ZirZ
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

cygwin/x and windows windows

[Mojmir Svoboda]

hello,

i'd like to ask whether there is a way to control every window from
cygwin/x environment. i mean having one fullscreen x server running and
show win applications as if they were managed by the window manager
running on top of x.

many thanks,
mojmir

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: clearing the scrollback buffer in mintty

[Andy Koppe]

Lee D. Rothstein:
> Dave Korn "piped":
>
>> For gui consoles, use
>
>>  alias cls='echo -e "\033c"'
>
>> which does clear the scrollback buffer.
>
> Thanks Dave, this works on 'xterm' but not on 'mintty'.
>
> On 'mintty' it does a 'clear' (i.e., clears the screen),
> rather than a 'cls' (i.e., clears the screen and
> scrollback buffer.

Fixed in 0.3.7.

Andy

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: mintty & less

[Andy Koppe]

Lee D. Rothstein:
> I'm having some problems with 'less' in a 'mintty' window that are not
> consistent. Specifically while paging through stdin (to 'less'), in
> 'less', the first time I try to use  or  to go respectively
> to the beginning or end of the stdin stream, the 'less' navigation
> hangs until I hit -c. Then they each work.

Hmm, less could be getting confused by the VT220-style Home/End
keycodes that mintty sent so far. 0.3.7 sends "PC-style" keycodes that
are compatible with the xterm terminfo entry.

To get them working in less, add these two lines to ~/.lesskey (and
run lesskey to translate it into the binary ~/.less):

  \eOH goto-line
  \eOF goto-end

Andy

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: peflags utility

[Corinna Vinschen]

On Mar 16 02:32, Charles Wilson wrote:
> Here's revision 3. I've revised the UI to be more like what was
> eventually accepted by binutils.  One difference is that the ld options
> allow only to set flags:
>   ld --tsaware
> 
> With peflags we can set, clear, or display them:
>   peflags --tsaware: display
>   peflags --tsaware=1  : set
>   peflags --tsaware=0  : clear
> 
> If this is more-or-less ok, I'll get started on the peflagsall script,
> and send it all with updated docu as a patch for Jason to use in the
> next rebase release.
> 
> gcc -o peflags.exe -DVERSION='"2.4.5"' peflags.c

Looks good, except for three minor details I found.  Patch attached.

- The output is missing a trailing \n.

- Error output is missing an error description:

$ ./peflags --tsaware=1 /bin/tcsh
Error: could not update pe characteristics (/bin/tcsh)

  Yes, but... why?  The patch adds errno output, like this:

$ ./peflags --tsaware=1 /bin/tcsh
Error: could not update pe characteristics (/bin/tcsh): Device or resource 
busy

- The get/set characteristics function are calling close(fd) even
  if open failed.  This leads to wrong errno output after applying the
  above errno output.


Corinna


--- peflags.c.ORIG  2009-03-16 13:18:06.0 +0100
+++ peflags.c   2009-03-16 13:37:55.0 +0100
@@ -317,16 +317,16 @@ do_mark (const char *pathname)
 if (set_coff_characteristics (pathname,new_coff_characteristics) != 0)
   {
 fprintf (stderr,
- "Error: could not update coff characteristics (%s)\n",
-  pathname);
+ "Error: could not update coff characteristics (%s): %s\n",
+  pathname, strerror (errno));
 return 1;
   }
   if (new_pe_characteristics != old_pe_characteristics)
 if (set_pe_characteristics (pathname,new_pe_characteristics) != 0)
   {
 fprintf (stderr,
- "Error: could not update pe characteristics (%s)\n",
-  pathname);
+ "Error: could not update pe characteristics (%s): %s\n",
+  pathname, strerror (errno));
 return 1;
   }
 }
@@ -393,6 +393,7 @@ do_mark (const char *pathname)
   else
 printf ("pe(0x%04x) ", old_pe_characteristics);
 }
+  puts ("");
 }
 
   return 0;
@@ -704,7 +705,7 @@ get_characteristics(const char *pathname
 
   fd = open (pathname, O_RDONLY|O_BINARY);
   if (fd == -1)
-goto done;
+return status;
 
   if (pe_get32 (fd, 0x3c, &pe_header_offset) != 0)
 goto done;
@@ -741,7 +742,7 @@ set_coff_characteristics(const char *pat
  get_characteristics already did that */
   fd = open (pathname, O_RDWR|O_BINARY);
   if (fd == -1)
-goto done;
+return status;
 
   if (pe_get32 (fd, 0x3c, &pe_header_offset) != 0)
 goto done;
@@ -774,7 +775,7 @@ set_pe_characteristics(const char *pathn
  get_characteristics already did that */
   fd = open (pathname, O_RDWR|O_BINARY);
   if (fd == -1)
-goto done;
+return status;
 
   if (pe_get32 (fd, 0x3c, &pe_header_offset) != 0)
 goto done;


-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem with 575 man pages -- cygport problem?

[Christopher Faylor]

On Mon, Mar 16, 2009 at 01:35:38AM -0400, Lee D.Rothstein wrote:
> A large number (575) of 'man' pages, that reference other man pages using a
> '.so' (source include) reference, fail to work because the plain text files
> have the '.gz' extension appended without actually being gzipped. Could
> this be due to a mishap in or with the 'cygport' package?
>
> Each reference appears to be okay (I've only tested a handful), iff you
> remove the '.gz' extension.
>
> Following is a list of such man page error messages with a few of them
> actually verified to have the situation I describe above.

Please stop repeating the same message.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [1.7] BUG: heap_chunk_in_mb=1536 breaks expect.

[Christopher Faylor]

On Mon, Mar 16, 2009 at 10:41:19AM +0100, Corinna Vinschen wrote:
>The code handling heap_chunk_in_mb hasn't changed at all since 1.5.25,
>except for the registry location where it's loaded from.  I'm wondering
>if the mere size of the heap chunk is enough here to disturb
>functionality which requires more memory in 1.7 than in 1.5.  For
>instance, practically all file operations need more memory now (buffers
>for conversion to UNICODE, enough room for long paths).  And 1.5 Gigs +
>sizeof all DLLs + sizeof executable is quite easily filling up the 2
>Gigs virtual mem size for the process.

I wonder if we should just nuke this setting entirely.  It shouldn't really
be tremendously useful anymore.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How can I ssh to a Windows box?

[Wilfried]

Michael Hennebry  wrote:

> On Fri, 13 Mar 2009, Wilfried wrote:
> 
> > Michael Hennebry  wrote:
> >
> >> On Thu, 12 Mar 2009, Wilfried wrote:
> >>
> >>> Michael Hennebry  wrote:
> >>>
>  On Mon, 9 Mar 2009, Michael Hennebry wrote:
>  ...
>  I've discovered that if I kill the demon,
>  I still get timeout from the outside,
>  but connection refused locally.
> >>>
> >>> If you can login to ssh locally but not from the outside, perhaps your
> >>> Windows' firewall is blocking this.
> >>
> >> That was my thought, too,
> >> but it seems to be correct and turning it off didn't help.
> >> Could I be missing a similar flag somewhere?
> >
> > Perhaps some antivirus software?
> 
> I've got Norton and ThreatFire.

Then uninstall them, restart your PC, and try again.
See http://cygwin.com/faq/faq.using.html#faq.using.bloda
 
> > Also have a look in
> > (windows') control panel - administration - event viewer - application
> > Any entries for sshd?
> > Any error entries?
> 
> Yes.  Four, all the same.

How many entries of sshd do you have after a restart of your computer?
If it's more than one, you should clean up the registry from all entries
pointing to sshd and then re-install the service.


--
Wilfried Hennings


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [1.7] BUG: heap_chunk_in_mb=1536 breaks expect.

[Dave Korn]

Christopher Faylor wrote:
> On Mon, Mar 16, 2009 at 10:41:19AM +0100, Corinna Vinschen wrote:
>> The code handling heap_chunk_in_mb hasn't changed at all since 1.5.25,
>> except for the registry location where it's loaded from.  I'm wondering
>> if the mere size of the heap chunk is enough here to disturb
>> functionality which requires more memory in 1.7 than in 1.5.  For
>> instance, practically all file operations need more memory now (buffers
>> for conversion to UNICODE, enough room for long paths).  And 1.5 Gigs +
>> sizeof all DLLs + sizeof executable is quite easily filling up the 2
>> Gigs virtual mem size for the process.
> 
> I wonder if we should just nuke this setting entirely.  It shouldn't really
> be tremendously useful anymore.

  Well, let me check whether it's possible to link libgcj without it first...

cheers,
  DaveK

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: using gcc-4.3.2-2: gcc-4 -shared-libgcc

[Jason Tishler]

Chuck,

On Sun, Mar 15, 2009 at 03:05:37PM -0400, Charles Wilson wrote:
> Reini Urban wrote:
> > I hope that the frequent Vista unable to remap perl Cwd.dll errors
> > will be gone then, but I have not Vista to test.
> 
> Using peflags to mark Cwd.dll with dynbase solves the problem for me.
> Now that binutils' ld has a the capability to do this, and they have
> decided on a command line syntax, I'll rework peflags to match. Then,
> it's up to Jason to release a new version of the rebase package
> containing the new utility.

I've been AWOL, but lurking... :,)  I'm quite willing to release rebase
when your patch is ready.

Thanks,
Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: gcc4-java: packaging error?

[Charles Wilson]

This is an interesting thread, related to the future (and/or current
state) of gcj:

http://gcc.gnu.org/ml/java/2009-02/msg4.html

Which is not to say that cygwin's gcc distribution shouldn't include it,
or ensure that it works as well as possible, but it may explain why some
distros are packaging it separately (that is, building it from a
separate source from the rest of gcc-same-version).  OTOH, Debian has
been doing it that way since 4.1.0 (2 Mar 2006), long before OpenJDK was
actually open [*], so perhaps they have another reason. They do it that
way for Ada, too.

--
Chuck

[*] Sun's announcement of a forth-coming GPLed JDK: Nov 2006.  OpenJDK
initial code release, May 2007.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem with 575 man pages -- cygport problem?

[Lee D. Rothstein]

Christopher Faylor wrote:

On Mon, Mar 16, 2009 at 01:35:38AM -0400, Lee D.Rothstein wrote:
  

A large number (575) of 'man' pages, that reference other man pages using a
'.so' (source include) reference, fail to work because the plain text files
have the '.gz' extension appended without actually being gzipped. Could
this be due to a mishap in or with the 'cygport' package?

Each reference appears to be okay (I've only tested a handful), iff you
remove the '.gz' extension.

Following is a list of such man page error messages with a few of them
actually verified to have the situation I describe above.



Please stop repeating the same message.

cgf

  
I repeated the message the first time because the original subject did 
not specifically mention 'cygport'.


If 'cygport' is at fault this is a serious problem that compromises many 
packages.


I repeated the message, again, because I got a message from what I 
thought was the list's server
saying the message had been bounced because it had an attachment with an 
unacceptable name.

And, I got no responses.

Now, I see that the message got through.

Cheers,

Lee


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: mintty & less

[Lee D. Rothstein]

Andy Koppe wrote:

Lee D. Rothstein:
  

I'm having some problems with 'less' in a 'mintty' window that are not
consistent. Specifically while paging through stdin (to 'less'), in
'less', the first time I try to use  or  to go respectively
to the beginning or end of the stdin stream, the 'less' navigation
hangs until I hit -c. Then they each work.



Hmm, less could be getting confused by the VT220-style Home/End
keycodes that mintty sent so far. 0.3.7 sends "PC-style" keycodes that
are compatible with the xterm terminfo entry.

To get them working in less, add these two lines to ~/.lesskey (and
run lesskey to translate it into the binary ~/.less):

  \eOH goto-line
  \eOF goto-end

Andy

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


  
Thanks, Andy, this worked. Now, I'll go install 0.3.7, and see what 
happens. ;-)


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Ignore me

[Chris Carlson]

I've subscribed to this list, but my messages don't appear.

This is a test to see if this one does.

Thanks for your patience.
Chris


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem with 575 man pages -- ( libncurses-devel-5.7-4 problem? )

[David Dyck]

On Sun, 15 Mar 2009 at 22:35 -0700, l...@... wrote:


A large number (575) of 'man' pages, that reference other man pages using a
'.so' (source include) reference, fail to work because the plain text files
have the '.gz' extension appended without actually being gzipped. Could
this be due to a mishap in or with the 'cygport' package?

Each reference appears to be okay (I've only tested a handful), iff you
remove the '.gz' extension.


I see a similar list (only 574 :-) if I execute the following commands

$ cd /usr/share/man/man3
$ file *.gz | perl -ne 's/^[^:]*:\s*//; print unless /gzip compressed data/' | 
sort  | uniq -c
574 ASCII troff or preprocessor input text

The error message I see

$ man wtimeout

gzip: /usr/share/man/man3/wtimeout.3x.gz: not in gzip format
fgets: No such file or directory
Error reading man page /usr/share/man/man3/wtimeout.3x.gz
No manual entry for wtimeout

If I examine where the files come from

$ cd /usr/share/man/man3
$ file *.gz | perl -ne 's/^([^:]*)://; my $f=$1; unless ( /gzip compressed data/ ) { my $cmd = 
"cygcheck -f $ENV{PWD}/$f"; print "$f - ".`$cmd`;  } '

I see they all come from one package "libncurses-devel-5.7-4"

To verify this a quick look at the man3 pages that are installed from libncurses-devel 
reveals  the same 574 .gz files that aren't really compressed.

 (I needed the dos2unix because the output of the cygcheck/grep pipe had \015 
at the end of the lines,
  which caused xargs to choke)

$ cygcheck -l libncurses-devel | grep 'man3.*gz' |  dos2unix | xargs file  | 
perl -ne 's/^[^:]*:\s*//; print unless /gzip compressed data/' | sort  | uniq -c
574 ASCII troff or preprocessor input text

So, at least many of your 575 files that are incorrectly named as .gz files 
are from one package.  Perhaps this will bring you closer to a solution.


David

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin/x and windows windows

[Larry Hall (Cygwin)]

Mojmir Svoboda wrote:

hello,

i'd like to ask whether there is a way to control every window from
cygwin/x environment. i mean having one fullscreen x server running and
show win applications as if they were managed by the window manager
running on top of x.


Wrong list.  If you read the description of the lists at
 you will find this description for the
Cygwin list:

  If you have questions about how to use Cygwin, or if you have
  Cygwin-specific  (see above) questions, bugs, or observations about the
  UNIX tools (bash, gcc, make, etc.) that come with Cygwin, this is the list
  for you (although it's very possible that you will receive more qualified
  help for such tools on their specific non-Cygwin mailing lists). There are
  a few exceptions to the "all things Cygwin" nature of this list:

* Questions about the Cygwin/X project (or any X-related questions for
  Cygwin) should go to the cygwin-xfree mailing list (see below).


--
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?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] [1.7] Updated: file-5.00-3

[Corinna Vinschen]

I've updated the Cygwin 1.7 version of file to 5.00-3.

The Cygwin version is build from the vanilla sources with the latest
libtool applied, a minor change in an error message, as well as with
removed Cygwin-specific code which is not required anymore when running
under Cygwin 1.7.  All changes have been send upstream.

This new version is built against the latest versioned libgcc shared
library to drop the requirement to keep the old non-versioned libgcc
in the Cygwin net distribution.


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available   
starting at this URL.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Ignore me

[Larry Hall (Cygwin)]

Chris Carlson wrote:

I've subscribed to this list, but my messages don't appear.

This is a test to see if this one does.


This practice is very much frowned upon here.  If you send email to
this list and it succeeds, you can find it here:



If it doesn't, you'll get a bounce message with a description of the
problem and what you should do to solve it.  If you still cannot solve
your problem,  recommends this:

If you have any questions or problems with the mailing lists, see the 
Sourceware mailing list FAQs .


Please follow this recommended course of action if you (or others) have
similar issues in the future.

FWIW, the Cygwin list does not require that you subscribe before you post.
It is, however, generally appreciated if you do.

--
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?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13

[A.R. Burgers]

Any special reason for specifying -lm and -lc when building d3.dll?
Without them, pow is mentioned only once in the objdump output. However 
on 1.5 pow is mentioned only once, even if -lm and -lc

are specified.

The exact same problem as with zsh, I also run into with fltk's 
fluid.exe (from current 1.3 svn) on cygwin 1.7 and gcc 3.4.4.

fltk btw does not link to curses libraries.

Teun

Peter A. Castro schreef:


On Sun, 15 Mar 2009, Dave Korn wrote:

Hi Dave!


Peter A. Castro wrote:


  Using the Dependency Walker tool that Chuck pointed out (thanks
Chuck!)


 No problem, Basil!


"Basil!"  I love it! (you know I was just kidding! :-)


Could this really be a linker problem?


 If it's not a linker problem, it has to be a faulty import library.  
I can't
think of any other option that would explain how that import table got 
munged

like that.  I'll see if I can reproduce it.


I've been extracting modules from the import libs and dumping
import/export symbols from the two libncurses DLLs, but I can't seem to
find anything that looks wrong.

However... this I find strange:

file d3.c:

#include 

double my_pow( double d1, double d2 )
{
  double d;
  d = pow(d1,d2);
  return d;
}


$ gcc -g -shared -o d3.dll d3.c -lm -lc
$ objdump -x d3.dll

...
There is an import table in .idata at 0x10004000

The Import Tables (interpreted .idata section contents)
 vma:HintTime  Forward  DLL   First
 Table   Stamp ChainName  Thunk
 4000   4050   416c 4084

DLL Name: cygwin1.dll
vma:  Hint/Ord Member-Name Bound-To
40b8  351  _impure_ptr
40c8  720  calloc
40d4  779  cygwin_detach_dll
40e8  781  cygwin_internal
40fc  802  dll_dllcrt0
410c  917  free
4114 1186  malloc
4120 1395  realloc
412c 1285  pow

 4014   4070   416c 40a4

DLL Name: cygwin1.dll
vma:  Hint/Ord Member-Name Bound-To
412c 1285  pow

 4028   407c   417c 40b0

DLL Name: KERNEL32.dll
vma:  Hint/Ord Member-Name Bound-To
4134  337  GetModuleHandleA

 403c       
...


Why is 'pow' being pulled in twice?  Maybe it's really the math lib stuff
that's tickling the linker?  This is kinda looking more like some linker
bug.  Again, I'm not sure where to go next.  It's been a while since I
dug into gcc...


   cheers,
 DaveK





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Porting to GCC 4.3.2

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Václav Haisman wrote, On 15.3.2009 12:19:
> Hi,
> I am trying to use GCC 4.3.2 to compile log4cplus 1.0.3 source. Compilation
> works but test cases that are using the resulting DLL do not work. The $?
> shell variable ends up with value 5. I used depends.exe on the test case
> executable and it finds all dependencies except DWMAPI.DLL. After some
> digging
> (
> and
> )
> my question is: Does the GCC 4.3.2 change how delay loaded DLLs are handled
> or is this problem unrelated to mine?
The problem is apparently not this.

> 
> I am using Windows XP and Cygwin 1.5.

I have added -Wl,--enable-auto-import to the compiler command line and it has
fixed the resulting executable for me.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkm+qQQACgkQhQBMvHf/WHmY+QDdHxljq4x6A8jcYG1l/d4sJqUl
gTXCj7NJW6Z+RADfRGhd9Yau71GpDdacmlAV/tzhwfXSUoN7ppje1A==
=0sYD
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Porting to GCC 4.3.2

[Dave Korn]

Václav Haisman wrote:

>> I am using Windows XP and Cygwin 1.5.
> 
> I have added -Wl,--enable-auto-import to the compiler command line and it has
> fixed the resulting executable for me.

  You should have received a warning message during compilation telling you
that you might need to do that.  Did it turn up in your earlier builds before
you added the flag?

cheers,
  DaveK

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Porting to GCC 4.3.2

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dave Korn wrote, On 16.3.2009 20:52:
> Václav Haisman wrote:
> 
>>> I am using Windows XP and Cygwin 1.5.
>> I have added -Wl,--enable-auto-import to the compiler command line and it has
>> fixed the resulting executable for me.
> 
>   You should have received a warning message during compilation telling you
> that you might need to do that.  Did it turn up in your earlier builds before
> you added the flag?
Yes, the warning is there. I did not notice it in the oodles of other
auto-import info messages.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkm+whYACgkQhQBMvHf/WHkE5gDggc2YysuHFVEEeeqmOV2oOX5U
JJtkRFsuI021WgDgjI9FiO8ei2DmyTyYIMRg2JjbEPqYUmppaJB8ZQ==
=M6qU
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Porting to GCC 4.3.2

[Andy Koppe]

Václav Haisman wrote:
>>   You should have received a warning message during compilation telling you
>> that you might need to do that.  Did it turn up in your earlier builds before
>> you added the flag?
> Yes, the warning is there. I did not notice it in the oodles of other
> auto-import info messages.

Use -Werror. Should be a legal requirement. ;)

Andy

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Porting to GCC 4.3.2

[Dave Korn]

Václav Haisman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dave Korn wrote, On 16.3.2009 20:52:
>> Václav Haisman wrote:
>>
 I am using Windows XP and Cygwin 1.5.
>>> I have added -Wl,--enable-auto-import to the compiler command line and it 
>>> has
>>> fixed the resulting executable for me.
>>   You should have received a warning message during compilation telling you
>> that you might need to do that.  Did it turn up in your earlier builds before
>> you added the flag?
> Yes, the warning is there. I did not notice it in the oodles of other
> auto-import info messages.

  Thanks, just checking that there wasn't a bug causing it to be omitted.

  We've fixed this in upstream CVS versions of 'ld' by enabling auto import by
default for now.  If you're happy with building your own tools, you could
check out the binutils repository and build yourself a version that doesn't
emit all the warnings, or there will be a new binutils release coming along
fairly soon.

cheers,
  DaveK


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Did anyone download the Windows 7 beta?

[S. Cowles]

in january there was discussion about the windows 7 beta and how cygwin 
was performing on it.  i'm late to the party on this issue and did not 
have the same experience related by the early adopters at that time.


i'm currently running win7 as a vmware guest with 2 cpus and 1G memory on 
a quad cpu ubuntu host.  in order to install services, i had to turn off 
win7 UAC entirely.  i tried each of the top two settings for UAC and 
neither allowed any changes to files or directories (after a full download 
using setup).  i could not change permissions on c:\cygwin or 
c:\cygwin\home, for instance, from either properties dialogs or from 
within a bash shell session using chown and chmod.  after deactivating 
UAC, service installs and configurations proceeded with no surprises. 
(services, here, included cygrunsrv, crontab, exim, and sshd.)


i've never run vista, so i'm new to the UAC.  is it normal procedure to 
deactivate UAC like this?


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13

[A.R. Burgers]

A.R. Burgers schreef:

The exact same problem as with zsh, I also run into with fltk's 
fluid.exe (from current 1.3 svn) on cygwin 1.7 and gcc 3.4.4.

fltk btw does not link to curses libraries.



fltk's fluid depends on libpng and libjpeg.
If I move back to from jpeg 6b-20 to 6b-12 and
from png 1.2.35-10 to 1.2.12-1, the built fluid.exe
will launch successfully.

Teun


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Did anyone download the Windows 7 beta?

[Dave Korn]

S. Cowles wrote:

> i've never run vista, so i'm new to the UAC.  is it normal procedure to
> deactivate UAC like this?

  Depends how cynical you're being ;-)  A lot of complaints have been
addressed at how UAC is so intrusive users just end up turning it off
completely.  (It's also, at least in win7, trivial for viruses etc. to bypass
programmatically, because MS left a wide-open back door in it for the benefit
of their own software.  Duh!)


cheers,
  DaveK

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Duplicate mintty window (was: Re: MinTTY 0.3.3)

[Andy Koppe]

bjoe wrote:
>> > What I found missing in Mintty is putty feature to start duplicate
>> > session (more welcome with hot-keys)
>>
>> Since MinTTY doesn't have sessions like Putty, I didn't think there
>> was much point in keeping this.
>
> It's because you remove networking function from putty, right. IMHO
> this feature will help many user (especially who come from Windows
> word)

MinTTY is meant to be a small and simple command line window for
Cygwin with a native UI, no more, no less. It's the classic Unix
philosophy: do one job, and do it well. Cygwin already has all the
necessary network tools in ssh, telnet & co., and they can easily be
combined with mintty, so there was no point in keeping all that
security-critical code.


> I don't know the relationship between networking function in Putty with
> duplicate session feature in code point of view, but since this based
> on putty code I hope this will not give some sort of difficulty to
> adopt this feature in mintty.

It's fairly easy to do actually. Instead of a session it would simply
invoke mintty again with the same command line, for much the same
effect. The concern was about unnecessary features: no point
cluttering up the interface with stuff that can already be done with
system-wide facilities.


>> Desktop and quickstart shortcuts already provide quick ways to open a
>> new MinTTY window, and as discussed on a separate thread here you can
>> assign hotkeys to Windows shortcuts.
>
> I run Cygwin from portable media in different PC so Desktop and
> quickstart shortcut not an options in My case.

Alright, I give in on this one. You could probably use AutoHotkey or
something like that, but I guess including this in MinTTY really is
quite a bit more convenient, also in comparison with shortcuts.

I'll stick a Duplicate command in the window menu, with disablable
shortcut Alt+F2. Reopened issue 11:
http://code.google.com/p/mintty/issues/detail?id=11

Andy

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Not a cygport problem [Was: Re: Problem with 575 man pages -- cygport problem?]

[Charles Wilson]

It took a while to track this down, but the issue is in ncurses'
internal mechanisms for installing man pages. Basically, it's too clever
for its own good.

Simple packages do this:
  I have man page. I put man page in mandir.  The end.
   /usr/share/man/man1/foo.1
Sometimes, they might have aliases implemented via symlinks, so that
'man bar' gets you the same text as 'man foo':

   /usr/share/man/man1/foo.1
   /usr/share/man/man1/bar.1 -> foo.1

cygport comes along and looks for symlinks in the mandir, figures out
what the target is, removes the symlink and replaces it with a file with
content:
   .so foo.1

Then, cygport gzips all the files, leaving

   /usr/share/man/man1/foo.1.gz
   /usr/share/man/man1/bar.1.gz (not a symlink)

This works fine.  ncurses tries to do something similar, except it
parses the man pages themselves for all entries in the NAME section, and
creates the stub files (.so target) for each of them manually. AND
optionally gzips, compresses, nroffs, and tbls them, installing each to
different hierarchies under /usr/share/man, depending on 27 different
configure arguments.

It got a little confused.

(What's odd is I didn't specify any of those 27 configure arguments; I
just wanted it to do the same thing I always do: --with-manpage-symlinks
(e.g. don't monkey around with .so files; just use symlinks [and I'll
let cygport do the heavy lifting]).

This worked in 5.5...but not, apparently, 5.7.

It will be a while until I get around to respining ncurses AGAIN, so in
the meantime, this should fix it:

#!/bin/sh
find /usr/share/man -type f -name "*.gz" |\
xargs file | grep 'ASCII troff' | awk -F: '{print $1}' |\
while read F ; do
  B=${F%%.gz}
  mv ${F} ${B}
  gzip ${B}
done

--
Chuck


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13

[Charles Wilson]

A.R. Burgers wrote:
> Any special reason for specifying -lm and -lc when building d3.dll?
> Without them, pow is mentioned only once in the objdump output. However
> on 1.5 pow is mentioned only once, even if -lm and -lc
> are specified.
> 
> The exact same problem as with zsh, I also run into with fltk's
> fluid.exe (from current 1.3 svn) on cygwin 1.7 and gcc 3.4.4.
> fltk btw does not link to curses libraries.

Hmm. All of these packages are mine (libpng, jpeg, ncurses), and all
have been rebuilt recently after a long fallow period. However, I didn't
do anything really tricky when building these libraries, so they oughta
Just Work.  They were more-or-less just ./configure; make; make install
in each case, with a few local patches that were constant between old
("working") and new ("not working"?).

What they all have in common is, that the older ("working") versions
were built using gcc-3.4.4-3 and binutils-20060817-1.  The new ("not
working") versions were built using gcc-3.4.4-999 and binutils-20080624-2.

Now, binutils-20080624-2 has been in use for over six months. I
*suppose* it's possible that it has a bug that is only now being
tickled.  But (a) the internal apps in each package, which use the DLLs
and import libs and were built using the "new" binutils, all work, and
(b) folks have been using the "new" linker for quite some time now
without these sorts of reports.  gcc is different, but it's pretty much
out of the loop by the time the things that could cause the reported
symptoms could occur; it's all ld at that point.

Looking at the DLLs and import libs, I don't see anything odd. I'd
really like to figure out if the problem is on the library creation end
(either in gcc, ld, or something stupid I may have done/am still doing
wile creating them) -- which means I have to rebuild all of my newly
updated packages. AGAIN.

Or if the problem is on the client end: either something silly is
happening in both Vin Shelton's AND Teun Burger's build process, or
their ld is having trouble.  Both seem unlikely.

I'm going to try the following:
(1) make sure I can reproduce the OP's troubles with zsh and new ncurses.

(2) downgrade binutils to 20060817 and see if that fixes it. Not really
sure what that shows, since

  library linked with old ld, linked into app using new ld --> works
  library linked with new ld, linked into app using new ld --> broken
? library linked with old ld, linked into app using old ld --> ??
? library linked with new ld, linked into app using old ld --> ??

If both of the last two work, then we have a case where for some reason
new ld can't eat its own dog food -- but it's been happily doing so for
six months until just now (with other maintainer's released libs). Well,
it'll be another data point...

--
Chuck


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Not a cygport problem [Was: Re: Problem with 575 man pages -- cygport problem?]

[Chris Sutcliffe]

Minor tweak to the proposed shell script fix to make it work.  This:

> xargs file | grep 'ASCII troff' | awk -F: '{print $1}' |\

Should be this:

> xargs file | grep 'ASCII text' | awk -F: '{print $1}' |\

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13

[Dave Korn]

Peter A. Castro wrote:

> file d3.c:
> 
> #include 
> 
> double my_pow( double d1, double d2 )
> {
>   double d;
>   d = pow(d1,d2);
>   return d;
> }
> 
> 
> $ gcc -g -shared -o d3.dll d3.c -lm -lc
> $ objdump -x d3.dll

> DLL Name: cygwin1.dll
> vma:  Hint/Ord Member-Name Bound-To

> 412c 1285  pow
> 
>  4014   4070   416c 40a4
> 
> DLL Name: cygwin1.dll
> vma:  Hint/Ord Member-Name Bound-To
> 412c 1285  pow

> Why is 'pow' being pulled in twice?  

  Dunno.  I can't reproduce it.  There must be some environment difference
between your system and mine.  You didn't specify whether you were using gcc3
or gcc4 for that example, so I tried them both, and neither reproduced:

$ cat d3.c
#include 

double my_pow( double d1, double d2 )
{
  double d;
  d = pow(d1,d2);
  return d;
}

$ gcc-3 -g -shared -o d3.dll d3.c -lm -lc
$ objdump -x d3.dll > with-3.txt
$ gcc-4 -g -shared -o d3.dll d3.c -lm -lc
$ objdump -x d3.dll > with-4.txt
$ diff -pu with-3.txt with-4.txt
--- with-3.txt  2009-03-17 02:34:40.46875 +
+++ with-4.txt  2009-03-17 02:34:56.515625000 +
@@ -3,7 +3,7 @@ d3.dll: file format pei-i386
 d3.dll
 architecture: i386, flags 0x013b:
 HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED
-start address 0x10001050
+start address 0x69b41120

  Note this change, it could be relevant.  GCC-4 passes the
'--enable-auto-image-base' option to the linker, which is supposed to help us
avoid fork errors in future.  Here are the import tables:


@@ -61,52 +61,53 @@ Entry d   Delay Import D
 Entry e   CLR Runtime Header
 Entry f   Reserved

-There is an import table in .idata at 0x10004000
+There is an import table in .idata at 0x69b46000

 The Import Tables (interpreted .idata section contents)
  vma:HintTime  Forward  DLL   First
  Table   Stamp ChainName  Thunk
- 4000  4040   4160 4078
+ 6000  6040   617c 607c

DLL Name: cygwin1.dll
vma:  Hint/Ord Member-Name Bound-To
-   40ac  351  _impure_ptr
-   40bc  720  calloc
-   40c8  779  cygwin_detach_dll
-   40dc  781  cygwin_internal
-   40f0  802  dll_dllcrt0
-   4100  917  free
-   4108 1183  malloc
-   4114 1282  pow
-   411c 1392  realloc
+   60b4  351  _impure_ptr
+   60c4  720  calloc
+   60d0  779  cygwin_detach_dll
+   60e4  781  cygwin_internal
+   60f8  802  dll_dllcrt0
+   6108  917  free
+   6110 1183  malloc
+   611c 1282  pow
+   6124 1392  realloc

- 4014  406c   4170 40a4
+ 6014  606c   6190 60a8

DLL Name: KERNEL32.dll
vma:  Hint/Ord Member-Name Bound-To
-   4128  337  GetModuleHandleA
+   6130  337  GetModuleHandleA
+   6144  364  GetProcAddress

- 4028      
+ 6028      


  As you see, they have sane-looking differences in the VMAs, and neither of
them imports cygwin1.dll twice.

> Again, I'm not sure where to go next.

  Might be worth trying a fresh build of binutils from CVS.  I've just
completed a build of zsh and it exhibits the problem, so I'll see if I can
figure out what's gone wrong.

  BTW to avoid confusion can everyone in this thread please remember to take
care and specify explicit version number suffixes on any examples they show
using gcc!

cheers,
  DaveK


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13

[Dave Korn]

Peter A. Castro wrote:

>   The offending symbol entries are the following (functions)
>   tgetent
>   tgetflag
>   tgetnum
>   tgetstr
>   tgoto
>   tputs
>   pow  (but this is not an unresolve symbol, see below)
> 
> 'pow' is not an unresolve symbol in this mess, but it is lumped into the
> chunk with the bad symbols.
> 
> libzsh-4.3.9.dll is 

... peculiarly named with no 'cyg' prefix.  I suspect something may have gone
bad in the libtoolification or whatever other procedure zsh uses to build this
dll.

> the one who needs these symbols, but the import list
> is wrong:

> And, here's the imports from compiling/linking with libncurses-9 (bad):

>  0009e03c   0009e398   0009f374 0009e6d0
> 
> DLL Name: cygwin1.dll
> vma:  Hint/Ord Member-Name Bound-To
> 9f0101285  pow
> 9f018 468  tgetent
> 9f024 469  tgetflag
> 9f030 470  tgetnum
> 9f03c 471  tgetstr
> 9f048 472  tgoto
> 9f050 480  tputs
> 
>  0009e050   0009e39c   0009f39c 0009e6d4
> 
> DLL Name: cygncurses-9.dll
> vma:  Hint/Ord Member-Name Bound-To
> 9f018 468  tgetent
> 9f024 469  tgetflag
> 9f030 470  tgetnum
> 9f03c 471  tgetstr
> 9f048 472  tgoto
> 9f050 480  tputs
> 
> It appears to trying to import the symbols twice.

  While it is not unusual to see multiple imports for the same symbols
(auto-import works by generating loads of mini-pseudo-IATs scattered through
the .text section at addresses coinciding with instruction operand fields that
need relocating), it's very wrong to see them listed under the wrong DLL name.

  BTW, I've now tried this with both old and latest CVS binutils, and it makes
no difference.

> I've checked the import libs for both 5.5-3 (good) 5.7-13 (bad) and they
> don't appear to have anything funny about them.  libncurses.a and
> libncurses.dll.a both appear to have the correct exports.  There's no
> difference in how zsh is compiled between ncurses 8 & 9.
> 
> Could this really be a linker problem?

  I don't know why exactly it's the problem yet, but I know a solution:

Here's the command from my build log that links libzsh dll:

i686-pc-cygwin-gcc  -s -shared -Wl,--export-all-symbols -o libzsh-4.3.9.dll
`cat stamp-modobjs` -lgdbm -L/usr/lib -lpcre -liconv -ldl -lncurses -lm  -lc


  I re-ran it with -v and got the following actual commandline passed to the
linker:

/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld --shared
-Bdynamic -e __cygwin_dll_en...@12 --enable-auto-image-base
--dll-search-prefix=cyg -o libzsh-4.3.9.dll -s
/usr/lib/gcc/i686-pc-cygwin/4.3.2/crtbegin.o -L/usr/lib
-L/usr/lib/gcc/i686-pc-cygwin/4.3.2 -L/usr/lib/gcc/i686-pc-cygwin/4.3.2
-L/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/lib
-L/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../.. --export-all-symbols builtin.o
compat.o cond.o exec.o glob.o hashtable.o hist.o init.o input.o jobs.o lex.o
linklist.o loop.o math.o mem.o module.o options.o params.o parse.o pattern.o
prompt.o signals.o signames.o sort.o string.o subst.o text.o utils.o watch.o
-lgdbm -lpcre -liconv -ldl -lncurses -lm -lc -v -lgcc_s -lcygwin -luser32
-lkernel32 -ladvapi32 -lshell32 -lgcc_s 
/usr/lib/gcc/i686-pc-cygwin/4.3.2/crtend.o


  Anyway, I found that removing "-lm -lc" from the options fixes the build
problem, and that it makes no difference what version of ld you use.  Remove
those two -l options and you get a good DLL, leave them in and you get a bad
one.  I don't know yet what effect these options have that does the damage,
but will look later.

  I then ran make install which went smoothly, and invoked zsh:

This is the Z Shell configuration function for new users,
zsh-newuser-install.
You are seeing this message because you have no zsh startup files
(the files .zshenv, .zprofile, .zshrc, .zlogin in the directory
~).  This function can help you with a few settings that should
make your use of the shell easier.

You can:

(q)  Quit and do nothing.  The function will be run again next time.

(0)  Exit, creating the file ~/.zshrc containing just a comment.
 That will prevent this function being run again.

(1)  Continue to the main menu.

--- Type one of the keys in parentheses ---


  So I conclude it's more or less working.  I do however get this warning:

$ zsh
zsh: failed to load module `zsh/zle': No such process
$P$G

  Also I tried a test suite run.  It got some way before one of the testcases
appeared to hang and I killed it:


cd Test ; make check
make[1]: Entering directory `/usr/src/zsh2/zsh-4.3.9/.build/Test'
if test -n "i686-pc-cygwin-gcc"; then \
  cd .. && DESTDIR= \
  make MODDIR=`pwd`/Test/Modules install.modules > /dev/null; \
fi
/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning:
auto-importing has been activated without --enable-auto-import specified 

Re: under cygwin, zsh cannot run when built against ncurses9-5.7-13

[Dave Korn]

Dave Korn wrote:

>   I'm now going to try building it again, from scratch, but with the LDFLAGS
> edited to a) remove "-lm -lc" and b) add "-Wl,--enable-auto-import".  Let's
> see if that improves things any.

  Right, works nicely.  Also I discovered about "make install.modules" in the
meantime, which helps, and now it just works:

$ zsh --login

(ad...@ubik)[1] ~
$ echo "Hello world from ZSH"
Hello world from ZSH

(ad...@ubik)[2] ~
$ exit

$ echo $?
0

  So, what I did was not suitable for upstream, but I'll leave you to work
that one out with them.  I ...

a) Deleted these lines from configure.ac and regnerated configure:

$ diff -pu zsh/zsh-4.3.9/configure.ac zsh3/zsh-4.3.9/configure.ac
--- zsh/zsh-4.3.9/configure.ac  2008-10-30 13:04:44.0 +
+++ zsh3/zsh-4.3.9/configure.ac 2009-03-17 03:39:19.21875 +
@@ -642,9 +642,10 @@ dnl in case they require objects that ex
 dnl and might not be compiled into the zsh executable.
 dnl On ReliantUNIX -lc better be the last library, else funny things
 dnl may happen.
-AC_CHECK_LIB(c, printf, [LIBS="$LIBS -lc"])
-
-AC_CHECK_LIB(m, pow)
+dnl On cygwin this is a no-no
+dnl AC_CHECK_LIB(c, printf, [LIBS="$LIBS -lc"])
+dnl
+dnl AC_CHECK_LIB(m, pow)

 dnl Various features of ncurses depend on having the right header
 dnl (the system's own curses.h may well not be good enough).

$

b)  Modified the build script to enable auto import.

$ diff -pu zsh/zsh-4.3.9-1.sh zsh3/zsh-4.3.9-1.sh
--- zsh/zsh-4.3.9-1.sh  2009-03-17 02:22:13.87500 +
+++ zsh3/zsh-4.3.9-1.sh 2009-03-17 03:45:06.828125000 +
@@ -105,6 +105,7 @@ conf() {
   --enable-multibyte \
   --with-curses-terminfo \
   --with-install-prefix=${instdir} \
+  --enable-ldflags=-Wl,--enable-auto-import \
   ${ZSHCONFDEBUG} )
 }
 build() {

$

  Everything built and runs ok, and the testsuite reports:

/usr/src/zsh3/zsh-4.3.9/Test/C02cond.ztst: starting.
Warning: Not testing [[ -b blockdevice ]] (no devices found)
Warning: Not testing [[ -f blockdevice ]] (no devices found)
Warning: Not testing [[ -p pipe ]] (FIFOs not supported)
Test /usr/src/zsh/zsh-4.3.9/Test/C02cond.ztst failed: bad status 1, expected 0
from:
  if (( EUID == 0 )); then
print -u$ZTST_fd 'Warning: Not testing [[ ! -r file ]] (root reads anything)
'
[[ -r zerolength && -r unmodish ]]
  else
[[ -r zerolength && ! -r unmodish ]]
  fi
Was testing: -r cond
/usr/src/zsh3/zsh-4.3.9/Test/C02cond.ztst: test failed.

/usr/src/zsh3/zsh-4.3.9/Test/V01zmodload.ztst: starting.
*** /tmp/zsh.ztst.err.1400  Tue Mar 17 04:01:22 2009
--- /tmp/zsh.ztst.terr.1400 Tue Mar 17 04:01:23 2009
***
*** 0 
--- 1,2 
+ (eval):3: failed to load module `zsh/net/tcp': No such process
+ (eval):3: failed to load module `zsh/net/tcp': No such process
Test /usr/src/zsh3/zsh-4.3.9/Test/V01zmodload.ztst failed: error output differs
from expected as shown above for:
 for m in $mods
 do
   zmodload -i $m || mods[(r)$m]=()
 done
Was testing: Test loading of all compiled modules
/usr/src/zsh3/zsh-4.3.9/Test/V01zmodload.ztst: test failed.

**
34 successful test scripts, 2 failures, 1 skipped
**




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: peflags utility

[Charles Wilson]

Charles Wilson wrote:

> If this is more-or-less ok, I'll get started on the peflagsall script,
> and send it all with updated docu as a patch for Jason to use in the
> next rebase release.

Incorporating Corinna's patch, with a peflagsall script and updated
documentation and Makefile patches. I even used it on my entire
installation with no ill effects.

Jason?  (I arbitrarily bumped the version number to 2.9.8, but whatever
you choose is fine).

--
Chuck


rebase-2.4.4-1.20090316.patch.gz
Description: application/gzip
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Not a cygport problem [Was: Re: Problem with 575 man pages -- cygport problem?]

[Charles Wilson]

Chris Sutcliffe wrote:
> Minor tweak to the proposed shell script fix to make it work.  This:
> 
>> xargs file | grep 'ASCII troff' | awk -F: '{print $1}' |\
> 
> Should be this:
> 
>> xargs file | grep 'ASCII text' | awk -F: '{print $1}' |\

It depends on which version of 'file' you are using. On cygwin-1.7, the
current version of file:

$ file -version
file-5.00

reports ASCII text.

On cygwin-1.5, the current version of file

$ file -version
file-4.21

reports ASCII troff.

--
Chuck


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin/x and windows windowsg

[Mojmir Svoboda]

* Larry Hall (Cygwin)  [2009-03-16 12:32:25 
-0400]:

> Wrong list.  If you read the description of the lists at

sorry

m.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/