-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Due to the complaints about .exe magic in rm (it broke libtool, and
doesn't work properly on some symlinks), I have reverted just that patch
to coreutils as a quick fix. I am still interested in writing a more
comprehensive patch that makes .exe
There has been a new release of the official cmake (2.0.6-1).
This is a minor release from to 2.0.5 to 2.0.6.
Here are the required files:
ftp://www.cmake.org/pub/cmake/cygwin/setup.hint
ftp://www.cmake.org/pub/cmake/cygwin/cmake-2.0.6-1.tar.bz2
Hans W. Horn wrote:
Hi Max,
Max Bowsher wrote:
One further suggestion: I think it would be appropriate to include
only the html version of the manual. Including the PDF format too
substantially increases the size of the package, for no real gain -
it's just duplication.
Actually, I just noticed
Max,
I found the origin of the mysterious rendering problem I'd referred to.
My computer is missing a font specified in doxygen.css:
.fragment {
font-family: Fixed, monospace;
font-size: 95%;
}
The doxygen pdf manual will go, as soon as I have found that friggen font
somewhere!
H.
Max
Hans W. Horn wrote:
Max,
I found the origin of the mysterious rendering problem I'd referred to.
My computer is missing a font specified in doxygen.css:
.fragment {
font-family: Fixed, monospace;
font-size: 95%;
}
The doxygen pdf manual will go, as soon as I have found that friggen font
CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: [EMAIL PROTECTED] 2005-04-14 17:08:03
Modified files:
cygwin : fork.cc
Log message:
.
Patches:
CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: [EMAIL PROTECTED] 2005-04-14 17:34:04
Modified files:
cygwin : ChangeLog cygwin.din dcrt0.cc dll_init.cc
dll_init.h exceptions.cc fhandler_disk_file.cc
I can see why would one think this is a bug, but it was meant
to be that way. Having a wrong gid can make seteuid fail.
Perhaps we could print the new and current uids and the current
gid to cover all cases.
Pierre
At 01:59 PM 4/14/2005 +0900, Kazuhiro Fujieda wrote:
I'd submit a trivial patch
Kees Vonk wrote:
Okay, the .la is just the libtool version of an .a file. That's all
fine and good.
gcc -I./.. -I.. -Wall -g -O2makedatprog.c -o makedatprog
This is your problem. make is invoking an implicit rule for
makedatprog, rather than the one specified by the Makefile which
Hi Eric,
* Eric Blake wrote on Wed, Apr 13, 2005 at 03:24:15PM CEST:
According to Ralf Wildenhues on 4/13/2005 1:17 AM:
Hmm. Here you talk about the superficial symmetry in mv/cp vs rm..
Only rm was given new .exe magic. cygwin mv and cp have had them for
several years, before
* Robert Ögren wrote on Wed, Apr 13, 2005 at 11:44:20PM CEST:
I'll attach a patch for the Libtool-1.5.14 sources that does this. So
far I've only tested it by running the Libtool testsuite, but if you
want I can run more tests. I can also test the change on the Libtool CVS
HEAD branch if
On Apr 13 16:54, Rob Siklos wrote:
Hi all,
I'm trying to port an app from linux to Cygwin, and it's choking when
trying to link to the pcre library.
When I compile (with gcc -lpcre rob.c), I get the message:
/c/DOCUME~1/rsiklos/LOCALS~1/Temp/cc7QPrgq.o(.text+0x44):rob.c: undefined
On Apr 13 18:47, Loh, Joe wrote:
Output from dd:
$ dd if=.\\physicaldrive1 ibs=1024 skip=1610612600 count=10 | od -x
So you're using the Windows filename instead of the POSIX filename
which Cygwin provides? Too bad.
I suggest reading the appropriate chapter in the Cygwin user guide
Process substitution in bash is not working for me currently. I'm pretty
certain it worked at some point in the past (maybe about 6 months ago).
For example:
$ cat ( echo hello)
hangs, ignoring ^C, kill -9, and requiring kill -f on the cat
process.
Reading the bash manual, it seems bash can
Rainer Kirsch wrote:
Since cygwin 1.5.13 apache (which is available via setup) is not running
on my winXP SP2 computer.
You're going to have to be a lot more specific than is not running.
Such as...
... how you're trying to run it (as a service is the preferred way)
... how you installed the
Hi,
I'm not sure what happened, but if I start Cygwin for a certain
restricted user I receive the following message:
9 [main] bash 3624 fork_parent: child 2756 died waiting for
longjmp before initialization
bash: fork: Bad file descriptor
bash-2.05b$
Everything worked fine, nothing was
On 13 Apr 2005, at 11:29 pm, Larry Hall wrote:
At 04:29 PM 4/13/2005, you wrote:
I'm experimenting with using cygwin on my Macintosh PowerBook (running
OS X 10.3.8) within Virtual PC 7.0.1. My aim is to be able to
continue
developing the Windows port of our research software (EDEN).
Cygwin
I looked and this doesn't seem to have been mentioned in the archives.
You can cd to any random subdirectory of a directory in the /proc
filesystem, irrespective of whether it exists. Examples:
$ cd /proc/banana
$ ls
ls: .: Not a directory
$ cd /proc/self/banana
$ ls
ls: .: Not a directory
$ cd
Hi,
We use clock_gettime and clock_settime. We now get an undefined reference
when linking on clock_settime, clock_gettime doesn't give any problems.
Someone an idea?
Johnny
Creating library file: libACE.dll.a
.shobj/OS_NS_time.o(.text+0x95): In function
Ashley Ward wrote:
Because of these issues, my preferred solution would be to use Shared
Folders -- if it worked, it'd be a lot simpler than Samba -- no
separate server and configuration to worry about. I might try
following up the issue with MS VPC support in the newsgroup and then
Original Message
From: Lev S Bishop
Sent: 14 April 2005 11:19
I looked and this doesn't seem to have been mentioned in the archives.
You can cd to any random subdirectory of a directory in the /proc
filesystem, irrespective of whether it exists. Examples:
$ cd /proc/banana
$ ls
Original Message
From: Johnny Willemsen
Sent: 14 April 2005 11:54
Hi,
We use clock_gettime and clock_settime. We now get an undefined reference
when linking on clock_settime, clock_gettime doesn't give any problems.
Someone an idea?
There is no clock_settime in cygwin. Never
There's an interesting interaction with the recent changes to coreutils
here, too:
$ ln -s /proc/banana ooo
$ rm ooo
rm: cannot lstat `ooo.exe': No such file or directory
Who said anything about ooo.exe, just delete ooo :-)
Lev
--
Unsubscribe info:
[Disclaimer: Yes, I did STFW. 'tab completion dll site:cygwin.com' just
brings up every post there's ever been about tab completion, because 'dll'
occurs in just about every post there's ever been on any subject on this
list!]
Does anyone know why tab-completion doesn't work for .dll
Original Message
From: beau
Sent: 13 April 2005 20:43
http://www.google.com/search?hl=enq=dave+korn+kshbtnG=Google+Search
You can imagine my confusion after a quick look at this result. I was
beginning to feel guilty about switching to bash when I log onto
freeshell.
Imagine how
On Apr 14 12:16, Dave Korn wrote:
[Disclaimer: Yes, I did STFW. 'tab completion dll site:cygwin.com' just
brings up every post there's ever been about tab completion, because 'dll'
occurs in just about every post there's ever been on any subject on this
list!]
Does anyone know
Dave Korn wrote:
Does anyone know why tab-completion doesn't work for .dll files? I don't
Weird. WJFFM:
$ cd /usr/bin
$ ls cyg[TAB]
Display all 166 possibilities? (y or n)
$ ls cygw[TAB]
cygWand-6.dll*cygwin1-1.5.14.dll* cygwin1-20050402.dll*
cygwin1-20050408.dll*
On Apr 14 10:54, Ashley Ward wrote:
2) The '\' character used in Windows share names is an escape character
to bash -- so the example mount \\pollux\home\joe\data /data in the
cygwin manual (example 3.10) is misleading. For me, that style of
example gives error messages about /data, not
On Apr 14 06:18, Lev S Bishop wrote:
I looked and this doesn't seem to have been mentioned in the archives.
You can cd to any random subdirectory of a directory in the /proc
filesystem, irrespective of whether it exists. Examples:
$ cd /proc/banana
$ ls
ls: .: Not a directory
$ cd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Lev S Bishop on 4/14/2005 5:16 AM:
There's an interesting interaction with the recent changes to coreutils
here, too:
$ ln -s /proc/banana ooo
$ rm ooo
rm: cannot lstat `ooo.exe': No such file or directory
Shoot - yet one more
I got a big problem, I just reinstalled by error coreutils, and I upgraded
to the
latest setup.exe.
Now, my installer keeps hanging when installing, not at the end of the
installation,
but at the end of the package installation.
We have Norton antivirus, I hope that is not the problem, because
I tried building bash from the source package, and then it uses either
/dev/fd (if I have that as a symlink) or /proc/self/fd (if I don't),
rather than the fifo that the binary package uses. So perhaps whoever
built the binary package didn't have /proc/self/fd for whatever reason?
With my built
The problem was that I get pointer problems with the new utilities.
I will try to upgrade cygwin1.dll too.
Jurgen
Jurgen Defurne [EMAIL PROTECTED]
Sent by:
[EMAIL PROTECTED]
2005-04-14 01:53 PM
To: cygwin@cygwin.com
cc: (bcc: Jurgen Defurne/BRG/CE/PHILIPS)
/cygwin1-1.5.11.dll /bin/cygwin1-20050404.dll
/bin/cygwin1-20040103.dll/bin/cygwin1-20050414.dll
/bin/cygwin1-20040719.dll/bin/cygwin1-clip-debug.dll
/bin/cygwin1-20041201.dll/bin/cygwin1.dll
/bin/cygwin1-20050228.dll/bin/cygwin1.dll.current
/bin/cygwin1-20050302
On 14 Apr 2005, at 12:33 pm, Corinna Vinschen wrote:
On Apr 14 10:54, Ashley Ward wrote:
2) The '\' character used in Windows share names is an escape
character
to bash -- so the example mount \\pollux\home\joe\data /data in the
cygwin manual (example 3.10) is misleading. For me, that style of
Original Message
From: Ashley Ward
Sent: 14 April 2005 13:11
Perhaps I'm not being clear enough. I'm suggesting changing example
3.10 in the manual from
mount \\pollux\home\joe\data /data
to
mount '\\pollux\home\joe\data' /data
Pay closer attention to the prompt in that
Original Message
From: Dave Korn
Sent: 14 April 2005 13:17
Original Message
From: Ashley Ward
Sent: 14 April 2005 13:11
Perhaps I'm not being clear enough. I'm suggesting changing example
3.10 in the manual from
mount \\pollux\home\joe\data /data
to
mount
On 14 Apr 2005, at 12:02 pm, Brian Dessent wrote:
Ashley Ward wrote:
Because of these issues, my preferred solution would be to use Shared
Folders -- if it worked, it'd be a lot simpler than Samba -- no
separate server and configuration to worry about. I might try
following up the issue with MS
Lev S Bishop wrote:
rather than the fifo that the binary package uses. So perhaps whoever
built the binary package didn't have /proc/self/fd for whatever reason?
If I'm not mistaken /proc/pid/fd capabilty was added 2005-02-01. The
current bash package (2.05b-16) was released 2003-10-23. (the
Ashley Ward wrote:
I was a bit confused about it, though -- can such a setup *link* a
final binary as well as compile? Presumably then all the necessary
libraries from each platform need to be available on the build
platform?
You can link the final binary as long as you have import
Brian Dessent wrote:
If I'm not mistaken /proc/pid/fd capabilty was added 2005-02-01. The
current bash package (2.05b-16) was released 2003-10-23. (the test
version -17 was released 2004-11-22.) So it was quite impossible for
the person who built bash to have that feature.
Thanks for this
I still have the following problems :
- The installation of cygwin1.dll keeps hanging at 78 %
-- Probably because the installation is not complete,
i cannot get access to my D: drive (which is just a second drive),
but I can get access to my C: drive and to my network drives.
ANy hints ?
Jurgen
On Apr 14 08:04, Lev S Bishop wrote:
I tried building bash from the source package, and then it uses either
/dev/fd (if I have that as a symlink) or /proc/self/fd (if I don't),
rather than the fifo that the binary package uses. So perhaps whoever
built the binary package didn't have
Brian Dessent wrote:
You can link the final binary as long as you have import libraries. As
far as I know, you don't need the actual libraries themselves since
Well, okay, you need a little more than that, such as crt0.o. Basically
take the contents of usr/include and usr/lib from the
Corina wrote:
In the Linux kernel there's some magic
going on which we can't reproduce in Cygwin so far. Trying to open
an existing pipe for writing or reading opens apparently exactly the
right end of the pipe under Linux. On Windows, you only get the exact
end of the pipe which is already
On Thu, 14 Apr 2005, Lev S Bishop wrote:
Corina wrote:
^^
Sorry, Corinna.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
Original Message
From: Jurgen Defurne
Sent: 14 April 2005 13:38
I still have the following problems :
- The installation of cygwin1.dll keeps hanging at 78 %
-- Probably because the installation is not complete,
i cannot get access to my D: drive (which is just a second drive),
but
Hi,
I seem to have hit the same issue as described in:
http://sourceware.org/ml/cygwin/2005-03/msg00919.html
No resolution was offered there...
Cygwin works fine locally and (via terminal serve) on a variety of other
machines running Win 2000 and XP. However, when
I terminal serve to a
On Thu, Apr 14, 2005 at 02:38:25PM +0200, Jurgen Defurne wrote:
I still have the following problems :
- The installation of cygwin1.dll keeps hanging at 78 %
-- Probably because the installation is not complete,
i cannot get access to my D: drive (which is just a second drive),
but I can get
Hi,
I'm having this problem as well. Specifically, I'm getting the following
errors for non-privileged users logging in via Remote Desktop to Windows
Server 2003:
When I click on the Cygwin Icon:
2 [main] bash 6544 fork_parent: child 5496 died waiting for longjmp
before initialization
Dear all,
When I recently upgraded various cygwin components,
including tetex, several things have gone wrong. I am
baffled as cygwin is running fine on my home machine,
which is very similar (but has local accounts and not
networked accounts).
After much tweaking (see below), my status is that
Cygwin currently has sighold(), but not its counterpart sigrelse().
I believe it's implementation should be mainly a matter of copy/pasting:
In exceptions.cc, copy/paste sighold(), s/sighold/sigrelse/,
s/sigaddset/sigdelset/
In include/cygwin/signal.h and cygwin.din, copy/paste the sighold line,
Christopher,
That was the latest version from the URL you gave me.
Jurgen
Christopher Faylor [EMAIL PROTECTED]
Sent by:
[EMAIL PROTECTED]
2005-04-14 03:57 PM
Please respond to cygwin
To: cygwin@cygwin.com
cc: (bcc: Jurgen Defurne/BRG/CE/PHILIPS)
On 14 Apr 2005, at 1:17 pm, Dave Korn wrote:
From: Ashley Ward
Sent: 14 April 2005 13:11
Perhaps I'm not being clear enough. I'm suggesting changing example
3.10 in the manual from
mount \\pollux\home\joe\data /data
to
mount '\\pollux\home\joe\data' /data
Pay closer attention to the
On Thu, Apr 14, 2005 at 05:12:40PM +0200, Jurgen Defurne wrote:
That was the latest version from the URL you gave me.
I don't know what this means. What is the version that you are running?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Original Message
From: d j
Sent: 14 April 2005 16:03
When I recently upgraded various cygwin components,
including tetex, several things have gone wrong. I am
baffled as cygwin is running fine on my home machine,
which is very similar (but has local accounts and not
networked
Original Message
From: Christopher Faylor
Sent: 14 April 2005 16:30
On Thu, Apr 14, 2005 at 05:12:40PM +0200, Jurgen Defurne wrote:
That was the latest version from the URL you gave me.
I don't know what this means.
I reckon it means that it was the latest version, from the URL
On Thu, Apr 14, 2005 at 04:40:27PM +0100, Dave Korn wrote:
Original Message
From: Christopher Faylor
Sent: 14 April 2005 16:30
On Thu, Apr 14, 2005 at 05:12:40PM +0200, Jurgen Defurne wrote:
That was the latest version from the URL you gave me.
I don't know what this means.
I reckon it
Coreutils testsuite found another bug, this time in rename(2), as tested on the
20050412 snapshot:
$ cd /cygdrive/c # local NTFS drive
$ mknod fifo p
$ ls -lF fifo
prw-rw-rw- 1 eblake Domain Users 102 Apr 14 09:27 fifo|
$ mv fifo /cygdrive/u # remote NFS drive
$ ls -lF /cygdrive/u/fifo
I'm not sure what happened, but if I start Cygwin for a certain
restricted user I receive the following message:
9 [main] bash 3624 fork_parent: child 2756 died waiting for
longjmp before initialization
bash: fork: Bad file descriptor
bash-2.05b$
Everything worked fine, nothing
Nathan Potter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Hi,
I'm having this problem as well. Specifically, I'm getting the following
errors for non-privileged users logging in via Remote Desktop to Windows
Server 2003:
When I click on the Cygwin Icon:
2 [main] bash
Nathan Potter wrote in message news:[EMAIL PROTECTED]
Hi,
I'm having this problem as well. Specifically, I'm getting the following
errors for non-privileged users logging in via Remote Desktop to Windows
Server 2003:
When I click on the Cygwin Icon:
2 [main] bash 6544 fork_parent:
Original Message
From: Oliver Vecernik
Sent: 14 April 2005 10:41
Hi,
I'm not sure what happened, but if I start Cygwin for a certain
restricted user I receive the following message:
9 [main] bash 3624 fork_parent: child 2756 died waiting for
longjmp before initialization
I have an rsync being spawned from an external application nightly, and it seems
to always freeze on ssh:
2005-04-14 00:03:10: Running rsync -e ssh -vvv -o PasswordAuthentication=no
--exclude-from=d:\AlohaQS\backups\RSYNC.ex -az /cygdrive/d/AlohaQS/20050413
/cygdrive/d/AlohaQS/200504* [EMAIL
Attached is a very simple makefile which demonstrates the problem.
There's a leak either in make itself or in the spawning of
subprocesses.
Beware! this will likely lock up your machine, or at the very least
prevent you from launching any new processes.
Simply type make with this makefile in
I've seen something similar...
It seemed to be permission related and I never did figure it out...
try rsync'ing the files to another directory on the destination server and
then rsync'ing again from there to the final directory (on the same
server)...see it that works...
- Original Message
On Wed, 13 Apr 2005 07:00:50 +0200 (CEST), wrote:
The cygutils package has been updated to 1.2.7. This adds a 'rename'
utility, and fixes some issues with cygstart.
o Changes from version 1.2.6-1
- rename.exe added (contributed by Christopher Faylor)
Rename seems rather cute
eg
Well, if you scroll all the way down, you see it works fine if i run the app
manually. It only hangs there if it is run automatically. (I run it as
Administrator, but it get's auto launched as the local system).
-Jason
On Thu, Apr 14, 2005 at 01:23:35PM -0400, Ben Terry wrote:
From: Ben Terry
On Thu, Apr 14, 2005 at 06:29:53PM +0100, zzapper wrote:
On Wed, 13 Apr 2005 07:00:50 +0200 (CEST), wrote:
The cygutils package has been updated to 1.2.7. This adds a 'rename'
utility, and fixes some issues with cygstart.
o Changes from version 1.2.6-1 - rename.exe added (contributed by
On Wed, 13 Apr 2005 15:41:07 -0500, wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sam Steingold
Sent: Wednesday, April 13, 2005 3:07 PM
To: cygwin@cygwin.com
Subject: Re: ReMOVE ME FROM YR MAILING LIST FOR THE LAST TIME FUK OFF
how
Brian Dessent wrote:
If you're not using the -17 (test) version of bash, try that.
Wow! Much better! My scripts are still churning after 4 hours. When will
this be part of an offical cygwin drop?
--
Ken Shaffer
- - - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - -
I just did a complete re-install of the latest version of cygwin (1.5.14-1),
and come across the following problem: when prepping a source for compilation,
invoking:
./configure
would stop at seemingly random places. However, running:
bash ./configure
worked much better. It still didn't
Original Message
From: Timothy Wall
Sent: 14 April 2005 18:22
Attached is a very simple makefile which demonstrates the problem.
There's a leak either in make itself or in the spawning of
subprocesses.
Beware! this will likely lock up your machine, or at the very least
prevent you
So, is the following terminal trace just due to the braindead NFS
implementation of Win2000 SP4, or is there a bug in cygwin chmod(2) in regards
to directory permissions? I have /cygdrive/u viewing my home drive on a unix
box NFS server named perth.
$ cd /cygdrive/u
$ alias ll='ls -lF'
$
Christopher Faylor writes:
Yeah, one of the rpms that I am working on building for my real job (tm)
actually used rename on linux. It was news to me that this program even
existed. I usually write some kind of for loop to do this.
Maybe that's because I am not sure at all it does exist on
Am Donnerstag, 14. April 2005 20:13 schrieb Jan Nieuwenhuizen:
Christopher Faylor writes:
Yeah, one of the rpms that I am working on building for my real job (tm)
actually used rename on linux. It was news to me that this program even
existed. I usually write some kind of for loop to do
Thanks for the input so far. Task Manager shows memory usage slowly
creeping up as the makefile below is run. I've verified this on two XP
laptops and one w2k desktop. The memory never comes back, and it
doesn't take long to max out a 512Mb/768Mb machine. Might take a bit
longer if you've
Upon closer inspection of the logfiles, it appears that the line after the last
line below (in the Good run of the program) is:
2005-04-14 09:19:29: debug1: read PEM private key done: type DSA
So i go to look at the .ssh/id_dsa file, and sure enough, the file wasn't
readable by anyone but
$ head -1 /usr/bin/rename
#!/usr/bin/perl -w
Yes, Debian includes a perl script /usr/bin/rename, which seems more
powerful than Cygwin rename:
NAME
rename - renames multiple files
SYNOPSIS
rename [ -v ] [ -n ] [ -f ] perlexpr [ files ]
DESCRIPTION
rename renames
On Thu, Apr 14, 2005 at 08:13:33PM +0200, Jan Nieuwenhuizen wrote:
Christopher Faylor writes:
Yeah, one of the rpms that I am working on building for my real job
(tm) actually used rename on linux. It was news to me that this
program even existed. I usually write some kind of for loop to do
Should the version info provided by echo $BASH_VERSION match
the bash version displayed by cygcheck -cd? If not, is there some way to
verify that the bash I'm really running is the version displayed by
cygcheck? Or, does cygcheck gets its version info from within the
executable?
--
Ken Shaffer
On Thu, Apr 14, 2005 at 08:21:01PM +0200, Markus Sch?nhaber wrote:
Am Donnerstag, 14. April 2005 20:13 schrieb Jan Nieuwenhuizen:
Christopher Faylor writes:
Yeah, one of the rpms that I am working on building for my real job
(tm) actually used rename on linux. It was news to me that this
program
What package is strings in now. I thought it used to be in sh_utils but
see it's being replaced by coreutils.
--
Ken Shaffer
- - - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary,
rename comes from the util-linux package.
cgf
cgf you are right. I just checked a couple of my Linux boxes and
there is a rename in /usr/bin/ I suspect that most old-time UNIX
weenies (myself included) have never used it. I always used mv.
WOW, learn something new everyday :-P
--
On Thu, Apr 14, 2005 at 03:56:20PM -0400, Shaffer, Kenneth wrote:
What package is strings in now. I thought it used to be in sh_utils but
see it's being replaced by coreutils.
http://cygwin.com/cgi-bin2/package-grep.cgi?grep=strings.exe
--
Unsubscribe info:
Christopher Faylor writes:
So, it is no surprise that the rename from util-linux is available un
FC*, RH7.2, RH9, Gentoo, SuSE, (AFAICT) Mandrake, and (AFAICT)
Slackware.
Thanks for the information. I filed a bug-report with Debian's perl
package.
Jan.
--
Jan Nieuwenhuizen [EMAIL
On Thu, 14 Apr 2005, Erik Rantapaa wrote:
I just did a complete re-install of the latest version of cygwin
(1.5.14-1), and come across the following problem: when prepping a
source for compilation, invoking:
./configure
would stop at seemingly random places. However, running:
bash
On Thu, 14 Apr 2005, Shaffer, Kenneth wrote:
Should the version info provided by echo $BASH_VERSION match the bash
version displayed by cygcheck -cd? If not, is there some way to verify
that the bash I'm really running is the version displayed by cygcheck?
If you're running a bash that was
Shaffer, Kenneth wrote:
If you're not using the -17 (test) version of bash, try that.
Wow! Much better! My scripts are still churning after 4 hours. When will
this be part of an offical cygwin drop?
Well, it's already official in that it's been on all the cygwin
mirrors for quite some
Dave Korn wrote:
Hmm, actually I'm not sure now: do post-install scripts invoke a login
shell? Does /etc/profile get run for them?
Setup runs sh -c postinstallscript so that would mean that it's not a
login shell, if I understand right.
Brian
--
Unsubscribe info:
Greetings! First off, thanks to all for Cygwin - this is a great system
that saves us massive amounts of time. I'm currently preparing to
deploy Cygwin to replace some commercial tools on our network. I have
everything working the way I want on my machine, and would like to
capture this
Carl Perry wrote:
I've built an NSIS installer taht copies all the files and creates
all the necessary icons - however things are not functioning as
expected.
If you're not copying the mounts, you're almost certainly going to run
into problems. The correct way to do this is to do mount -m
Hi everybody,
[cc:ing libtool as I started a thread about Libtool execution speed there]
One thing that has annoyed me for a while is that large/complex shell
scripts with a lot of forking, like configure scripts or Libtool, run
quite slowly on Cygwin. I know that you have to do a lot of
On Thu, 14 Apr 2005, Brian Dessent wrote:
Carl Perry wrote:
I've built an NSIS installer taht copies all the files and creates
all the necessary icons - however things are not functioning as
expected.
If you're not copying the mounts, you're almost certainly going to run
into problems.
Robert Ögren wrote:
My questions for you:
1. Do these numbers seem reasonable?
Yes, unfortunately. Heavy fork()-exec() based scripts just take
forever.
2. Is there anything (apart from cross-compiling on Linux :) ) that can
be done to increase script execution speed?
You can try mounting
At 05:54 AM 4/14/2005, you wrote:
Yes, I did notice the strange character in the cygcheck drive listing output.
Is the information from GetVolumeInformation used by cygwin to determine how
to treat the volume? (Ie is it possible that the nonsense output is the root
of the problem?)
Not
Brian Dessent wrote:
Kees Vonk wrote:
Okay, the .la is just the libtool version of an .a file. That's all
fine and good.
gcc -I./.. -I.. -Wall -g -O2makedatprog.c -o makedatprog
This is your problem. make is invoking an implicit rule for
makedatprog, rather than the one specified by the
Kees Vonk wrote:
[EMAIL PROTECTED]@
EXTRA_PROGRAMS=makedatprog$(EXEEXT)
Try this instead:
[EMAIL PROTECTED]@$(EXEEXT)
EXTRA_PROGRAMS=makedatprog
The way to debug this is to look at the generated Makefile and find
places where a *_programs refers to something without .exe on the end.
for
On Thu, Apr 14, 2005 at 03:02:50PM -0700, Brian Dessent wrote:
Shaffer, Kenneth wrote:
If you're not using the -17 (test) version of bash, try that.
Wow! Much better! My scripts are still churning after 4 hours. When will
this be part of an offical cygwin drop?
Well, it's already
Hello all,
I try to run setup.exe and get the following message regardless of the mirror I
select:
(null) line 1: synatx error, unexpected LT, expecting $end
I haven't seen any recent posts on this matter, but it seems that the last time
that it happened, someone needed to apply a patch. Can
1 - 100 of 103 matches
Mail list logo
