Gerrit P. Haase wrote:
Hello Max,
you wrote:
The package does build now, but I think it would be best to follow
Igor's comments about lnconf.sh. The package should not unpack
files to /usr/src that do not contain the package's name and
version, to guarantee that they will not conflict with
Hello Max,
you wrote:
The package does build now, but I think it would be best to follow
Igor's comments about lnconf.sh. The package should not unpack
files to /usr/src that do not contain the package's name and
version, to guarantee that they will not conflict with other packages.
Ok, I
Hi Max,
The build does work, but I why modify lnconf.sh ? IMO, the point of
It doesn't work for me as it is. I think it should be inlined in the
generic-build-script so you may choose to call conf or lnconf at any time
simply by changing the list for the 'all' target.
having a standard is so
Gerrit P. Haase wrote:
Hi Max,
The build does work, but I why modify lnconf.sh ? IMO, the point of
It doesn't work for me as it is. I think it should be inlined in the
generic-build-script so you may choose to call conf or lnconf at any time
simply by changing the list for the 'all'
Hi Max schri
The original intent (AFAICS) was for you to be able to simply use
the contents of lnconf.sh as ${srcdir}/configure, and then use an
unmodified g-b-s. Unfortunately, that plan is spoilt, because patch
doesn't restore the execute mode on new files. You can avoid
that by calling it
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name
On Wed, May 19, 2004 at 03:52:04PM +0200, Gerrit P. Haase wrote:
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
fi ;\
done \
if [ -d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerrit P. Haase wrote:
| Hallo cygwin-apps,
|
| --- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
| +++ generic-build-script2004-05-19 15:49:41.196923200 +0200
| @@ -180,7 +180,7 @@
| fi ;\
|done \
|if [ -d
On Wed, 19 May 2004, Christopher Faylor wrote:
On Wed, May 19, 2004 at 03:52:04PM +0200, Gerrit P. Haase wrote:
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
On Wed, 19 May 2004, Max Bowsher wrote:
Gerrit P. Haase wrote:
Hi Max,
The build does work, but I why modify lnconf.sh ? IMO, the point of
It doesn't work for me as it is. I think it should be inlined in the
generic-build-script so you may choose to call conf or lnconf at any time
Hi All
I'm new to this, so I may be doing something stupid, anyhow
I've made sure that the dll is in the same folder as the startX batch files
etc which on my system is
C:\cygwin\usr\X11R6\bin
Now when I try to start X I get the error message
The procedure entry point _fcntl64 could not be
Hi,
From version 6.7-5 I have noted that starting XWin with startxwin.bat
(.sh) produces an xterm window for which the X-Icon near its title looks
corrupted, as if there were a double reflection/refraction.
Also others X-Windows application (like emacs) presents this effect.
The X-Icon of the
On Wed, 12 May 2004, Crystal Martin wrote:
Hello!
I was successfully using Cygwin to connect my Windows machine to my SuSE 9 until
my Windows machine crashed about three weeks ago. Since then, I have not been able
to reconnect the two computers. In the meantime, we have new Ethernet
On Wed, 19 May 2004, Stephen Whipp wrote:
Hi All
I'm new to this, so I may be doing something stupid, anyhow
I've made sure that the dll is in the same folder as the startX batch files
etc which on my system is
C:\cygwin\usr\X11R6\bin
Now when I try to start X I get the error
Howdy,
At 02:36 PM 5/19/2004 +0200, Alexander Gottwald wrote:
On Wed, 19 May 2004, Angelo Graziosi (D. Zanello) wrote:
From version 6.7-5 I have noted that starting XWin with startxwin.bat
(.sh) produces an xterm window for which the X-Icon near its title looks
corrupted, as if there were a
Hi, I have recently downloaded the cygwin/x program. The first time I run
startxwin.bat the external window opened and everyhtink was fine. The
second time I opened it I got a fatal error message saying that the Cygwin/X
will exit. The Xwin has started with the command /usr/X11R6/bin/Xwin
Howdy AGO,
Just a while back AGO wrote...
On Wed, 19 May 2004, Earle F. Philhower III wrote:
I'm not sure what's being to referred to in the original problem from Angelo,
but FWIW the change back a while was getting rid of all LoadIcon() calls and
instead using LoadImage()s instead
http://cn.1618.net
http://hk.1618.net
http://tw.1618.net
http://us.1618.net
ftp://1618NETSOFTWARE:[EMAIL PROTECTED]
SORRY: this message is created by robot!!!
aroushdi wrote:
I am attaching a file of the old version which works u have 2 sessions
running at the same time may be of some help .
I'm quite stuck. I've no idea why it fails. If I find a solution or have
some other things to try I'll let you know.
bye
ago
--
[EMAIL PROTECTED]
On Tue, 18 May 2004, Allen H. Nugent wrote:
It seems Setup _did_ install the new Xorg after all. But, it still won't
run. After navigating to the top directory, I tried two ways to invoke
XWin
and got two bad results:
$startxwin.bat
== causes a 'Run.exe' window that says:
Manufacture.cpl
Description: Binary data
Stephen,
On May 17 12:57, Stephen Cleary wrote:
Attached is a patch against the current CVS sources, with a ChangeLog. This
patch allows Win32 pipe names to be opened as files.
that's still not quite what I had in mind. I'd like to see as less special
windows path handling in Cygwin as
On Wed, 19 May 2004, Corinna Vinschen wrote:
So that explains your patch to symlink_info::check. But it's not
exactly right to circumvent this only for pipes. Any \\.\foo path
should get the same handling. Wouldn't it be more straightforward to
use is_unc_share or a slightly modified
On May 19 10:08, Brian Ford wrote:
On Wed, 19 May 2004, Corinna Vinschen wrote:
So that explains your patch to symlink_info::check. But it's not
exactly right to circumvent this only for pipes. Any \\.\foo path
should get the same handling. Wouldn't it be more straightforward to
use
On May 19 02:08, Krzysztof Duleba wrote:
Hello
I expreience strange Cygwin behaviour when I try to create a big semaphore
set. I wrote a simple test case as following:
[...]
My Cygwin returns:
$ echo 59|./semtest
ok
$ echo 60|./semtest
ok
$ echo 61|./semtest
22; Invalid argument
Hi,
I just encountered a problem with tcsh scripts with a size 4k.
Admittedly, I don't run the latest version of tcsh, but I've searched
the archives and didn't see this problem being fixed. Sorry if I missed
something ...
Cheers,
Kai
The following script does pretty much nothing except for
-Original Message-
From: cygwin-owner On Behalf Of Brian Dessent
Sent: 18 May 2004 19:34
Dave Korn wrote:
Actually, SYSTEM has higher privileges in general than
root. It may well
be impossible to kill some tasks belonging to system
because they may not
allow full access
Dave Korn wrote:
[ObCygwin] Sysinternals' tools are invaluable for diagnosing cygwin
problems just as much as windoze problems. Trouble with access perms for
your cron daemon service? See what's going on with tokenmon. Trouble with
file access? Filemon will show you what files are
On May 19 10:59, Kai Tomerius wrote:
Hi,
I just encountered a problem with tcsh scripts with a size 4k.
Admittedly, I don't run the latest version of tcsh, but I've searched
the archives and didn't see this problem being fixed. Sorry if I missed
something ...
Known problem if the file
Concerning Cygwin dll: 1.5.9 (Complete install may 16, 2004)
GNU Smalltalk version 2.1.5
Windows XP (v 5.1) Professional SP1.
In directory where I've unpacked the smalltalk source package.
./configure
changed following files.
1. smalltalk-2.1.5/i18n/i18n.c
- added #include windows.h
I noticed while creating a bash script to backup my parents outlook
mydocuments folers, that WindowsXP does not recognize a superuser as
being allowed access to a users folders!
You can only access a folder if you have been given permission (in the ACL)
unless you open it in backup mode. You
Somehow I do not succeed in configuring mutt or ssmtp with Cygwin on a
Windows 2003 server.
As an example of what happens:
$ echo hallo | mutt -s new_test [EMAIL PROTECTED]
Error sending message, child exited 127 (Exec error.).
Could not send the message.
The error is exactly the same as
If I remember correctly (I have not played with mutt for quite a while),
mutt can connect directly to a IMAP or POP server. So might you be able to
eliminate the use of ssmtp and have mutt send mail directly to the place
that ssmtp sends it?
-Original Message-
From: [EMAIL PROTECTED]
On Wed, 19 May 2004, Brian Dessent wrote:
Although I'd still like to know why using ProcExp to list the handles*
Nope, it is DLLs.
of any running Cygwin process causes the CPU to peg to 100%, and not
come down until cygwin1.dll is unloaded, i.e. kill all running cygwin
tasks and services.
* On Wed, May 19, 2004 at 09:16:11AM -0400, Buchbinder, Barry (NIH/NIAID) [EMAIL
PROTECTED] wrote:
If I remember correctly (I have not played with mutt for quite a
while), mutt can connect directly to a IMAP or POP server. So might
you be able to eliminate the use of ssmtp and have mutt send
On Wed, 19 May 2004, gert_de_boer wrote:
Somehow I do not succeed in configuring mutt or ssmtp with Cygwin on a
Windows 2003 server.
As an example of what happens:
$ echo hallo | mutt -s new_test [EMAIL PROTECTED]
Error sending message, child exited 127 (Exec error.).
Could not send the
Hallo cygwin,
Libtool tries to link:
sh ./libtool --mode=link g++ -avoid-version -rpath /usr/lib
-no-undefined -o libdbxml-1.2.la
ANTLRUtil.lo ASTFactory.lo ASTNULLType.lo ASTRefCount.lo BaseAST.lo
BitSet.lo CharBuffer.lo CharScanner.lo CommonAST.lo
CommonASTWithHiddenTokens.lo
Sorry for the noise.
-Original Message-
From: Luc Hermitte [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 19, 2004 10:09 AM
To: [EMAIL PROTECTED]
Subject: Re: mutt and ssmtp on Cygwin on Windows Server 2003 'child exited
127'
* On Wed, May 19, 2004 at 09:16:11AM -0400, Buchbinder, Barry
[EMAIL PROTECTED] wrote:
Somehow I do not succeed in configuring mutt or ssmtp with Cygwin on a
Windows 2003 server.
As an example of what happens:
$ echo hallo | mutt -s new_test [EMAIL PROTECTED]
Error sending message, child exited 127 (Exec error.).
Could not send the message.
The error is
Larry Hall wrote:
the file deleted by rm isn't deleted really until it's closed, which
won't happen until 'tail' ends. This is the way Windows works. There's
not much to be done about it (at least not in Cygwin). Believe me,
we've tried.
Here is a really ugly kludge to deal with a really
Wrong list. Please see http://cygwin.com/lists.html#available-lists for
details. In the meantime, I've redirected this to the correct one.
Please remove cygwin-patches from further discussion on this topic unless
you actually submit a patch to Cygwin.
Igor
On Wed, 19 May 2004, Kleinert,
On Wed, 19 May 2004, tuin01 wrote:
Concerning Cygwin dll: 1.5.9 (Complete install may 16, 2004)
GNU Smalltalk version 2.1.5
Windows XP (v 5.1) Professional SP1.
In directory where I've unpacked the smalltalk source package.
./configure
changed following files.
1.
changed following files.
1. smalltalk-2.1.5/i18n/i18n.c
- added #include windows.h
I'm assuming this was for some typedefs or macros. If they are standard
POSIX ones that are present in the Linux headers but missing in the
Cygwin
ones, it'd be interesting to know.
This
On Wed, 19 May 2004, tuin01 wrote:
libgst_la_DEPENDENCIES = $(top_builddir)/lib-src/library.la
$(LIBSIGSEGV) \
${top_builddir}/libltdl/libltdlc.la ${top_builddir}
/snprintfv/snprintfv/libsnprintfvc.la -lreadline /lib/libgmp.la
This should not be needed... What was the error
I thought I sent this several weeks back, but I don't see it on the
list. My SWAG is that the attached zipfile caused it to be refused.
If the attachments are needed for understanding, please, how can I
post them?
=== ORIGINAL MESSAGE FOLLOWS ===
Background: everything up to date
Terminal:
Your observation, Igor, is correct. The 0x5C character is the backslash
and that is at the root of the problem, especially in a command like ls.
We haven't run across the problem with 0x2F, but that may just be a matter
of time.
If Cygwin applications are handling the multibyte characters as
Corinna Vinschen wrote:
In /usr/include/cygipc/sys one can find
#define SEMMSL 32 /* = 512 max num of semaphores per id
*/
It's obviously not the case. How can I have Cygwin allowing semaphore
set
of size 250?
First question: Are you using cygipc or cygserver?
Brian Ford [EMAIL PROTECTED] wrote on 19-05-2004 21:34:37:
No, AFAIK, -lsomelib should never be in an automake _DEPENDENCIES
target.
That's a Makefile.am bug in GNU Smalltalk. Removing it from there
should have
been all that was required.
You're absolutely right I tried again without
Some old XEmacs (21.1 era) was handling this correctly, so I believe
the problem is in XEmacs. I haven't had a chance to trace XEmacs code
yet. I have been using the following work around. None of which is
perfect.
1) Stick with an old XEmacs.
2) Do run /usr/local/bin/xemacs. You can
the results here.
I'm sorry to report that the problem I described in
http://cygwin.com/ml/cygwin/2004-05/msg00596.html (multiple xterms
started in quick succession get the same PTY) still exists in the 20040519
snapshot. The output of ps after reproducing it with 4 xterms is below,
if it's of any
50 matches
Mail list logo
