Re: g++-3 and g77-3 packages under setup-x86.exe

Dima Pasechnik wrote: On 20 August 2013 03:13, LMH wrote: I would be happy to build gcc-3 myself, I'm just looking for some documentation to get that done. The fact the gcc-3/g77 are old means nothing to me. There are still millions of lines of fortran77 code out there that are being used. The

shared object file not found with `git submodule update --init --recursive` in Cygwin 64-bit

Hello, Running `git submodule update --init --recursive` in my repository results in an error loading shared libraries. However, the git submodule update seems to proceed nevertheless, so I'm not sure what this error would actually break: $ git submodule update --init --recursive /usr/lib/

Re: g++-3 and g77-3 packages under setup-x86.exe

On 20 August 2013 03:13, LMH wrote: > I would be happy to build gcc-3 myself, I'm just looking for some > documentation to get that done. > > The fact the gcc-3/g77 are old means nothing to me. There are still millions > of lines of fortran77 code out there that are being used. There is just no >

Re: g++-3 and g77-3 packages under setup-x86.exe

On Mon, Aug 19, 2013 at 06:43:39PM -0400, LMH wrote: >Thanks for the information. I am tying to get the packages using the >Time Machine, but all I am getting is an error, "unable to get >setup.ini" from the different ftp addresses I have tried. I sent an >email to the link at the bottom of the

Re: g++-3 and g77-3 packages under setup-x86.exe

Thanks for the information. I am tying to get the packages using the Time Machine, but all I am getting is an error, "unable to get setup.ini" from the different ftp addresses I have tried. I sent an email to the link at the bottom of the page, so hopefully they will be able to help me with tha

Re: cygwin emacs 24.3 fci bug

On 8/19/2013 3:46 PM, Matt D. wrote: The current build of emacs has a bug in the redisplay engine and can be seen when using the fill-column-indicator script. I just rebuilt cygwin emacs from source and can confirm that the patch mentioned in the following link does correct the problem: https:/

Re: Makefile for emacs throws an error when username contains spaces

On 8/19/2013 3:33 PM, Matt D. wrote: I experienced the following error while running "make install" for cygwin emacs: chown: invalid user: `Matthew' I corrected the problem by encapsulating the following variables in quotes within Makefile and Makefile.in: $${USERNAME} $${USER} $${installuser}

Re: mt and tar fail on LTO-5 drives

On 8/19/2013 3:53 PM, bartels wrote: On 08/19/2013 08:44 PM, Guy Harrison wrote: Thanks Guy, but these troubles are only seen with tar / mt. Both drives work fine with LTFS. I know I am grasping at straws, but I wonder if manually setting the tape length with tar's --tape-length option would

Re: g++-3 and g77-3 packages under setup-x86.exe

On 8/19/2013 3:13 PM, LMH wrote: I would be happy to build gcc-3 myself, I'm just looking for some documentation to get that done. I don't have a direct pointer for you but I'm sure you can find something while looking around the net. gcc.gnu.org might be the best place to get some basic info

Re: mt and tar fail on LTO-5 drives

On 08/19/2013 08:44 PM, Guy Harrison wrote: This *might* be useful.. http://www-01.ibm.com/support/docview.wss?uid=swg21393009 ..particularly.. http://www-01.ibm.com/software/sysmgmt/products/support/IBM_TSM_Supported_Devices_for_AIXHPSUNWIN.html Please bear in mind the page is for TSM (Tivoli S

cygwin emacs 24.3 fci bug

The current build of emacs has a bug in the redisplay engine and can be seen when using the fill-column-indicator script. I just rebuilt cygwin emacs from source and can confirm that the patch mentioned in the following link does correct the problem: https://github.com/alpaker/Fill-Column-Ind

Makefile for emacs throws an error when username contains spaces

I experienced the following error while running "make install" for cygwin emacs: chown: invalid user: `Matthew' I corrected the problem by encapsulating the following variables in quotes within Makefile and Makefile.in: $${USERNAME} $${USER} $${installuser} Matt D. -- Problem reports:

Re: g++-3 and g77-3 packages under setup-x86.exe

I would be happy to build gcc-3 myself, I'm just looking for some documentation to get that done. The fact the gcc-3/g77 are old means nothing to me. There are still millions of lines of fortran77 code out there that are being used. There is just no reason to spend years of man hours to update

Re: mt and tar fail on LTO-5 drives

On 08/19/2013 07:12 PM, Corinna Vinschen wrote: It would be interesting to see the OS error codes. If you run tar under strace, the trace output should contain a line like [...] write: Win32 error or [...] close: Win32 error The value of is what I'm curious about. Her

Re: g++-3 and g77-3 packages under setup-x86.exe

On 8/19/2013 1:27 PM, LMH wrote: I recently tried to update my cygwin install and discovered I had to change to the setup-x86.exe package for the update to work. After finishing the update, I see that some binaries have been removed from my install. Which g++-3 and which g77-3 now return no findi

Re: mt and tar fail on LTO-5 drives

On Monday 19 August 2013 17:40:31 bartels wrote: > On 08/19/2013 06:31 PM, Eliot Moss wrote: > > First of all, it's not clear to me whether it is a Microsoft problem > > or a device driver problem. I would see what's known about the > > behavior of the devices and their drivers with the specific W

Re: mt and tar fail on LTO-5 drives

On 08/19/2013 07:06 PM, Eliot Moss wrote: Not so much, yet. Presumably HP and IBM offer some kind of backup utility with the drive software, Sure: both drives work fine using LTFS. Plenty of bytes there. No problem at all. - Bartels. -- Problem reports: http://cygwin.com/problems.htm

Re: mt and tar fail on LTO-5 drives

On 08/19/2013 07:12 PM, Corinna Vinschen wrote: To be really sure, you could add debug output to Cygwin's mtinfo_drive::get_mp function and rebuild the DLL: diff -u -p -r1.90 fhandler_tape.cc Gladly. I would like to close this one way or the other. Which package and which dll are you talking

g++-3 and g77-3 packages under setup-x86.exe

I recently tried to update my cygwin install and discovered I had to change to the setup-x86.exe package for the update to work. After finishing the update, I see that some binaries have been removed from my install. Which g++-3 and which g77-3 now return no findings and those compilers appear

Re: mt and tar fail on LTO-5 drives

On 8/19/2013 1:13 PM, Corinna Vinschen wrote: On Aug 19 18:40, bartels wrote: On 08/19/2013 06:31 PM, Eliot Moss wrote: In theory, typical SCSI/SAS tapes should use the default tape.sys driver, IIRC. There's nothing special with them, using standard SCSI/SAS commands. Thank you, Corinna; i

Re: mt and tar fail on LTO-5 drives

On Aug 19 18:40, bartels wrote: > On 08/19/2013 06:31 PM, Eliot Moss wrote: > > > >First of all, it's not clear to me whether it is a Microsoft problem > >or a device driver problem. I would see what's known about the behavior > >of the devices and their drivers with the specific Windows version y

Re: mt and tar fail on LTO-5 drives

On Aug 19 18:21, bartels wrote: > On 08/19/2013 12:19 PM, Corinna Vinschen wrote: > >On Aug 17 20:35, bartels wrote: > >>Hello People, > >> > >>I have here two SAS connected LTO-5 drives: one IBM and one HP. > >> > >>Both drives work work fine, but sadly mt does not. > >>The size reported by mt is

Re: mt and tar fail on LTO-5 drives

On 8/19/2013 12:40 PM, bartels wrote: On 08/19/2013 06:31 PM, Eliot Moss wrote: First of all, it's not clear to me whether it is a Microsoft problem or a device driver problem. I would see what's known about the behavior of the devices and their drivers with the specific Windows version you ha

[ANNOUNCEMENT] New Package: git-review-1.23-1

git-review has been added to Cygwin. More details about git-review can be found at https://pypi.python.org/pypi/git-review. DESCRIPTION: git-review is a tool that helps submitting git branches to gerrit for review. DOWNLOAD: = Note that downloads from sources.redhat.com (aka

Re: mt and tar fail on LTO-5 drives

On 08/19/2013 06:31 PM, Eliot Moss wrote: First of all, it's not clear to me whether it is a Microsoft problem or a device driver problem. I would see what's known about the behavior of the devices and their drivers with the specific Windows version you have. Of course it could be that other t

[ANNOUNCEMENT] Updated: scons-2.3.0-3

CYGWIN NEWS: This release includes additional fixes for the Cygwin-specific linking tool including fixes when no_import_lib=1 is defined and fixes for versioned shared libraries. DESCRIPTION: SCons is an Open Source software construction tool—that is, a next-generation bu

[ANNOUNCEMENT] Updated: whois-5.0.26-1

The whois package has been updated to the latest upstream release 5.0.26. The change log can be found here: https://raw.github.com/rfc1036/whois/master/debian/changelog More information about whois can be found at https://github.com/rfc1036/whois DESCRIPTION: whois searches for an

Re: mt and tar fail on LTO-5 drives

On 8/19/2013 12:21 PM, bartels wrote: On 08/19/2013 12:19 PM, Corinna Vinschen wrote: On Aug 17 20:35, bartels wrote: Hello People, I have here two SAS connected LTO-5 drives: one IBM and one HP. Both drives work work fine, but sadly mt does not. The size reported by mt is a meager 35 GB, ins

Re: mt and tar fail on LTO-5 drives

On 08/19/2013 12:19 PM, Corinna Vinschen wrote: On Aug 17 20:35, bartels wrote: Hello People, I have here two SAS connected LTO-5 drives: one IBM and one HP. Both drives work work fine, but sadly mt does not. The size reported by mt is a meager 35 GB, instead of the expected 1.5TB I have trie

Re: Mintty command line for old time rxvt users

On 19 August 2013 08:23, Keith Starsmeare wrote: > But I've got a question regarding the command line options. I used to have a > bunch of shortcuts to start an rxvt to ssh to my remote servers but it took > some trial and error to get it working so that it is (briefly) a login shell > to get my ss

Re: Trying to solve my cygheap base mismatch issue

On 8/19/2013 8:18 AM, Tony Whyte wrote: Hi All, One morning last week, after 11 months of flawless cygwin-ing, I was suddenly unable to create a cygwin terminal on my Windows XP (SP3) installation. The window would launch and then quickly close. Ive dug through the mail Archives and attempted

Re: cygwin sshd dumping stack trace when not allocating pseudo-tty

On 8/19/2013 7:58 AM, Thorsten Glaser wrote: We have a problem with a Cygwin SSHD installation: normal logins work fine and use domain logins: Connections that do not use a pseudo-tty do not work: We need your cygcheck output and to understand the method you're using to login. See

cygwin sshd dumping stack trace when not allocating pseudo-tty

Hi everyone, please keep the both of us in Cc as we’re not subscribed. We have a problem with a Cygwin SSHD installation: normal logins work fine and use domain logins: tglase@tglase:~ $ ssh cygbox Last login: Mon Aug 19 13:50:59 2013 from tglase.lan.tarent.de tglase@cygbox:~$ fgrep tglase /etc/

Re: Stack size on 64-bit Cygwin

On Aug 19 14:36, Corinna Vinschen wrote: > On Aug 19 07:43, Ryan Johnson wrote: > > On 19/08/2013 7:39 AM, Corinna Vinschen wrote: > > >On Aug 19 07:04, Ryan Johnson wrote: > > >>So maybe emacs just had the incredibly bad luck to alloca() a large > > >>buffer right at end-of-stack and then somehow

Re: Stack size on 64-bit Cygwin

On Aug 19 07:43, Ryan Johnson wrote: > On 19/08/2013 7:39 AM, Corinna Vinschen wrote: > >On Aug 19 07:04, Ryan Johnson wrote: > >>On 19/08/2013 6:49 AM, Ryan Johnson wrote: > >>>One thing I don't understand, though: shouldn't a stack overflow > >>>normally manifest as a seg fault when trying to acc

Mintty command line for old time rxvt users

I've been using rxvt with Cygwin for years and I must thank Chuck Wilson and anyone else that's helped maintain it and the Cygwin as a whole! I've recently been having trouble with my locales accessing Linux servers through ssh - gcc errors were coming out with horrible characters, and I'm sure I

Re: Stack size on 64-bit Cygwin

On 19/08/2013 7:39 AM, Corinna Vinschen wrote: On Aug 19 07:04, Ryan Johnson wrote: On 19/08/2013 6:49 AM, Ryan Johnson wrote: One thing I don't understand, though: shouldn't a stack overflow normally manifest as a seg fault when trying to access the invalid addresses, rather than silent memory

Re: Stack size on 64-bit Cygwin

On Aug 19 07:04, Ryan Johnson wrote: > On 19/08/2013 6:49 AM, Ryan Johnson wrote: > >One thing I don't understand, though: shouldn't a stack overflow > >normally manifest as a seg fault when trying to access the invalid > >addresses, rather than silent memory corruption? That would be helpful. >

Re: Stack size on 64-bit Cygwin

On 19/08/2013 6:49 AM, Ryan Johnson wrote: On 19/08/2013 5:32 AM, Corinna Vinschen wrote: On Aug 16 16:49, Ken Brown wrote: The problem that has been discussed at length in the thread "64-bit emacs crashes a lot" appears to have been solved on the emacs-devel list. (I say "appears to" because

Re: Stack size on 64-bit Cygwin

On 19/08/2013 5:32 AM, Corinna Vinschen wrote: On Aug 16 16:49, Ken Brown wrote: The problem that has been discussed at length in the thread "64-bit emacs crashes a lot" appears to have been solved on the emacs-devel list. (I say "appears to" because I'm waiting for Ryan to confirm this.) The

Re: Stack size on 64-bit Cygwin

On 8/19/2013 5:32 AM, Corinna Vinschen wrote: On Aug 16 16:49, Ken Brown wrote: The problem that has been discussed at length in the thread "64-bit emacs crashes a lot" appears to have been solved on the emacs-devel list. (I say "appears to" because I'm waiting for Ryan to confirm this.) The p

Re: mt and tar fail on LTO-5 drives

On Aug 17 20:35, bartels wrote: > Hello People, > > I have here two SAS connected LTO-5 drives: one IBM and one HP. > > Both drives work work fine, but sadly mt does not. > The size reported by mt is a meager 35 GB, instead of the expected 1.5TB > > I have tried both an older 32 bit and the 'cur

Re: Stack size on 64-bit Cygwin

On Aug 16 16:49, Ken Brown wrote: > The problem that has been discussed at length in the thread "64-bit > emacs crashes a lot" appears to have been solved on the emacs-devel > list. (I say "appears to" because I'm waiting for Ryan to confirm > this.) The problem went away for me when I built emac

Re: binutils feature request: ld --disable-large-address-aware [PATCH]

Hi Christian, On Aug 17 18:36, Christian Franke wrote: > Christian Franke wrote: > >A few programs are not compatible with --large-address-aware which > >is enabled by default in current x86 ld. For example cdrkit, > >dvd+rw-tools and smartmontools use IOCTL_SCSI_PASS_THROUGH_DIRECT > >which appar

[ANNOUNCEMENT] Updated: serf-1.3.1-1

The serf packages have been updated to the new upstream release 1.3.1. See http://serf.googlecode.com/svn/tags/1.3.1/CHANGES for more details about the changes in this release. More information about serf can be found at http://code.google.com/p/serf/. DESCRIPTION: The serf libra