Re: Can I mount an EXT3 partition that WinXP sees as "(Unknown partition)"?

[Peter Farley]

FYI, explore2fs found both my boot and root partitions
on the firewire external drive with no trouble.

Thanks for the pointer, this is just what I needed, an
easy way to copy info over to cygwin.

Peter

--- Larry Hall
<[EMAIL PROTECTED]> wrote:
> At 04:00 PM 5/3/2005, you wrote:
> >On a firewire-mounted external hard drive I have an
> >EXT3 partition that used to be the root file system
> >for an RH7.3 linux setup.  Is there any way to
> mount
> >such a partition to cygwin when XP doesn't
> recognize
> >it with a drive letter?
> >
> >The partition is primary, not extended.
> 
> 
> No.  You need software that knows the filesystem
> first.  You can check out Paragon if you're looking
> for commercial support.  There is an older
> free S/W driver for ext2 and NT but I haven't tried
> it since NT 4 and I can't recommend it.  If you're
> just looking to get read access (and/or very 
> touchy write access) and don't mind the slowness of
> a user-land utility, check out Explore2fs
>
<http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm>.
> I don't know if it works with FireWire but it does
> work fine with local ext3 partitions.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: pwd vs $PWD, bash, cygwin vs Linux

[Peter Farley]

But what if it is *not* your Makefile, but someone
else's, e.g. the many GNU source packages that expect
bash behavior?  Surely you don't intend that ordinary
users (well, OK, anyone compiling from a source
package isn't really "ordinary") should modify every
package maintained by GNU in order to make it under
cygwin, do you?

With respect,

Peter

P.S. - If there have already been discussions or if
there already exists documentation on why ash vs. bash
(I gather it is for performance reasons), I'd
appreciate (a) pointer(s) so I could better learn the
history so I don't re-hash settled issues.

--- Christopher Faylor
<[EMAIL PROTECTED]> wrote:
 
> I really don't understand why using CURDIR isn't
> the ultimate solution here.  If you can mess with
> your mount table or copy bash to sh, then
> you really should be able to also change your
> Makefile to use $(CURDIR) rather than $$PWD.



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: pwd vs $PWD, bash, cygwin vs Linux

[Peter Farley]

WHOA there.  I think we have a slight failure to
communicate.  I am NOT the OP, I was just chiming in
on the conversation (I should have said PMFJI right up
front, apologies for forgetting that).

That said, I understand your position better now,
especially with Dave's workaround (perfectly
acceptable to me, don't know about the OP).

I certainly did NOT intend to say or to imply that 
cygwin maintainers should make any global fix to
address this issue.  I just did not understand the
reason that bash was not the default shell.  Now I do.
 Thank you (and Dave Korn) for straightening me out.

Mea maxima culpa for not being clear in my question or
my comments.

Peter

--- Christopher Faylor
<[EMAIL PROTECTED]> wrote:
> On Wed, May 04, 2005 at 08:05:40AM -0700, Peter
> Farley wrote:
> >But what if it is *not* your Makefile,
> 
> I just went back and reread this thread.  It isn't
> exactly clear that this was not your Makefile. 
> You mentioned a "test setup" which seemed
> to imply that you were using your own Makefiles.
> 
> >but someone else's, e.g.  the many GNU source
> >packages that expect bash behavior?
> 
> Most GNU packages are interested in being portable. 
> Assuming that every system out there is POSIX
> compliant is not portable.  I have a couple of
> older systems that I use which would have the same
> problems as cygwin if you use PWD in a Makefile. 
> Actually, CURDIR would also be a problem
> for them since they don't use GNU make.  Since the
> workaround is trivial it would make sense to not
> rely on PWD in any package that is supposed
> to be disseminated widely.
> 
> >Surely you don't intend that ordinary users (well,
> OK, anyone compiling
> >from a source package isn't really "ordinary")
> should modify every
> >package maintained by GNU in order to make it under
> cygwin, do you?
> 
> I would expect a GNU-maintained package to accept a
> patch to eliminate a potential problem source.
> 
> However, I surely don't intend to keep talking
> about this any further. I get the feeling that you
> want us (i.e., cygwin maintainers) to do
> something globally to solve this.  We've been using
> ash for many years and we're not about to change
> anytime soon.  You've been given enough
> alternatives now that you should be able to get
> things working.
> 
> Cygwin is not guaranteed to be 100% POSIX compliant
> or 100% linux compliant.  Sometimes we make
> tradeoffs because of Windows constraints.
> Since bash is noticeably slower than ash under
> Cygwin, we use ash as our /bin/sh.  That produces
> some problems for non-portable shell constructs.
> 
> cgf


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

sshd "owned by root" error

[Ordal, Peter]

I just finished an install of Cygwin's OpenSSH on XP SP 2. Along the way I
got the error:

/var/empty must be owned by root and not group or world-writable.

This has been discussed several places before, I know. Still, I had a
different experience than previous posts. I found that what "owned by root"
meant was actually owned by the account running sshd. So, when I ran
/usr/sbin/sshd -D under my domain account, I had to chown /var/empty to my
account.

I tried to get sshd to run as a service under the system account, but it
wouldn't start. The console error message (on typing net start sshd) was not
helpful, and the event log just said "starting service `sshd' failed: execv:
255, error 255." Even with /var/empty chowned to system, no luck. So I was
forced to change the sshd service to run as my domain account, and to
similarly take ownership of /var/empty.

I found this error message originates on line 1166 of sshd.c in the openssh
package. Perhaps it should be changed. Saying "owned by root" doesn't make
much sense here.

Cheers,
Peter

References:
Google search -
http://www.google.com/search?q=cygwin+%22must+be+owned+by+root+and+not+group
%22
Best results from that:
1 - http://archive.erdelynet.com/ssh-l/2003-09/msg00048.php
2 - http://www.cs.princeton.edu/~sudhakar/linux/trivia.html
3 - http://www.derkeiler.com/Newsgroups/comp.security.ssh/2003-05/0219.html
(rather spirited)

>From this list - http://sourceware.org/ml/cygwin/2005-03/msg00514.html

--
Peter Ordal
Webmaster
Office of College Enrollment
University of Rochester

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

tail -f and pipes with bash shell

[Peter Ekberg]

Hello!

What is going on here?

~$ ps -f | grep $$
peda2316   1 con  20:21:51 /usr/bin/bash
peda31802316 con  21:51:47 /usr/bin/ps
peda31642316 con  21:51:47 /usr/bin/grep

  [I use bash, if that matters]

~$ tail -f frame.log | grep Antenna
2005-05-11,21:51:07: Antenna DAC 0
2005-05-11,21:51:17: Antenna DAC 0
2005-05-11,21:51:26: Antenna DAC 0
2005-05-11,21:51:36: Antenna DAC 0
2005-05-11,21:51:46: Antenna DAC 0
2005-05-11,21:52:06: Antenna DAC 0

  [Fine, that works, I get bored and press ^C]

~$ tail frame.log | grep Antenna | cat
2005-05-11,21:51:17: Antenna DAC 0
2005-05-11,21:51:26: Antenna DAC 0
2005-05-11,21:51:36: Antenna DAC 0
2005-05-11,21:51:46: Antenna DAC 0
2005-05-11,21:52:06: Antenna DAC 0

  [Fine, that works...]

~$ tail -f frame.log | grep Antenna | cat

  [No output!? I'm puzzled and press ^C]

Every other line in frame.log is an "Antenna"-
line, so I really think there should be output
from the last command as well.

(For the real task I'm doing I want to do more
 than 'cat' at the end of the pipe, this is just
 a trimmed down example.)

Can anyone please provide any hints?

Cheers,
Peter


cygcheck.log
Description: cygcheck.log
--
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: tail -f and pipes with bash shell

[Peter Ekberg]

Lev Bishop wrote:
> On 11/05/05, Peter Ekberg wrote:
>> What is going on here?
> 
> My guess: "tail frame.log" closes its stdout as soon as it has read
> the requested lines from the file, "tail -f frame.log" keeps its
> stdout open, since it is waiting for new lines to be added to the
> logfile. Cat is using some buffering on its stdin, so it tries to read
> a buffer's worth of data at a time.

Ah, thanks for the hint!

But, the buffering does not seem to happen in cat (or
is at least triggered by something external to cat).

If I open two cmd window consoles, and in the first
one I issue
~$ cat > foobar

And in the second one I issue
~$ tail -f foobar | grep d
I see all lines entered in the first console on the
second console (if they have d in them) with a fairly
rapid response time.

But if I instead issue this in the second console
~$ tail -f foobar | grep d | grep d
I get the buffering effect with high latencies...

Also, if I issue this in the second console
~$ tail -f foobar | cat
I again get a farily rapid response time.

So, the buffering does not seem to be related to cat,
but to where in the pipe the process is located, or
to the length of the pipe or something.

Rather unintuitive, my guess is that it's BYAM...

Cheers,
Peter

--
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: tail -f and pipes with bash shell

[Peter Ekberg]

Lev Bishop wrote:
> Try "grep --line-buffered" to get grep to flush output after every
> line. There is a performance penalty for doing this. I don't know why
> you don't see the buffering when grep's stdout isn't redirected.
> Perhaps grep (or the std library) removes/reduces buffering in the
> case the output is a terminal.
> 
> Lev

Yes, that works for this slimed down example, but probably not for
the real work, as that includes several other commands that do
not all have a --line-buffered equivalent. Thanks for you time
though.

I'll drop this now, it's getting more complex than the task
deserves. I can get by as is...

Cheers,
Peter

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

dllwrap fails to find last exported symbol alphabetically

[Peter Stephenson]

A problem now seen by two of us with recent Cygwin installations:
mine was updated to `current' status last week.  However, I don't think
this is new since I've been seeing it on my own setup for a while.

Zsh uses `dllwrap --export-all-symbols' to link against it's own DLL's.
On the systems in question, dllwrap failed to identify the last symbol
exported from the main dll (zsh.dll) against which all the other DLL's
are linked.  The symbol in question is `zwarnnam'; we've verified it
really is the last symbol by adding a dummy one later in the alphabet,
and the problem goes away.  (This is an easy workaround so consequently
finding a real fix isn't a high priority for us.)

It sounds like if this is fundamental lots of people would have fallen
over it, but I've no idea what else might be relevant.

Anyway, on systems where it does trigger, it will show up by downloading
zsh 4.2.0 from ftp://ftp.zsh.org/pub/ and trying to compile with default
options.  You will see warnings about failures to find the symbol
zwarnnam when linking DLL's.  (The failure seen by users is a crash on
an attempt to print warning messages form libraries.  Running `vared
nonexistentvar' form the installed shell will do this.)  We haven't
narrowed it down any further.

If you (the Cygwin people) need more information, it's probably best to
prod [EMAIL PROTECTED] (this list runs qconfirm but you only need to
confirm once).

-- 
Peter Stephenson <[EMAIL PROTECTED]>  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK  Tel: +44 (0)1223 692070


**
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited. 
If you received this in error, please contact the sender and 
delete the material from any computer.
**


--
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: zsh and line breaks

[Peter Stephenson]

Bart Schaefer wrote:
> On Apr 2,  5:23pm, Peter A. Castro wrote:
> }
> } On Thu, 1 Apr 2004, Peter A. Castro wrote:
> } 
> } So, now I need a ruling on just where to put this fix.
> 
> I don't know that I can give you a "ruling" but in my opinion it would be
> fine to put this in main.c, appropriately #ifdef'd.

I agree, there's nothing magic about main.c.  The only reason it's short
is because usually it's convenient for as much stuff as possible to be
in zsh.dll, on systems where that needs to exist.  Your case is exactly
the opposite, so main.c is fine.

-- 
Peter Stephenson <[EMAIL PROTECTED]>
Work: [EMAIL PROTECTED]
Web: http://www.pwstephenson.fsnet.co.uk

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

Peter Ihlenfeld ist unterwegs!

[Peter Ihlenfeld]

Ich werde ab  03.04.2004 nicht im Büro sein. Ich kehre zurück am
18.04.2004.



Erst danach werde ich wieder Gelegenheit haben, Ihre mail zu lesen.

Bitte wenden Sie sich bei Bedarf vertrauensvoll an meine Kolleginnen und
Kollegen im Innendienst der Niederlassung in Stuttgart [Tel. 07 11/7 21
99-19 oder "[EMAIL PROTECTED]"].

Viele Grüße von

Peter Ihlenfeld


Important Note 
This email and any attachment hereto are confidential and may contain trade secrets or 
may be otherwise protected from disclosure. If you have received it in error you are 
in 
notice of this fact. Please notify us immediately by reply email and then delete this 
email and any attachment from your system. Please understand that you are not allowed 
to 
copy this email or any attachment hereto or disclose its contents to any other person. 
Thank you.

Wichtiger Hinweis 
Diese E-Mail und etwaige Anlagen koennen Betriebs- oder Geschaeftsgeheimnisse oder 
sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtuemlich 
erhalten
haben, ist Ihnen dieser Umstand hiermit bekannt. Bitte benachrichtigen Sie uns in 
diesem Fall umgehend durch Ruecksendung der E-Mail und loeschen Sie diese E-Mail 
einschließ-
lich etwaiger Anlagen von Ihrem System. Diese E-Mail und ihre Anlagen duerfen 
weiterhin nicht kopiert oder an Dritte weitergegeben werden. Vielen Dank.

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

rsync question

[Peter Kok]

Dear All
-- 
Problem: using rsync with nontsec turned on.
 
I would like to rsync from a Solaris box to a Windows 2000 Server.  
W2K 
server is running cygwin version 1.5.9.  The CYGWIN variable was set 
to 'binmode tty nontsec'.  
 
I used nonntsec rather than ntsec to retain the NTFS permission 
inheritance.  The permission for all newly created folders and files 
were set correctly as their parent folder.  But, the nontsec option 
doesn't allow me to rsync with public key authentication.  I received 
error message 'Read from socket failed: Connection reset by peer', and 
in the ssh debug log, I saw that it didn't accept my public key at 
all.  But when I switched back using the ntsec option, the 
authentication went through with the same RSA public key!
 
Q1: If I want to retain my NTFS permission inheritance, am I correct 
that I have to use nontsec?
Q2: Could nontsec work with public key authentication?  I have granted 
the account with several local user rights, "create token object, 
logon 
as a service' and 'replace a process level token'
 
Thank you for your help
Peter

--
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: rsync question

[Peter Kok]

> At 12:08 AM 4/17/2004 +0200, Corinna Vinschen wrote:
> >On Apr 16 15:44, Peter Kok wrote:
> 
> >> Q2: Could nontsec work with public key authentication?  I have 
granted 
> >> the account with several local user rights, "create token object, 
> >> logon 
> >> as a service' and 'replace a process level token'
> >
> >Did you give the SYSTEM account the right to read your ~/.ssh 
directory
> >and the files in it?  Does the service know about nontsec (set CYGWIN
> >in global windows environment or through cygrunsrv)?  Is StrictModes 
set
> >to no in /etc/sshd_config?
> 
> >From Peter's question it's not clear if his sshd is running as 
SYSTEM.
> If it is, then granting the privileges to the user should not be
> necessary, but that doesn't explain the problem.
> 
> I can reproduce on an NT system, with sshd running as SYSTEM,
> but I can't explain it. Part of the debug output of ssh is given
> below, with and without ntsec. The difference is in the last few
> lines.
> 
> Pierre
> 
>It's a problem with the ntsec specific test in OpenSSH itself.  The
>test requires ntsec to be turned on for switching user context w/o
>password.  This isn't required anymore for a while but the test in
>OpenSSH still insists on ntsec for pubkey auth.
>
>I've send a patch to the portable OpenSSH developers list which 
>hopefully
>makes it into 3.8.1p1, which is due RSN.
>
>Corinna

Thank you Corinna for your quick response.  I just saw that OpenSSH has 
release 3.81pl on April 19, but unfortunately, it didn't include the 
new patch.  Can you please show me tips/website onto how I could 
compile the new modified bsd-cygwin_util.c to be used by cygwin?

Thanks in advance,
Peter


--
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 To Export NFS?

[Peter Rehley]

I'm going start off by stating the obvious.  After starting the 
daemons, make sure that they are really running.  After the mount do 
the check again.  Make sure that you can ping the box you want to 
access.

Try removing the broadcast and submask from the exports file.
If everything seems to be running, then stop the daemons and start them 
again with debugging turned on.  You'll need two bash windows opened 
for this.
rpc.mountd -F -d all
rpc.nfsd -F -d all

This will run the commands in the foreground and show all messages.  If 
you don't need all messages don't use -d all.

When running as a back ground process, you can check the log messages 
in the Event Viewer or /var/log/*.log

On your linux machine, check the log files also.
If you already got this to work.. Good job, what did you do.
Peter
On May 14, 2004, at 6:26 AM, Baurjan Ismagulov wrote:
Hello, Jack!
On Thu, 13 May 2004, Jack Polimer wrote:
I'm trying to export an NFS filesystem under cygwin to
a Linux machine on the same network, but I get"
# mount -t nfs 10.0.0.1:/etc /mnt
mount: RPC: Timed out
The client is not getting anything from the remote portmapper. Try
"rpcinfo -p 10.0.0.1" and "showmount -e 10.0.0.1". If this does not
help, investigate with tcpdump/ethereal on both ends.
With kind regards,
Baurjan.
--
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/

=
Infinity Softworks.  Making scientific, financial and realtor 
calculators for Palm Pilots and other PDAs since 1997

Visit them today at http://www.infinitysw.com
--
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/

Running ssh from procmail

[Peter Wisnovsky]

I have a strange problem that I'm hoping someone can help me with. I've
searched the archives and this may be related to some socket difficulties
people have had on dual processor systems, but I dunno.

I have a winxp dual xeon system in my office with an up-to-date cygwin
installation as of today that cygchecks ok.

I use a somewhat wierd mechanism to penetrate my office firewall from my
home computer, since Mac OSX doesn't support the vpn server my company uses
(gack!). I run fetchmail/procmail to check mail at the office, and based on
a certain pattern it runs a script that runs ssh to my home system at a
fixed IP doing port forwarding, and running sleep for a minute. I send
myself mail, wait a little, then connect my remote desktop client to the
forwarded port. Ssh is then configured to hang around until the connection
dies.

This had been working fine for a while. I hadn't used it for a bit, maybe in
a month or two, in the meantime upgrading cygwin a couple of times at the
office. Now when I try I get various forms of wierdness.

If I run ssh -l xyz verklempt (my home system, in /etc/hosts) it works fine.

If I start bash and run the "tohome.sh" script it connects fine.

If I send myself the telltale email I get

ssh: verklempt: no address associated with name

Odd, since it knows what "verklempt" is when run on the command line. OK, I
replace the address with the fixed IP in the script. I get:

socket: Operation not permitted
ssh: connect to host #.#.#.# port 22: Operation not permitted

Fetchmailrc is (some names changed to protect the innocent)

poll xyz.com protocol pop3 username abc keep mda "/usr/bin/procmail -d %T"

Procmailrc is

SHELL=/bin/sh
PATH=/bin:/usr/bin:/pkg/mail/bin
MAILDIR=$HOME/usr/mail
DEFAULT=$MAILDIR/INBOX.spool
LOGFILE=$MAILDIR/procmail.logfile
VERBOSE=on
LOGABSTRACT=all
export PATH

:0:
* ^Subject: blahblahblah
| /usr/bin/bash -x $HOME/tohome.sh

...

tohome.sh contains

(echo "${LOGNAME} : ${SHELL} : Open connection at `date` " ;
/usr/bin/ssh -g -n -e none -R #:localhost:# -l abc $HOMEADDR "sleep 180" ;
echo Connection closed at `date`) >> /tmp/openconnect.ssh 2>&1 &

Any help someone can provide would be much appreciated...I'm not sure where
to start. I've looked at the procmail/fetchmail man pages concerning the
process environment of forked processes but can't find anything to account
for this. Moreover since it used to work I suspect its a bug that has been
introduced not too long ago.

Thanks,

Peter


--
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: Running ssh from procmail

[Peter Wisnovsky]

More information on this problem with ssh hostname resolution failing.

If my fetchmailrc has

poll ...  mda "/usr/bin/procmail -d %T"

hostname resolution in the nested script fails with
+ /usr/bin/ssh -g -n -e none -v -R p1:localhost:p1-l me verklempt 'sleep
180'
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh_config
ssh: verklempt: no address associated with name

If I do

poll ... mda "/usr/bin/procmail -p /home/me/.procmailrc"

(e.g. preserve environment) I get

+ /usr/bin/ssh -g -n -e none -v -R p1:localhost:p1-l me verklempt 'sleep
180'
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to verklempt [] port 22.

Hurray! But I'm confused as to why.

The only think I can think of that would cause ssh to fail to resolve a host
named in /etc/hosts based on the environment would be if my PATH were
picking up a different ssh, but debug indicates they are the same...moreover
I named the binary explicitly as /usr/bin/ssh in the script. Any ideas what
environment var or user setting could be interferering with this? This used
to work as is.

Peter

- Original Message - 
From: "Peter Wisnovsky" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 11, 2004 11:39 AM
Subject: Running ssh from procmail -#- MailID:KHFA


> I have a strange problem that I'm hoping someone can help me with. I've
> searched the archives and this may be related to some socket difficulties
> people have had on dual processor systems, but I dunno.
>
> I have a winxp dual xeon system in my office with an up-to-date cygwin
> installation as of today that cygchecks ok.
>
> I use a somewhat wierd mechanism to penetrate my office firewall from my
> home computer, since Mac OSX doesn't support the vpn server my company
uses
> (gack!). I run fetchmail/procmail to check mail at the office, and based
on
> a certain pattern it runs a script that runs ssh to my home system at a
> fixed IP doing port forwarding, and running sleep for a minute. I send
> myself mail, wait a little, then connect my remote desktop client to the
> forwarded port. Ssh is then configured to hang around until the connection
> dies.
>
> This had been working fine for a while. I hadn't used it for a bit, maybe
in
> a month or two, in the meantime upgrading cygwin a couple of times at the
> office. Now when I try I get various forms of wierdness.
>
> If I run ssh -l xyz verklempt (my home system, in /etc/hosts) it works
fine.
>
> If I start bash and run the "tohome.sh" script it connects fine.
>
> If I send myself the telltale email I get
>
> ssh: verklempt: no address associated with name
>
> Odd, since it knows what "verklempt" is when run on the command line. OK,
I
> replace the address with the fixed IP in the script. I get:
>
> socket: Operation not permitted
> ssh: connect to host #.#.#.# port 22: Operation not permitted
>
> Fetchmailrc is (some names changed to protect the innocent)
>
> poll xyz.com protocol pop3 username abc keep mda "/usr/bin/procmail -d %T"
>
> Procmailrc is
>
> SHELL=/bin/sh
> PATH=/bin:/usr/bin:/pkg/mail/bin
> MAILDIR=$HOME/usr/mail
> DEFAULT=$MAILDIR/INBOX.spool
> LOGFILE=$MAILDIR/procmail.logfile
> VERBOSE=on
> LOGABSTRACT=all
> export PATH
>
> :0:
> * ^Subject: blahblahblah
> | /usr/bin/bash -x $HOME/tohome.sh
>
> ...
>
> tohome.sh contains
>
> (echo "${LOGNAME} : ${SHELL} : Open connection at `date` " ;
> /usr/bin/ssh -g -n -e none -R #:localhost:# -l abc $HOMEADDR "sleep 180" ;
> echo Connection closed at `date`) >> /tmp/openconnect.ssh 2>&1 &
>
> Any help someone can provide would be much appreciated...I'm not sure
where
> to start. I've looked at the procmail/fetchmail man pages concerning the
> process environment of forked processes but can't find anything to account
> for this. Moreover since it used to work I suspect its a bug that has been
> introduced not too long ago.
>
> Thanks,
>
> Peter
>
>
> --
> 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/
>


--
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: Running ssh from procmail

[Peter Wisnovsky]

I'm running it using fetchmail -d #.

Peter

- Original Message - 
From: "Brian Dessent" 
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 15, 2004 9:05 AM
Subject: Re: Running ssh from procmail -#- MailID:TNFA


> Peter Wisnovsky wrote:
> 
> > socket: Operation not permitted
> > ssh: connect to host #.#.#.# port 22: Operation not permitted
> 
> How are you scheduling fetchmail to run?  From cron?  If it's running
> from cron, then it will be running as the SYSTEM user.  It will be
> impersonating your regular user account, but since it's launched from a
> service it will actually be the SYSTEM account that owns the process. 
> I've read that on recent server versions (e.g. Win2k3) the SYSTEM
> account has less privileges assigned to it by default, one of which
> might be "access the network."  If that's the case then it would explain
> why it cannot gethostbyaddr() to resolve the hostname, and why the
> socket functions fail with "operation not permitted" if supplied a
> dotted-quad.  Try adding that privilege, or have crun run as the
> "NetworkService" instead of "LocalServer" or whatever it's called.
> 
> Brian
> 
> --
> 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/
> 

--
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: Running ssh from procmail

[Peter Wisnovsky]

No such luck...moreover wouldn't a missing binary or dll lead to a link  
or exec failure?

Peter
On Jun 15, 2004, at 1:34 AM, Corinna Vinschen wrote:
Add the usual Windows paths to $PATH, e.g. on my system that would be
   
PATH=/bin:/usr/bin:/pkg/mail/bin:/cygdrive/c/WINDOWS/system32:/ 
cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem

Then try your original solution again.  I have this feeling it will  
help.

Corinna

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

Perl crash caused by "system 'net send...'"?

[Peter Aarestad]

I'm running a script that does a screen scrape and tries to send out a
"net send" to our team to let them know about a new ticket. When I run
it with the 'system "net send machine msg"' commented out, it works
fine. But when I uncomment it, I get the following:

C:\cygwin\bin\perl.exe (2100): *** unable to remap
C:\cygwin\bin\cygssl-0.9.7.dl
l to same address as parent(0xC3) != 0xC4
C:\cygwin\bin\perl.exe (2100): *** unable to remap
C:\cygwin\bin\cygssl-0.9.7.dl
l to same address as parent(0xC3) != 0xC4
  5 [main] perl 2096 sync_with_child: child 2100(0x17C) died before
initiali
zation with status code 0x1
   4034 [main] perl 2096 sync_with_child: *** child state child loading
dlls

A "perl.exe.stackdump" file is created, but it's empty. Attached is my
script (with URLs and other info changed to protect the innocent, but
it's functionally equivalent to my "real" script).

For the record, I have cygwin 1.5.10-3 and perl 5.8.2-1, as well as the
latest packages I need to run my script via CPAN (LWP, Net::SSL,
HTML::Tree, etc.).

Thanks!

-peter

=
Peter M Aarestad
[EMAIL PROTECTED]

During times of universal deceit, telling the truth becomes a revolutionary act.
  --George Orwell

screenscraper.pl
Description: screenscraper.pl
--
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: Perl crash caused by "system 'net send...'"? - FIXED

[Peter Aarestad]

> Oh, that.  You're in for some pain, friend.

Oh dear. :( (Actually, the pain was minor...)

> What's happening is
> that Windows is trying to load two "executables" into the same
> address space (I think).The short answer is to investigate the
> program /usr/bin/rebaseall; simply running that program according to
> the directions (which might be on some web page somewhere) *might*
> fix it.

This was it! I grabbed "rebase" from the archive, and tried to rebase
/bin/cygssl-0.9.7.dll, only to find it was mysteriously write-protected
(555 rights). Changed it to 755, ran

$ rebase -b 0x7000 /bin/cygssl-0.9.7.dll

and rebase ran without complaint. Ran the Perl script again, and it
worked splendiferously.

I hope this was just something goofy on my machine, rather than some
other problem. Anyway, thanks for the hint, Eric!

-peter

=
Peter M Aarestad
[EMAIL PROTECTED]

During times of universal deceit, telling the truth becomes a revolutionary act.
  --George Orwell

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

gcc install problem

[Peter Wisnovsky]

I'm trying to install gcc on my system so I can build the id-utils.

I run the setup program from the web site, pick a mirror, check "Devel/gcc".
Some other things get pulled in. I hit Next.

The .bz files are downloaded to my package dirs, and it says "Download
Complete". Yay! But the binaries don't get installed. Wah!

I try again: again, gcc is not checked (!), but it finds the cached files,
says download complete, doesn't install any binary.

I've tried this with a couple of mirrors with no luck. Am I missing
something?

Peter


--
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: gcc install problem

[Peter Wisnovsky]

Doh! I've gotten so used to just flipping past the first few screens I never
noticed the radio button got flipped to "Download" instead of
"Install"...though whats odd is I don't recall ever dinking with it.

This sort of thing has cropped up before, and it has always been
attributable to human error.

Peter

- Original Message - 
From: "Christopher Faylor"
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 23, 2004 4:45 PM
Subject: Re: gcc install problem -#- MailID:N4GA


> On Wed, Jun 23, 2004 at 04:31:41PM -0700, Peter Wisnovsky wrote:
> >I'm trying to install gcc on my system so I can build the id-utils.
> >
> >I run the setup program from the web site, pick a mirror, check
"Devel/gcc".
> >Some other things get pulled in. I hit Next.
> >
> >The .bz files are downloaded to my package dirs, and it says "Download
> >Complete". Yay! But the binaries don't get installed. Wah!
>
> So, you avoided the option that told setup to install files and just
> told setup to just download files to your system.  If you want to
> install files you have to use the Install option.
>
> --
> 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/
>


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

Dynamic loading of cygwin dependent dlls

[Peter Ekberg]

Hello!

I have read several messages stating that dlopen does not work for dlls
that depend on cygwin1.dll.
(e.g. http://sources.redhat.com/ml/cygwin/2004-06/msg01056.html).
I have also understood that this is due to some structures not being
initialized in that case.

Is this dlopen problem limited to non-cygwin apps? I.e. is it true
that an app that depends directly on the cygwin1.dll is incapable of
dlopening dlls that depend on cygwin1.dll?

Regards,
Peter Ekberg

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

how can I set $REMOTEHOST ( so I can set $DISPLAY with sshd w\X11 forwarding)

[peter waltman]

hi -

trying to figure out how to set $REMOTEHOST when I ssh into a machine running
cygwin's imp. of sshd.  X11 forwarding works great when I set the $DISPLAY
properly, but I'd like to have it done in the .bashrc file (by checking if the
$REMOTEHOST var is set).

I've tried looking through the startup scripts on both my cygwin install and a
rh9 box, but can't find where it gets set.  can anyone point me in the right
direction?

tia,

Peter


--
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 set $REMOTEHOST ( so I can set $DISPLAY with sshd w\X11 forwarding)

[peter waltman]

Ken Dibble  alltel.net> writes:

> 
> I'm not 100 % sure what you are saying.
> Are you trying to say that the cygwin sshd does not respect the -X and 
> -Y flags
> passed to the local ssh process?
> And that for the above named reason you are forced to manually set the 
> DISPLAY variable?
> 
> regards,
> ken
> 
> 
> peter waltman wrote:
> 
> >hi -
> >
> >trying to figure out how to set $REMOTEHOST when I ssh into a machine running
> >cygwin's imp. of sshd.  X11 forwarding works great when I set the $DISPLAY
> >properly, but I'd like to have it done in the .bashrc file (by checking if the
> >$REMOTEHOST var is set).
> >
> >I've tried looking through the startup scripts on both my cygwin install and a
> >rh9 box, but can't find where it gets set.  can anyone point me in the right
> >direction?
> >
> >
> >  
> >
> 
> 


yeah.  pretty much.  I've set the "ForwardX11 yes" in the sshd_config file on
the server I log into and I've also set it in the ssh_config with the client I'm
using to log into it.

   piano{pwaltman}51: ssh -X grad107m
   [EMAIL PROTECTED]'s password:
   Last login: Fri Aug  6 19:16:42 2004 from lin04.eecs.tufts.edu

   [EMAIL PROTECTED] ~
   $ echo $DISPLAY
   127.0.0.1:0

even when I use the -X flag, it still set's my $DISPLAY to the above value and
when I start an X11 app, like xterm, it ends up getting launched in the server's
x-server and appears on the desktop of the server (grad107m).  If I set the
$DISPLAY to localhost:10.0, everything works fine and it appears on the client.

not sure why, ergo the reason I want to use the $REMOTEHOST var as a means to
check if I've ssh'd in remotely and then use something like

if $?REMOTEHOST
   export DISPLAY=$REMOTEHOST:0.0

thanks for any ideas,

Peter

p.s. forgive the shell script syntax errors.  I don't remember the exact script,
but I've seen folks who've done it this way.  



--
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: Dynamic loading of cygwin dependent dlls

[Peter Ekberg]

Christopher Faylor wrote:
>On Thu, Aug 05, 2004 at 09:09:40AM +0200, Peter Ekberg wrote:
>>I have read several messages stating that dlopen does not work for
dlls
>>that depend on cygwin1.dll.
>>(e.g. http://sources.redhat.com/ml/cygwin/2004-06/msg01056.html).
>>I have also understood that this is due to some structures not being
>>initialized in that case.
>>
>>Is this dlopen problem limited to non-cygwin apps? I.e. is it true
>>that an app that depends directly on the cygwin1.dll is incapable of
>>dlopening dlls that depend on cygwin1.dll?
>
>No, it is not true.  dlopen would be pretty worthless if it didn't work
>in a standard cygwin program.

Indeed. Knowing that it should work, I was inspired to do some more
tests.

The reason I asked is that the following results in a dll that can't be
dlopened:

foo.c:
8<---
__declspec(dllexport) int foo(int bar);

int foo(int bar)
{
return bar;
}
8<---

Build commands:
$ gcc -c foo.c
$ dlltool --dllname pseudo_stubs.dll --exclude-symbols
[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],DllMainCR
[EMAIL PROTECTED],[EMAIL PROTECTED] --output-def foo.def  foo.o
$ dllwrap --dllname pseudo_stubs.dll --output-lib pseudo_stubs.dll.a
--def foo.def foo.o -L/usr/lib

However, further tests have shown that if I change the name pseudo_stubs
to foo in the above commands, it works like a charm. Like this:

$ gcc -c foo.c
$ dlltool --dllname foo.dll --exclude-symbols
[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],DllMainCR
[EMAIL PROTECTED],[EMAIL PROTECTED] --output-def foo.def  foo.o
$ dllwrap --dllname foo.dll --output-lib foo.dll.a --def foo.def foo.o
-L/usr/lib

I use this program to test whether the resulting dll works:

load.c
8<---
#include 
#include 

char *dlls[] = {
"pseudo_stubs.dll",
"foo.dll",
NULL
};

int main(void)
{ 
int i;
void *res;

for(i=0; dlls[i]; ++i) {
printf("%s\t", dlls[i]);
res=dlopen(dlls[i], RTLD_LAZY | RTLD_GLOBAL);
if(!res)
printf("%s\n", dlerror());
else
printf("ok\n");
}

return 0;
}
8<---

I build load.c with "gcc load.c -o load" and ./load produces this
output:
pseudo_stubs.dlldlopen: Win32 error 998
foo.dll ok

Any help on this would be appreciated.

Cheers,
Peter Ekberg



cygcheck.out
Description: cygcheck.out
--
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: Dynamic loading of cygwin dependent dlls

[Peter Ekberg]

 

Reid Thompson wrote:
> well -- i just redid the entire thing, with the correct spelling and
> your original post works
> 
> $ ./load
> pseudo_stub.dll ok
> foo.dll ok

That's strange, did my original post first get you error 998 for
pseudo_stubs.dll and now, after some juggling, the same thing is ok?

Cheers,
Peter

--
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: Dynamic loading of cygwin dependent dlls

[Peter Ekberg]

I wrote:
> Reid Thompson wrote:
> > well -- i just redid the entire thing, with the correct spelling and
> > your original post works
> > 
> > $ ./load
> > pseudo_stub.dll ok
> > foo.dll ok
> 
> That's strange, did my original post first get you error 998 for
> pseudo_stubs.dll and now, after some juggling, the same thing is ok?

Ah, now I see it. You have to be careful with your typing.
pseudo_stubs.dll (with one s in the end) is the name that fails.
Apparently both pseudo_stub.dll (no s) and psuedo_stubs.dll (bad
spelling) work. And pseudo_stubss.dll (double s) definitely works, that
I have tried myself.

Cheers,
Peter


--
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: Dynamic loading of cygwin dependent dlls

[Peter Ekberg]

> > Ah, now I see it. You have to be careful with your typing.
> > pseudo_stubs.dll (with one s in the end) is the name that fails.
> > Apparently both pseudo_stub.dll (no s) and psuedo_stubs.dll (bad
> > spelling) work. And pseudo_stubss.dll (double s) definitely 
> works, that
> > I have tried myself.
> 
> You have checked what error 998 actually is?
> 
> #define ERROR_NOACCESS 998L

Of course. I have also checked what might cause the error. See:
http://support.microsoft.com/default.aspx?scid=kb;en-us;q196069

I can also say that I have tried to use the pure Win32 LoadLibrary call
on the resulting dlls, and the results are consistent with the dlopen
results. My guess is that there is something wrong inside the dll, that
causes a segfault during dlopen/LoadLibrary.

> I cannot believe that it depends on the name of a DLL whether it can
> be dlopened or not.

Me neither, yet the name appears to be significant in some way.

>  There must be another error with your test!
> 
> Consider this (with source from your first posting):
> $ gcc -shared -o pseudo_stubs.dll foo.c
> $ gcc -o load load.c
> $ ./load
> pseudo_stubs.dllok
> foo.dll dlopen: Win32 error 126
> $ cp pseudo_stubs.dll foo.dll
> $ ./load
> pseudo_stubs.dllok
> foo.dll ok

Hey, that doesn't explain anything. It's like answering someones awk bug
report with "see, it works with sed, your test must be wrong". Apart
from that, thanks for the example, the project now uses "gcc -shared"
with apparent success. So for me, this problem is now academic.

I'm not saying that it is the name of the dll that is causing the
problem. If I build the dll as foo.dll with dlltool/dllwrap and rename
it to pseudo_stubs.dll, pseudo_stubs.dll works. Also, if I build the dll
as pseudo_stubs.dll and rename it foo.dll, foo.dll doesn't work.

I'd say that there is some sort of problem in dlltool/dllwrap. Please
enlighten me if I'm using them incorrectly.

Can someone also please say if they get error 998 for the example in the
original post, or if that happens on my machine only.

Cheers,
Peter

--
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: http://cygwin.com/snapshots/cygwin-inst-20040802.tar.bz2 contains extra files?

[peter waltman]

Christopher Faylor  cygwin.com> writes:

> 
> On Sun, Aug 08, 2004 at 02:00:00PM -0700, Yitzchak Scott-Thoennes wrote:
> >I downloaded and installed
> >http://cygwin.com/snapshots/cygwin-inst-20040802.tar.bz2
> >
> >and was a bit surprised to see that it included files normally in the
> >w32api and mingw-runtime packages as well as a few other files (and
> >/bin/dumper.exe which is normally in the cygwin package was missing).
> 
> dumper missing is a problem.  The extra files are not.
> 
> cgf
> 
> 


there are 2 configurations when I'm ssh'ing into the machine.

1 - I use the windows version of the ssh2 client from www.ssh.com.  X11
tunneling is a feature which you can either enable or disable (enabled on my
machine).  the x-server is the pc-xware x-server.  there is no problem when I
ssh into any of the other server's on my school's network, but I can't determine
what the local $DISPLAY var is set to.

2 - using another machine with cygwin, I use the startxwin.bat script to start
the xserver and open a window with a bash shell prompt in it.  again, I have no
issue with X11 being tunneled if I ssh into any of the other unix servers on our
shool's network.  the local $DISPLAY var for the cygwin client is set to
localhost:0.

Both configurations have the same problem where X11 apps launched from the
client's shell get launched and opened under the x-server running on the machine
running the cygwin sshd daemon (also launched using the startxwin.bat script).

Additional info about my setup, the server (grad107m) is part of a windows
domain and is running windows XP professional.  the account I use to log in is
not the machine admin, though the machine admin account was used to install
cygwin.  The domain accts and groups had to be added post-install using the

mkpasswd -l -d > /etc/passwd

and 

mkgroup -l -d > /etc/group

commands.

thanks for any ideas or suggestions,

Peter


--
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: http://cygwin.com/snapshots/cygwin-inst-20040802.tar.bz2 contains extra files?

[peter waltman]

> 
> So this is not a Cygwin specific problem and therefore, off-topic for this 
> list.
> --



apologies.  this got posted in reply to the wrong article.  I'll add it to the
correct topic.

Peter


--
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 set $REMOTEHOST ( so I can set $DISPLAY with sshd w\X11 forwarding)

[peter waltman]

Brian Dessent  dessent.net> writes:

> 
> Igor Pechtchanski wrote:
> 
> > > It could be that if DISPLAY is set before you run ssh -X then ssh won't
> > > change it.  Try unsetting DISPLAY first.
> > 
> > This is wrong.  "ssh -X/-Y" will not enable X11 forwarding *unless*
> > DISPLAY is set in the local shell.
> 
> Ahh, I should read the man page more often.  I knew there was some
> relation between setting $DISPLAY before invoking ssh -X, but I guess
> those neurons were crossed.
> 
> Brian
> 
> 

there are 2 configurations when I'm ssh'ing into the machine.

1 - I use the windows version of the ssh2 client from www.ssh.com.  X11
tunneling is a feature which you can either enable or disable (enabled on my
machine).  the x-server is the pc-xware x-server.  there is no problem when I
ssh into any of the other server's on my school's network, but I can't determine
what the local $DISPLAY var is set to.

2 - using another machine with cygwin, I use the startxwin.bat script to start
the xserver and open a window with a bash shell prompt in it.  again, I have no
issue with X11 being tunneled if I ssh into any of the other unix servers on our
shool's network.  the local $DISPLAY var for the cygwin client is set to
localhost:0.

Both configurations have the same problem where X11 apps launched from the
client's shell get launched and opened under the x-server running on the machine
running the cygwin sshd daemon (also launched using the startxwin.bat script).


I believe this is the pertinent section of the sshd_config file:

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

and perms 

$ ls -al /etc/sshd_config
-rwxr-xr-x+   1 eecsexec Domain U 2485 Aug  4 17:29 /etc/sshd_config

Additional info about my setup, the server (grad107m) is part of a windows
domain and is running windows XP professional.  the account I use to log in is
not the machine admin, though the machine admin account was used to install
cygwin.  The domain accts and groups had to be added post-install using the

mkpasswd -l -d > /etc/passwd

and 

mkgroup -l -d > /etc/group

commands.

thanks for any ideas or suggestions,

Peter





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

Apache CGI Scripts - Network layer permission denied

[Peter Flanigan]

When I run CGI scripts from Apache I'm getting permission denied errors.

use Net::protoent;
my $p = getprotobyname(shift || 'tcp');

if (defined $p) {
 printf("proto for %s is %d, aliases are %s\n",
  $p->name, $p->proto, "@{$p->aliases}");
} else {
 printf("Bad protocol 'tcp'\n");
}

This correctly turns ths string 'tcp' into the number 6 via lookup in
/etc/protocols when run from the pdksh prompt. Returns the bad protocol
error when run as a CGI script from Apache. Apache is being started (by
apachectl start) from the same shell prompt which correctly runs the script.
In general I'm finding that all network related calls (creating new sockets
and similar) are failing.

I also note (and think that it's related) that uname -n returns the correct
mixed case hostname when run from the shell prompt but returns an incorrect
(all upper case) string when run from the cgi-bin/test-cgi shell script.
This eliminates Perl from the equation.

I think this is the same problem as posted to this mailing list by:

Richard Morse <[EMAIL PROTECTED]>
Problems with Amanda and Cygwin 1.5.10
28/07/2004

and

"David A. Rogers" [EMAIL PROTECTED]
Socket problem w/ apache & perl cgi
30/07/2004

I did not notice any follow up posts to these queries (my spam filter was
rejecting some Cygwin mailing list posts).

Regards


cygcheck.out
Description: Binary data
--
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/

Creating a multi-volume archive with tar

[Peter Milliken]

Hi,

I am trying to write large files across multiple floppies using tar. I am
using tar 1.13.25 and it writes to the first diskette but then stops - no
prompt for the next disk or anything.

I searched the archives and found the following:

> >
> >Did you try the -M or --multi-volume option of tar?
> >
> >Corinna
> >
> 
> Yes, I did.
> 
> I even tried to force "tape size" to number below the size of floppy 
> disk -- no success.
> 
> I have experience with C, so I think I could find a problem, but I think 
>  that development could do it quicker. Anyway if you point me where to 
> start, I can try.

I found the culprit.  It was age old code in Cygwin which should speed
up reading and writing on raw devices by using buffering.  This works
nicely for reading, but it doesn't work quite as well for writing.
I've removed buffered writing for raw devices entirely.


Corinna


Is this fix in the currently available distribution yet? Is so, which
component of cygwin do I have to update i.e. tar.exe, one of the dll's or
what?

If it's not currently available, what are my options? :-)

Thanks
Peter

Peter Milliken
Software Engineer
ResMed
Phone: +61 2 9886-5059
Fax:   +61 2 9878-5564 


Warning:  Copyright ResMed.  Where the contents of this email and/or attachment 
includes materials prepared by ResMed, the use of those
materials is subject exclusively to the conditions of engagement between ResMed and 
the intended recipient.
 
This communication is confidential and may contain legally privileged information.
By the use of email over the Internet or other communication systems, ResMed is not 
waiving either confidentiality of, or legal
privilege in,the content of the email and of any attachments.
If the recipient of this message is not the intended addressee, please call ResMed 
immediately on  +61 2 9886 5000 Sydney, Australia.


--
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: Question about moving cygwin to another dirve

[Peter Rehley]

On Aug 16, 2004, at 9:43 PM, Yihu Li wrote:
Dear all,
My c drive does not have enough space, so I just copyed the whole 
folder of cygwin to another drive and expect to run it there. It 
worked but the problem is that the default folder is still under 
c:/cygwin, not the new one g:/cygwin. Anyone knows how to map it to 
the new drive?
Change the mount information in the registry
Thanks a lot.
Yihu

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


--
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: Creating a multi-volume archive with tar

[Peter Milliken]

[...]
> It's a bug in the Cygwin DLL.
> 
> > If it's not currently available, what are my options? :-)
> 
> Install a developers snapshot of Cygwin (http://cygwin.com/snapshots/)
> or wait for the 1.5.11 release which is due VSN.
> 
> 
> Corinna
[...]

That certainly did the trick - thanks :-) Sorry for the newbie questions.

Next step is I would like to backup some very large files to DVD. I have
some video files (>13GByte) that I would like to backup across multiple DVD
discs (-R or -RW - whichever works :-)).

Has anybody used a DVD burner as a backup mechanism and how do you work out
the device name to use with tar i.e. I found that a floppy is /dev/fd0 -
what would a DVD burner device name be? Is there a command that displays
device names?

Thanks
Peter


Warning:  Copyright ResMed.  Where the contents of this email and/or attachment 
includes materials prepared by ResMed, the use of those
materials is subject exclusively to the conditions of engagement between ResMed and 
the intended recipient.
 
This communication is confidential and may contain legally privileged information.
By the use of email over the Internet or other communication systems, ResMed is not 
waiving either confidentiality of, or legal
privilege in,the content of the email and of any attachments.
If the recipient of this message is not the intended addressee, please call ResMed 
immediately on  +61 2 9886 5000 Sydney, Australia.


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

Setup broken

[Peter Flanigan]

Whilst trying to regress Cygwin to avoid bugs in the current release I get 

(null) line 1537: parse error, unexpected COMMA, expecting STRING

when setup.exe tries parsing setup.ini

Anyone know know what it means and how to fix it?

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

__const use instead of const in one place

[Peter Hinely]

Hi,

I noticed that __const is used in one and only one place in the header files.  

Line 76 of \user\include\sys\unistd.h

char_EXFUN(*getpass, (__const char *__prompt));

That's the only place in all the header files.  Shouldn't it be changed to const?  

Regards,
Peter



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

_PC_SYMLINK_MAX and other #defines missing from

[Peter Hinely]

Hi,

It seems _PC_SYMLINK_MAX and some other #defines missing from 

Here is a description of the values:
http://www.opengroup.org/onlinepubs/009695399/functions/pathconf.html
http://www.greatsnakes.com/Sepal/d9/d7/unistd_8h.html

Some of them are there in the implementation, while some of them are missing from the 
implementation.

Thanks,
Peter


--
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 starting the server in an XP account other than the one installing cygwin

[Peter Rehley]

On Aug 23, 2004, at 10:56 AM, Congwu Cui wrote:
I just installed cygwin in xp. I found that the X server could not be
started in any acccount other than that in which it is installled, 
even the
the account is an admistrator one. what do i need to do? thanks a lot. 
I am
new to this software.

You need to read http://cygwin.com/problems.html.  This provides 
guidelines as to what to provide when having problems with cygwin.


Yours,
Congwu Cui

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


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

configure: error: invalid package name: extra-includes

[Peter Ekberg]

Hi list!

I have a problem with a configure script. It works like a charm most of
the time, but something seems to trigger a bug. I can work around the
bug by inserting extra spaces (or moving/removing them) between the
configure arguments.

Pasting some lines from the shell:

~/ggi-cygwin/libgii$ ../../ggi3/ggi-core/libgii/configure --prefix=/usr
-C  --with-extra-includes=/cygdrive/c/dx9csdk/include
configure: error: invalid package name: extra-includes
~/ggi-cygwin/libgii$ ../../ggi3/ggi-core/libgii/configure --prefix=/usr
-C  --with-extra-includes=/cygdrive/c/dx9csdk/include
configure: loading cache config.cache
checking for a BSD-compatible install... (cached) /usr/bin/install -c
(I hit ^C)

Note the extra space after the -C argument.

Sometimes I have to use less extra spaces, like this:
~/ggi-cygwin/libgii$ ../../ggi3/ggi-core/libgii/configure --prefix=/usr
-C --with-extra-includes=/cygdrive/c/dx9csdk/include

Note that neither of these invocations work every time. I have
successfully tried all of them at some point though, so none of them are
always failing either. That seems to depend on if configure script has
been regenerated though, but it can also be the phase of the moon...
The directory names also seem relevant, that's why I have included
complete paths. Please try with different number of spaces between
arguments to try to trigger the bug before giving up.

I have not attached the configure script in question as it is rather
large. Instead it can be downloaded from
http://www.lysator.liu.se/~peda/configure
Here is a chain of commands to get a slimmed down environment for
testing it.

~$ mkdir ggi3
~$ mkdir ggi3/ggi-core
~$ mkdir ggi3/ggi-core/libgii
~$ mkdir ggi3/ggi-core/libgii/input
~$ mkdir ggi3/ggi-core/libgii/input/stdin
~$ mkdir ggi3/ggi-core/libgii
~$ mkdir ggi-cygwin
~$ mkdir ggi-cygwin/libgii
~$ touch ggi3/ggi-core/libgii/input/stdin/input.c
~$ wget http://www.lysator.liu.se/~peda/configure -O
ggi3/ggi-core/libgii/configure
~$ chmod +x ggi3/ggi-core/libgii/configure
~$ cd ggi-cygwin/libgii
~/ggi-cygwin/libgii$ ../../ggi3/ggi-core/libgii/configure --prefix=/usr
-C --with-extra-includes=/cygdrive/c/dx9csdk/include

With this slimmed down environment the bug is triggered when you see:
configure: error: invalid package name: extra-includes

The bug is not triggered when you see:
configure: loading cache config.cache
configure: error: cannot find install-sh or install.sh in
../../ggi3/ggi-core/libgii ../../ggi3/ggi-core/libgii/..
../../ggi3/ggi-core/libgii/../..

The last error is of course due to the slimmed down environment, the
relevant thing to note is that the script got around to load the cache.

You're of course all welcome to grab cvs-head of ggi-core for the
complete test case (see http://sourceforge.net/projects/ggi/ for
details).

I do not seem to be alone with problems in this area, see:
http://www.ethereal.com/lists/ethereal-users/200309/msg00163.html
http://sulaco.hrhansen.dk/pipermail/kimdaba/2004-March/000309.html

This post can also be related:
http://www.cygwin.com/ml/cygwin/2003-10/msg00556.html

Any suggestions? Is it reproducable?

Cheers,
Peter Ekberg



cygcheck.out
Description: cygcheck.out
--
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: configure: error: invalid package name: extra-includes

[Peter Ekberg]

I wrote:
> ~/ggi-cygwin/libgii$ ../../ggi3/ggi-core/libgii/configure 
> --prefix=/usr
> -C  --with-extra-includes=/cygdrive/c/dx9csdk/include
> configure: error: invalid package name: extra-includes
> ~/ggi-cygwin/libgii$ ../../ggi3/ggi-core/libgii/configure 
> --prefix=/usr
> -C  --with-extra-includes=/cygdrive/c/dx9csdk/include
> configure: loading cache config.cache
> checking for a BSD-compatible install... (cached) /usr/bin/install -c
> (I hit ^C)
> 
> Note the extra space after the -C argument.
> 
> Sometimes I have to use less extra spaces, like this:
> ~/ggi-cygwin/libgii$ ../../ggi3/ggi-core/libgii/configure 
> --prefix=/usr
> -C --with-extra-includes=/cygdrive/c/dx9csdk/include

Crap, the relevant parts got munched. The relevant parts were:
"...nfigure --prefix=/usr -C  --wit..."
"...nfigure --prefix=/usr  -C  --wit..."

and

"...nfigure --prefix=/usr -C --wit..."

Sorry for the confusion.

Cheers,
Peter

--
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: configure: error: invalid package name: extra-includes

[Peter Ekberg]

> The last time I tried to build ggi-project failed with compilation
> errors.  That probably means that I was able to configure it 
> or parts of
> it.

I have spent some time on getting libggi working. I believe it does work
now, you have to use the cvs version though as the released versions do
not have all the patches that has been commited lately.

The problem is not that I can't get it to work. It works *most* of the
time. *Sometimes* there's this mysterious failure though. I'm tired of
adding spaces to the configure command and I would also like
"./config.status --recheck" to work reliably.

What does an extra space between configure arguments really change? This
is friggin' strange.

> I always update the autogenerated part when a package is going to
> build shared libraries, try: autoreconf --install --force --verbose in
> the source directory.  Well, you do this anyway when building 
> from CVS?

No, there is an autogen.sh script included though. It basically boils
down to this:
aclocal
autoheader
automake --add-missing
autoconf

Anyway, I tried:
WANT_LIBTOOL_VER=1.5.6 WANT_AUTOMAKE_VER=1.8.5 WANT_AUTOCONF_VER=2.59
autoreconf --install --force --verbose
and I can still reproduce the bug. I can configure with the "correct"
number of extra spaces though, but it later bugs out during make so that
is a definite step backwards.

> Which version of configure, automake, libtool are you using?

autoconf 2.59 and automake 1.8.5 and an old libtool (libtool is included
in libgii, I've had to throw quite a few patches at it to make it work
with cygwin/mingw. I reported a dlltool/dllwrap problem to this list
earlier related to this and got the advise to use "gcc -shared").

Cheers,
Peter

--
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: configure: error: invalid package name: extra-includes

[Peter Ekberg]

Gerrit wrote:

> Peter wrote:
> 
> >> The last time I tried to build ggi-project failed with compilation
> >> errors.  That probably means that I was able to configure it 
> >> or parts of
> >> it.
> 
> > I have spent some time on getting libggi working. I believe 
> it does work
> > now, you have to use the cvs version though as the released 
> versions do
> > not have all the patches that has been commited lately.
> 
> > The problem is not that I can't get it to work. It works 
> *most* of the
> > time. *Sometimes* there's this mysterious failure though. 
> I'm tired of
> > adding spaces to the configure command and I would also like
> > "./config.status --recheck" to work reliably.
> 
> > What does an extra space between configure arguments really 
> change? This
> > is friggin' strange.
> 
> >> I always update the autogenerated part when a package is going to
> >> build shared libraries, try: autoreconf --install --force 
> --verbose in
> >> the source directory.  Well, you do this anyway when building 
> >> from CVS?
> 
> > No, there is an autogen.sh script included though. It 
> basically boils
> > down to this:
> > aclocal
> > autoheader
> > automake --add-missing
> > autoconf
> 
> > Anyway, I tried:
> > WANT_LIBTOOL_VER=1.5.6 WANT_AUTOMAKE_VER=1.8.5 
> WANT_AUTOCONF_VER=2.59
> > autoreconf --install --force --verbose
> > and I can still reproduce the bug. I can configure with the 
> "correct"
> > number of extra spaces though, but it later bugs out during 
> make so that
> > is a definite step backwards.
> 
> >> Which version of configure, automake, libtool are you using?
> 
> > autoconf 2.59 and automake 1.8.5 and an old libtool 
> (libtool is included
> > in libgii, I've had to throw quite a few patches at it to 
> make it work
> > with cygwin/mingw. I reported a dlltool/dllwrap problem to this list
> > earlier related to this and got the advise to use "gcc -shared").
> 
> autoreconf -force -install also  installs the new libtool, very good
> idea to do it, since patching the included libtool is error prone.

It might be a good idea in general, but not in this case IMO. I'm no
libtool guru though, so the build problem autoreconf causes might be
easy to fix.

The reason I have patched libtool is that the ggi maintainers are
waiting until after their next release to bring in the 1.5 series of
libtool. I decided not to wait for that.

> I'll try to build the latest release, where can I find a summary about
> all the recent patches / fixes?

I don't think there's a summary on the level you'd be interested in,
other than the cvs log of these files:
http://cvs.sf.net/viewcvs.py/ggi/ggi-core/libgii/m4/libtool.m4
http://cvs.sf.net/viewcvs.py/ggi/ggi-core/libgii/ltmain.sh
Look for commits by me, or commits by cegger referencing me as the
originator. Hmm, when scanning through that list, it looks as if most of
my changes are mingw related. The bottom line is that I have not kept
track of the changes.

It is entirely possible that the changes that has been made to libtool
are bogus. It is, as you say, error prone to fiddle with libtool.
Especially when you, as is the case for me, don't really know what
you're doing and are just making educated guesses. I did make it work
though.

There has also been changes made to the configure.in file
http://cvs.sf.net/viewcvs.py/ggi/ggi-core/libgii/configure.in

Most changes have been made to other parts of the tree but as I see it
those can't be related to this script argument parsing bug.

Otherwise, these pages list high level changes:
http://www.ggi-project.org/packages/libgii.html
http://www.ggi-project.org/packages/libggi.html

Here are some build instruction if you are going to go for the build or
gii/ggi. You will not need the DirectX SDK to reproduce the bug, do
however include the --with-extra-includes option, it is a good way to
trigger the bug. The bug can be triggered with other options as well
though.
http://cvs.sf.net/viewcvs.py/ggi/ggi-core/libgii/doc/README.directx?view
=markup
http://cvs.sf.net/viewcvs.py/ggi/ggi-core/libggi/doc/README.directx?view
=markup

All of the above is perhaps too much info to sift through and if you ask
me, blaming autotools is a red herring. The generated configure script
looks ok to me, and to further support that claim I have tested my
previosly provided steps to reproduce on Solaris, AIX, Linux and mingw
and have not been able to trigger the bug. That is, I have moved the
configure script that has been generated on and fails on cygwin to those
platforms and there is no problem. On the other hand, I can easily
reproduce on cygwin; that usually happens on the 1st, 2nd or sometimes
3rd attempt. Therefore, if you ask me, the problem is in script
execution/invokation, not in script generation.

Cheers,
Peter


--
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 to re-build Cygwin core package?

[Peter Rehley]

Might we be able to update the FAQ with this information?
On Aug 26, 2004, at 11:22 PM, Gernot Hillier wrote:
Hi!
Am Mittwoch, 25. August 2004 13:07 schrieb Gernot Hillier:
how to re-build Cygwin core package?
Just as reference for others - I now did it this way:
1.  Install Cygwin 2004-06-24, start bash
2.  Unpack the Cygwin core source package:
tar xvjf /cygdrive/e/release/cygwin/cygwin-1.5.10-3-src.tar.bz2
3.  Apply the needed patch (from
http://www.cygwin.com/ml/cygwin-patches/2004-q3/msg00039.html):
cd cygwin-1.5.10-3/winsup/cygwin && patch -p0 < /path/to/root.diff
4.	It's necessary to build Cygwin in an extra path, so create one and 
change
to it:

cd ../../.. && mkdir obj && cd obj
5.	To avoid Cygwin to overwrite the files of your make environment, an 
install
prefix is used:

../cygwin-1.5.10-3/configure --prefix=/fake/usr --sysconfdir=/fake/etc 
\
 --libexecdir=/fake/usr/sbin --localstatedir=/fake/var \
 --datadir=/fake/usr/share --mandir=/fake/usr/share/man \
 --infodir=/fake/usr/share/info

6.	Build and install the new Cygwin to the install prefix path given 
above:

make && make install
7.  Remove debug symbols from all executables:
cd /fake && find . -type f -exec strip {} \;
8.  Correct some file locations:
mv  usr/i686-pc-cygwin/bin/* usr/bin/
mv  usr/i686-pc-cygwin/lib/* usr/lib/
rm -rf usr/i686-pc-cygwin/bin usr/i686-pc-cygwin/lib usr/etc
mv  usr/i686-pc-cygwin/* usr/
9.  Create the w32api package:
tar cjf w32api-20040624-1.tar.bz2 usr/include/w32api usr/lib/w32api
10. Remove the files which belong to the w32api package from our tree:
rm -rf /fake/usr/include/w32api /fake/usr/lib/w32api
11. Create the mingw-runtime package:
tar cjf mingw-runtime-20040624-1.tar.bz2 usr/bin/mingwm10.dll \
   usr/doc/mingw-runtime usr/include/mingw usr/lib/mingw
12. Remove the files which belong to the w32api package from our tree:
rm -rf /fake/usr/bin/mingwm10.dll /fake/usr/doc/mingw-runtime \
   /fake/usr/include/mingw /fake/usr/lib/mingw
13.	Remove files which are distributed with other packages (but are 
included
in the cygwin source package for boot-strapping) or should not be 
distributed
at all:

rm -rf /fake/usr/include/iconv.h # comes also with libiconv
rm -rf /fake/usr/include/unctrl.h # comes also with libncurses-devel
rm -rf /fake/usr/share/info/configure.info-1 # auto-created by info 
tool
rm -rf /fake/usr/lib/libiberty.a # comes also with binutils

14.	Three files were not built and would need extra effort (i.e. 
compiling
other libraries be-fore the Cygwin package). Take them from the already
installed Cygwin distribution:

cp /usr/bin/dumper.exe usr/bin/
cp /usr/share/info/libc.info usr/share/info/
cp /usr/share/info/libm.info usr/share/info/
15. Finally, the cygwin package itself can be created:
tar cjf cygwin-20040624-1.tar.bz2 etc/ usr/
16.	Now, the created packages can be moved to the Cygwin installation 
CD-ROM
to release/cygwin/, release/mingw-runtime/ and release/w32api/ and the 
file
names, sizes and md5sums in setup.ini modified accordingly so that 
setup.exe
will in-stall the new core packages in the future.

HTH anyone...
--
Bye,
Gernot Hillier
CT SE 2
Siemens AG, Mch P
--
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/


--
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: can't open file for writing

[Peter Rehley]

On Sep 3, 2004, at 2:33 PM, C Schreiner wrote:
I can not save to a nonexistant file name under
Cygwin, but I can under Windows.
When I type:
   cat "hello" > foo.txt
Does the file "hello" exist?  Try echo "hello" > foo.txt
under Cygwin I get this error message:
   bash: foo.txt: No such file or directory
(unless foo.txt already exists in the current
directory).  This only happens with network
filesystems.  I know I have write permission because I
can create the file with "touch foo.txt", and I can
create the files with Windows Wordpad.  Other programs
under Cygwin also cannot create files, such as vim,
and co (from the rcs package).  Things work fine for
all programs on the local C: drive.
Why does this problem occur under Cygwin?  Is there
maybe a workaround?
I have not seen anything about this in the Cygwin FAQ
or in two mailing list archive searches.  If there is
already documentation about this, please point me to
it.
I am using Windows XP professional 5.1.2600 SP 1.0,
and Cygwin DLL version 1.5.10-3 (setup program version
2.427).
Thank you for your consideration,
Christian Schreiner
caschreirc (at) yahoo (dot) com
__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
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/


--
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] Updated: cygwin-1.5.11-1

[Peter Ekberg]

> - Fix mysterious configure script premature exit.  (Pierre Humblet)

I'm sorry to report that 1.5.11-1 does not fix this configure script
premature exit:

http://sources.redhat.com/ml/cygwin/2004-08/threads.html#01025

Is there any other output I can provide to help debug this?

Cheers,
Peter

--
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.5.11-1: sftp performance problem

[Peter Siebold]

I updated to the newest version of cygwin dll on 9/7/4 and after sftp
suffered performance issues when issuing a get on a large file.  File
transfers now stall and do not complete.  After downgrading to version
of 1.5.10-3 of cygwin sftp then it works fine.

Both configurations used openssh 3.9p1-1

This is the first time reporting a problem, so I hope I didn't miss
anything.

-Pete


cygcheck.out
Description: cygcheck.out
--
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.5.10: expr + configure failure + testcase (also on 1.5.11-1)

[Peter Ekberg]

Christopher Faylor wrote:

> On Mon, Sep 13, 2004 at 09:54:29PM -0400, Pierre A. Humblet wrote:
> >The surprise is that the error message:
> >"configure: error: invalid package name: extra-includes"
> >is produced at time 29722848 by bash 2624 (the main script 
> pid).  This
> >is BEFORE the second expr is exec'ed.  This occurs only at time
> >29725911 by a forked child 2656 of 2624 Following the output of the
> >error message, 2624 proceeds to fork 2384, which apparently does
> >nothing.  2624 then waits for 2656 and 2384 and exits.
> >
> >In other words the control flow seems to be seriously screwed up.  It
> >may be linked to the pid reuse problem in bash, but I know 
> very little
> >about it.  Looking at the full trace available from Peter may help.

I forgot I had that trace and accidentally deleted it. However, creating
a new one is not difficult, so one is available at:
http://www.lysator.liu.se/~peda/bashstrace.bz2

This one is created with "strace -o ..." as suggested by Igor.

> I was thinking the same thing but AFAIK, ash doesn't have the pid
> recycling problem.

Don't know where ash comes into play, the script is executed by bash. I
must have missed some other test case...

Cheers,
Peter

--
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.5.10: expr + configure failure + testcase (also on 1.5.11-1)

[Peter Ekberg]

Bogdan Vacaliuc wrote:
> In your *new* trace there are the same trace (on line 176632) 
> in the 'zone' between the fork() and the parent-shell exit decision
> point of your most recent trace.
> 
> Did you update your cygwin since your last run?  Perhaps its 
> just an artifact?  The set happens 4 times in your trace:

Yes, the new trace is with cygwin1.dll 1.5.11-1, the old one was
with 1.5.10-3, sorry if I didn't mention that...

Cheers,
Peter

--
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.5.10: expr + configure failure + testcase (also on 1.5.11-1)

[Peter Ekberg]

> On Mon, Sep 13, 2004 at 10:25:52PM -0400, Christopher Faylor wrote:
> >I will create a snapshot with double the number of pids cached in
> >cygwin.  This will cause the last 8 pids to be held from reuse by
> >windows.
> 
> Hmm.  I woke up this morning to see people busily flooding 
> the airwaves
> with more strace output but not a hint of anyone trying this snapshot.

Well, I was expecting a note when it was in fact available.

> Can someone try the snapshot please?

Tried it, and I'm not able to open a shell with it. I have rebooted, so
it's not some stray old process holding on to the previous dll.

What I did: bunzip2 of the snapshot dll, shut down all cygwin processes,
swapped in the snapshot dll as /bin/cygwin1.dll, ran the cygwin
shortcut.

The cmd window appears and disappears.

So then I tried to reboot, but no effect.

Cheers,
Peter

--
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 1.5.11-1 breaks the Hans Boehm-gc (garbage collector)

[Peter Hinely]

Hi,

It appears that Cygwin 1.5.11-1 break the Hans Boehm-gc (garbage collector), v6.2 and 
v6.3.  http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/

The gctest test application of the the boehm-gc runs correctly (it shows a passed 
result) compiled with gcc 3.3.1, 3.3.1, and 3.4.1
under Cygwin 1.5.10-3.  But the gctest application does not run correctly compiled 
with any of those gcc versions under the current Cygwin, Cygwin 1.5.11-1.

I searched the mailing list archive, but I did not find any mention of this problem.  
But another cygwin user that I know has found the same problem.  Is there a known fix 
for this issue?

Thanks,
Peter


--
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 1.5.11-1 breaks the Hans Boehm-gc (garbage collector)

[Peter Hinely]

Hi,

Additional info:

I meant to say "gcc 3.3.1, 3.3.3, and 3.4.1" in my first email.

I am running Windows XP, SP1.  

I compiled and tested the boehm-gc that's under the GNU gcc project's source tree 
(used by the GNU java compiler), and it also fails the gctest with Cygwin 1.5.11-1, 
but works with Cygwin 1.5.10-3.

Regards,
Peter

>>> [EMAIL PROTECTED] 09/14/04 04:26PM >>>
At 10:24 PM 9/14/2004, you wrote:
>Hi,
>
>It appears that Cygwin 1.5.11-1 break the Hans Boehm-gc (garbage collector), v6.2 and 
>v6.3.  http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/ 
>
>The gctest test application of the the boehm-gc runs correctly (it shows a passed 
>result) compiled with gcc 3.3.1, 3.3.1, and 3.4.1
>under Cygwin 1.5.10-3.  But the gctest application does not run correctly compiled 
>with any of those gcc versions under the current Cygwin, Cygwin 1.5.11-1.
>
>I searched the mailing list archive, but I did not find any mention of this problem.  
>But another cygwin user that I know has found the same problem.  Is there a known fix 
>for this issue?


This problem has not been reported previously.  


--
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.5.10: expr + configure failure + testcase (also on 1.5.11-1)

[Peter Ekberg]

Christopher Faylor wrote:
> Grr...  This was the newlib problem previously mentioned.  I forgot to
> generate the snapshot in such a way as to work around this problem.
> 
> The new snapshot should work better.

Indeed it does. I have tried a couple of times without any hickups.
With 1.5.11 a have not been able to get my testcase to even pass
once if straceing. With this snapshot I now have 5 consecutive
successes (and no failures).

I'm afraid I don't understand the issue and why the temporary change
in the snapshot points at bash, so someone else is probably better
suited to notify the bash maintainer. (If the evidence in this message
qualifies as confirmation.)

BTW, thanks for helping out with debugging!

Cheers,
Peter

--
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: Program terminates with "cygheap version mismatch detected"

[Peter Rehley]

On Sep 15, 2004, at 5:54 AM, Joshua Wright wrote:
Jörg Schaible wrote:
c:\DEV\testing\asleap.exe (988): *** cygheap version mismatch 
detected - 0x6178/0xBF. You have multiple copies of 
cygwin1.dll on your system.

From your cygcheck output I've seen that you have or had a B15
running ... do you still use it? Even it the dll name is cygwin.dll
(just a guess, B15 was not my time ), it might already allocate
the same shared memory than cygwin1.dll.
I tried to remove all instances of Cygwin from my system in an effort 
to troubleshoot:
 + Did a find with regedit and removed any keys with "cyg" in them
 + Removed the c:\cygwin tree
 + Did a Windows Find on "cyg" and removed all files

Reinstalled cygwin, rebooted.  Same error. :(
Any other thoughts?  Possibly a problem with Windows XP SP2?  I'm not 
sure what to try next
Maybe off the wall, but keep the program that you are trying to run.  
Remove the cygwin tree (c:\cygwin) and then try running the exe again.  
See what happens.  If the program runs, then there is a cygwin1.dll 
outside of the tree.  Check the path that the program uses to see where 
the dll might be lurking.

Could the dll have a different name then cygwin1?  Where I work we've 
created a special dll with a different name to prevent cross over 
problems from the regular cygwin dll.  When running a regular cygwin 
program in this custom space (i.e. start from bash in custom 
environment) the error message you've seen appears.

Again off the wall things to try and check.
Peter
--
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/

DirectX headers

[Peter Ekberg]

Hello!

I'm working on a project (GGI) that uses DirectX (DirectInput and
DirectDraw) and would like to be able to compile it without downloading
the DirectX SDK from Microsoft. So, I tried to get it to work with the
DirectX headers available in Wine and this was a success after some
trivial #define games and some reordering.

Now, my wish is to share this possibility with others and have these
modified headers (dinput.h and ddraw.h) in the regular cygwin dist.
However, they are licensed under LGPL, and I don't know if that is a
problem? Do I have to get the Wine people to relicense them under
regular GPL?

Cheers,
Peter


--
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 in Cygwin-X...

[Peter Rehley]

On Sep 16, 2004, at 10:38 PM, Moises Deangelo wrote:
Please
I installed cygwin in my windows 2000 with service pack 4.
I download the complete version of cygwin.
But the graphic interface does not work by any means
Cygwin-X does not run.
Any applications do not accuse no mistake, simply do not initiate.
Other introduce the following mistake:
RUN.EXE
ERROR: could not start C:\cygwin\usr\X11R6\xdvi -display 127.0.0.1:0.0
Can anybody help to do the graphic interface to work?
Have you checked out the following site?
http://x.cygwin.com/
My guess is that the X Server isn't running (did you do startx?)
Also, it's been said before, but check out
http://cygwin.com/problems.html
Peter
--
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: Bash returns incorrect process status

[Peter Ekberg]

Pierre A. Humblet wrote:
> FWIW, attached is a patch to bash that may improve its 
> behavior on Cygwin.
> The idea is that when a new process is stored in the memory array, any
> existing process with the same pid is marked "reused". 
> "reused" processes
> are never considered when searching for a process by pid. 
> They are still
> still available, e.g. to get the status of processes in a job. 
> 
> It's a proof of principle code, not meant to be efficient. It 
> can still print
> a debug message on stderr.

Tried it and it doesn't solve the problem for me. It shifts the trigger
pattern though.

Without the patch, an almost sure thing to do to trigger the bug is to
run the configure script under "strace bash". But with the patch, I have
not been able to trigger the bug once.

However, just running the configure script without straceing bash
triggers the bug at about the same rate as without the patch (I estimate
that between 1/3 and 1/2 of the runs fail).

But wait, now I tried to trigger the bug with the original bash and that
also fails when straceing. So I guess my remark about the shift in
trigger pattern is not certain...

/me makes a note of the phase of the moon

I have not noted any occurance of the "Found old pid..." message. Is
that an indication that the patch never kicks in?

Cheers,
Peter

--
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: apache2 as service

[Peter Rehley]

On Sep 17, 2004, at 9:18 AM, Prakash Khemani wrote:
Hi,
I compiled & installed apache2 on cygwin+WinXP. I am able to use it 
fine
- but I am not able to install it as a service.

The run as User in the httpd.conf file is SYSTEM.
I installed apache2 asa service using the following command
cygrunsrv -I cygapache -p /usr/local/apache2/bin/httpd.exe -a "-k 
start"
-t auto

I'll assume that it seemed to install correctly.  As a quick simple 
sanity check try typing the command in a bash prompt and see what 
happens.  Make sure that starts ok.  If it goes to the background, you 
will need to find the parameter that keeps apache in the foreground.  
cygrunsrv needs this.  Otherwise it can say that the service has not 
started when it is running.

When I try to start it
cygrunsrv -S cygapache
I get the following error
cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error
1062:
The service has not been started.
Nothing is written to /var/log/cygaapche.log or to
/usr/local/apache2/log/error_log
Check the windows event viewer for more logs.  Might be nothing, but 
might also give hints to what may be happening.

The pid stored in httpd.pid changes but the httpd processes don't show
up on doing ps -ae
Almost sounds like apache wants to start, but is encountering a problem.
What am I doing wrong?
I compiled and installed apache2 as the network user ENG/khemani. I had
to change the permissions on apache2/logs directory to be able to run
apache2 as the user SYSTEM.
What more should I do?
Configuration problems.  File permissions.  Check them all.
Thanks,
Prakash
--
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/

A Møøse once bit my sister
--
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: So how do you uninstall Cygwin?

[Peter Rehley]

On Sep 17, 2004, at 11:50 AM, Igor Pechtchanski wrote:
On Thu, 16 Sep 2004, Brian Dessent wrote:
lukekendallcisracanoncomau wrote:
  ^^
Tut-tut.  . ;-)
It occurred to me, while trying to work out why ssh isn't working on 
a
laptop that we installed Cygwin on recently, to wonder whether the
information at http://cygwin.com/faq/faq_2.html#SEC19 (How do I 
uninstall
all of Cygwin?) could be a little more helpful.

It gives good advice, but ends by saying:
It's up to you to deal with other changes you made to your
system, such as installing the inetd service, altering system
paths, etc. Setup would not have done any of these things
for you.
This is true.  But for ssh, and other packages, is there any useful
advice that could be given on how to uninstall?
I'm wondering how I get the machine back into a pristine state to 
try a
re-install, since perhaps some of our post-install changes screwed
things up.  (ssh normally works just fine.)
Remove any services you might have installed ("cygrunsrv -R ssh") and
FWIW, I have been thinking of implementing a --list option to cygrunsrv
that would list all the Cygwin services installed with cygrunsrv.  At 
this
point I have no implementation, though.
Another feature that would be helpful is an option to show what program 
and the options associated with the program.  It would prevent hunting 
through the registry when debugging problems.


remove all entries from the mount table ("umount -a") and that should
pretty much do it, assuming of course you removed the main 
installation
directory as well.
Well, one could always add an "Uninstall all" radio button to 
setup.exe's
action screen.   :-)
	Igor
--
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_		[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_		[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in 
doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

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

A Møøse once bit my sister
--
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: So how do you uninstall Cygwin?

[Peter Rehley]

On Sep 17, 2004, at 12:11 PM, Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Igor Pechtchanski
Sent: 17 September 2004 19:50

FWIW, I have been thinking of implementing a --list option to
cygrunsrv
that would list all the Cygwin services installed with
cygrunsrv.  At this
point I have no implementation, though.
  Rather than run through the list of services and try and deduce 
which ones
are cygwin services, the simplest implementation might just be for 
cygrunsrv
to add a 'created_by_cygrunsrv' value into the service key in
HKLM/CCS/Services, which it can come back and look for later.
Looking for cygrunsrv is usually good enough.
cheers,
  DaveK
--
Can't think of a witty .sigline today
--
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/

A Møøse once bit my sister
--
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: apache2 as service

[Peter Rehley]

On Sep 17, 2004, at 3:11 PM, Igor Pechtchanski wrote:
On Fri, 17 Sep 2004, Prakash Khemani wrote:
Check the windows event viewer for more logs.
Windows event viewer has errors saying that the cygapache service
terminated unexpectedly.
What, no more information?
Actually, this is pretty normal.  Sometimes you might catch something.  
But in my experiences, those times have been rare.

--
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: special install

[Peter Rehley]

On Sep 23, 2004, at 10:32 AM, Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of J. David Boyd
Sent: 23 September 2004 18:16

"Calman, Jack" writes:
Hi,
 Our group is interested in installing cygwin on a group of
classified
computers that are not connected to the internet. Would you
please tell me
how to download what I need from the internet. Then I'll
put it on a CD,
carry it into the classified room, and then install on the
computers there.
 Thanks,
 - Jack Calman
Johns Hopkins University
Applied Physics Lab
Laurel, MD

After you have a working installation on any computer, you can zip and
copy the C:\CYGWIN directory.  It is totally self contained, and
should work fine anywhere.
  Nonsense!  That method won't create any mount points in the 
registry, nor
will it run any post-install scripts.  The correct method is to run
setup.exe, select 'Download from internet', download everything, burn 
the
temporary storage directory to cd along with a copy of setup.exe, then 
on
each enduser machine you run setup.exe and tell it to 'Install from 
local
directory', pointing at the download dir that you burnt to CD.
Actually, what the person mention would work.  Only thing left out 
would be the registry settings.  If the user has a working copy then 
everything is already set up in the cygwin directory.  Copying this to 
another machine would be perfectly fine.  I know because I've done 
something like this before and it has worked for me.

Potential problems could arise in
1) Registry settings.  These would need to be exported.  Actually, I 
think if they don't exist cygwin will create registry setting minus the 
mount points.  The mount points would need to be adjusted or imported 
from the original.  This could also be part of the zip file.
2) post-install scripts have already be run via initial setup.  However 
something would need to be done if any of the programs are set up as 
windows services.
3) passwd file.  If the same users exist on each machine, then this 
isn't an issue.  However domain users would need to be added.  This 
could be done before zipping cygwin directory.

cheers,
  DaveK
--
Can't think of a witty .sigline today

Enjoy,
Peter
--
A Møøse once bit my sister
--
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: special install

[Peter Rehley]

On Sep 23, 2004, at 10:54 AM, Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Peter Rehley
Sent: 23 September 2004 18:44

  Much snippage, just to summarize the essence of the post and it's 
role in
the conversation:

After you have a working installation on any computer, you can zip and
copy the C:\CYGWIN directory.  It is totally self contained, and
should work fine anywhere.


2) post-install scripts have already be run via initial
setup.

  So, in other words, what you're claiming is that
"It would work, but it won't create any mount points in the registry, 
nor
will it run any post-install scripts".
ummm, I'm saying that the post install scripts have already been run.  
And also giving suggestions on things that are missing.

  Well, thanks for that helpful clarification from the Department of
Redundancy Department!
Glad to be of service. Didn't I mention that before ;)

cheers,
  DaveK
--
Can't think of a witty .sigline today

Enjoy,
Peter
---
A Møøse once bit my sister
--
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: special install

[Peter Rehley]

On Sep 23, 2004, at 11:36 AM, Igor Pechtchanski wrote:
On Thu, 23 Sep 2004, Peter Rehley wrote (heavily [snip]ped):
3) passwd file.  If the same users exist on each machine, then this 
isn't an
issue.
This is *wrong* (and is the main reason I'm sending this mesage,
actually).  WinNT/2k/XP machines have a notion of "SID" that they give 
to
each user.  That SID is different on different machines, even if the 
user
name is the same.  User SIDs are stored in /etc/passwd, so an 
/etc/passwd
from one machine will be useless on another.
D'oh.  I knew this.

However domain users would need to be added.  This could be done
before zipping cygwin directory.
Again, wrong.  Domain user SIDs are actually the same across the 
domain,
so the domain users in /etc/passwd will be ok.

Actually, I still think this would be ok for domain users.  My point 
being that you need to add domain users at some point since the default 
setup doesn't create domain users.  However, the suggestions you and 
other have given regarding the creation of the passwd file is the right 
way to go.

Enjoy,
Peter
---
A Møøse once bit my sister
--
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: File permission problem

[Peter Rehley]

This sound suspiciously like the files are on a FAT32 file partition.  
Are they?

On Sep 23, 2004, at 8:32 PM, <[EMAIL PROTECTED]> wrote:
Yes. But I have already export the environment variable "ntsec" and
restart cygwin. But chmod still doesn't work. Do I need to run any
server in order to activate the change?
Jacky
-Original Message-
From: Larry Hall [mailto:[EMAIL PROTECTED]
Sent: Friday, 24 September, 2004 10:52
To: Jacky Lam; [EMAIL PROTECTED]
Subject: Re: File permission problem
At 09:59 PM 9/23/2004, you wrote:
Dear all,
   I have try to generate a private key file so that I don't need
to enter password everytime I "ssh" to a remote machine. However, 
"ssh"
complaints me about the permission of key file. I don't know why
"chmod"
always return 666 or 444 even I want to change the file to 600 or 400.
   Does anymore have idea? Thanks.

Does this describe your situation?
Why doesn't chmod work?
<http://cygwin.com/faq/faq_toc.html#TOC41>
--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746
--
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/
--
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/

Enjoy,
Peter
---
A Møøse once bit my sister
--
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: SableVM & Cygwin (was: Re: sablevm + windows)

[Peter Lovell]

Hi Gerrit,
many thanks for this. Great !
Speaking only for myself, I believe that option (2) would be the 
appropriate one. It might be nice to include it also back to gcc but I 
suspect that sablevm developers might prefer to not have that 
dependency.

I'll fetch your patches and test and let you know.
Many thanks.Peter
On Oct 13, 2004, at 11:57 AM, Gerrit P. Haase wrote:
Hi Peter,
coming back to this now.
I'm also willing to help port and maintain.
Fine.  I have to offer two possible scenarios.
1.
I have a stripped down standalone libffi package with a shared libffi
now.  This version is based on the sources from the cygwin release of
gcc-3.3.3. You can take this package and maintain it, that means update
it when Cygwin GCC is updated and integrate the changes happened in the
libffi subdirectory.
2.
Include this stripped down libffi version with the SableVM sourcetree
and link libffi into the main DLL as a convenience library.
IMO it would be easier to keep it uptodate when it is included with the
SableVM sources and also distributed this way.  So one can continue 
when
you or me are gone.

I have a patch I can send you, there is the stripped down libffi
integrated in the SablVM build.  The standalone libffi is available as
separate package from my webserver:
http://anfaenger.de/cygwin/cygwin-1.5/libffi-cygwin-standalone/
Ready compiled SableVM binary and source package:
http://anfaenger.de/cygwin/cygwin-1.5/saqblevm/
The source package includes also the patch and uses a statically 
libffi,
so it doesn't need a FFI DLL.  Could you verify that this SableVM works
as expected, please?

Classpath is still compiling.
Gerrit
--
=^..^= 
http://nyckelpiga.de/donate.html

___
SableVM-devel mailing list
[EMAIL PROTECTED]
http://sablevm.org/lists/control/listinfo/sablevm-devel

--
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: Installing from downloaded files or CD

[Peter Flynn]

On Tue, 2004-09-28 at 19:12, Jan Nieuwenhuizen wrote:
> Peter Flynn writes:
> 
> > error: libkpathsea3abi13 not in [curr]
> > error: libkpathsea3abi13 no install
> 
> Sorry.  This *is* a showstopper.  I've updated cyg-apt.  This time
> I've tested it too (under Wine), and it works fine.

Thanks very much, it all seems to download fine now...but...

> If you get setup.exe problems (crashes), please report them to
> [EMAIL PROTECTED]; I have seen bug reports for Windows XP for the
> latest version.

I burned it all to CD:

> [tmp]$ ls -l lily
> total 296
> -rwxrwxr-x1 peterpeter   18246 Sep 28 19:09 cyg-apt
> drwxrwxr-x3 peterpeter4096 Sep 29 10:30 etc
> drwxrwxr-x3 peterpeter4096 Sep 29 10:30
> http%3a%2f%2fmirrors.rcn.net%2fpub%2fsourceware%2fcygwin
> -rw-rw-r--1 peterpeter  268800 Apr 25 16:03 setup.exe
> [tmp]$ du -s lily
> 39532   lily
> [tmp]$

But installing it on an NT machine broke setup.exe. It started off fine,
checked all the MD5s down as far as lilypond-2.2.5-1, and then popped up
a window saying:

> Microsoft Visual C++ Runtime Library
> 
> Runtime Error!
> 
> Program E:\lily\setup.exe
> 
> abnormal program termination

The NT system is fully updated, and I'm not a Windows person, so I'm 
stuck at this stage. Clicking OK aborts the setup.

///Peter



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

ssh appear to hang; xauth; X forwarding

[Peter Ring]

Recently, probably after upgrading ssh to openssh-3.9p1-2, ssh appeared to hang, 
whether invoked by itself or as transport for cvs.

Well, the culprit was xauth, or rather X forwarding. Starting ssh invoked xauth which 
subsequently hung because X wasn't running, even though DISPLAY was defined.

Unsetting DISPLAY if X isn't running will cure the problem.

kind regards
Peter Ring



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

Missing declaration for siginterrupt

[Peter Ekberg]

Hello!

I miss a declaration for siginterrupt(3). Should there
not be one in signal.h or somewhere?

Background:

Make in a package that needs it ends with:
error: implicit declaration of function `siginterrupt'

Yes, I know that I don't need to specify
-Werror-implicit-function-declaration, but I didn't write
configure.in this time...

Cheers,
Peter

--
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: sablevm + windows

[Peter Lovell]

Hi Grzegorz,
On Oct 8, 2004, at 3:18 AM, Grzegorz B. Prokopski wrote:
On Thu, 2004-10-07 at 18:45, Peter Lovell wrote:
I was not able to check out Mélanie's sandbox in the way you suggested
($ svn co svn+ssh://svn.sablevm.org/public/developers/mlord
sablevm-mlord) probably because I don't have an ssh account. However
I was able to  fetch svn.sablevm.org/developers/mlord/sandbox
which hopefully is the same (disabuse me of that notion if 
appropriate).
Yes, it's the same.
Thanks for the confirmation.

The porting document there was very helpful and for our use I've
translated it into English. It's in the same format and not wiki-ized,
but even so it may be useful to have on sablevm.org -- just let me 
know
where.
Could you please put it up on a web page somewhere and provie an URL?
It will be easiest to mail it to you (it's not huge). I'll do that 
separately.

I'm still having a problem getting a proper version of libffi built,
and will attack that further tomorrow. Part of the problem is that I'm
not very familiar with auto* tools (but learning rather quickly).
If you take a look at thread that started here:
http://sablevm.org/lists/sablevm-devel/2004-September/64.html
Thanks for that info. I'm working on this today and will let you know 
how it goes.

If SableVM was to become part of applications available for Cygwin
(which I hope will happend) we'd want it to be "mostly/easily 
buildable"
with tools and libraries Cygwin provides (like it takes place in Debian
or Gentoo).
This is our direction also. Ideally it would be mingw or even 
ms-native. The latter will be much harder, but mingw would be great.

Regards.Peter
--
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: sablevm + windows

[Peter Lovell]

Hi Gerrit,
On Oct 8, 2004, at 8:59 AM, Gerrit P. Haase wrote:
Grzegorz wrote:
On Thu, 2004-10-07 at 18:45, Peter Lovell wrote:
I was not able to check out Mélanie's sandbox in the way you 
suggested
($ svn co svn+ssh://svn.sablevm.org/public/developers/mlord
sablevm-mlord) probably because I don't have an ssh account. However
I was able to  fetch svn.sablevm.org/developers/mlord/sandbox
which hopefully is the same (disabuse me of that notion if 
appropriate).

Yes, it's the same.
Is there a snapshot available?  I would like to try a build of SableVM.
[...]
The most recent released version is available from
<http://sablevm.org/download/release/1.1.6/>

If SableVM was to become part of applications available for Cygwin
(which I hope will happend) we'd want it to be "mostly/easily 
buildable"
with tools and libraries Cygwin provides (like it takes place in 
Debian
or Gentoo).
You're going to volunteer to maintain SableVM?  I 'm willing to help
to get it ported if you're going to maintain the result as a package.
I'm also willing to help port and maintain.
Regards.Peter
--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

Chuck wrote:
> New alpha versions of libtool available for test.  This is
> very close to
> what libtool-2.0 will be.  Please evaluate.
> 
> NOTE: cygwin maintainers: do NOT release any updates of your packages
> built using this version of libtool!  Be sure to revert back to
> "regular" libtool-devel ("1.5.10-1") before packaging any of your
> "stuff" for official releases.
> 
> This version passes ALL existing libtool selftests on cygwin, for the
> first time ever. 

I have one problem with libtool 1.9d, that I suspect is still present
in 1.9f. If I specify -lpthread when linking, libtool searches for a
real file matching -lpthread, like this:

*** Warning: linker path does not have real file for library -lpthread.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libpthread and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libpthread.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

Now, I *know* that I don't need to specify -lpthread. But I would like
libtool to not search for the real file in this case, just as it does
not search for a real file if I specify -lc or -lm.

Because of this, libtool fails to build the dll in question, which is a
pity.

Cheers,
Peter

--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

Reini Urban wrote:
> Peter Ekberg schrieb:
>> I have one problem with libtool 1.9d, that I suspect is still present
>> in 1.9f. If I specify -lpthread when linking, libtool searches for a
>> real file matching -lpthread, like this:
>> 
>> *** Warning: linker path does not have real file for library
>> -lpthread. 
>> *** I have the capability to make that library automatically link in
>> when 
>> *** you link to this library.  But I can only do this if you have a
>> *** shared version of the library, which you do not appear to have
>> *** because I did check the linker path looking for a file starting
>> *** with libpthread and none of the candidates passed a file format
>> test 
>> *** using a file magic. Last file checked: /lib/libpthread.a
> 
> Then you have a binutils problem. The new magic for /lib/libpthread.a
> tells libtool that this is the import library. (which normally would
be
> called libpthread.dll.a)

Actually I don't think I have problems with binutils, but thanks for
the useful pointer.

I have this in the generated libtool script:
--8<
# Method to check whether dependent libraries are shared objects.
deplibs_check_method="file_magic ^x86 archive import|^x86 DLL"

# Command to use when deplibs_check_method == "file_magic".
file_magic_cmd="func_win32_libid"
------8<

Is that what is expected?

If I change to
deplibs_check_method="file_magic"
it works.

Any suggestions?

Cheers,
Peter


--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

Reini Urban wrote:
> Peter Ekberg schrieb:
>> Reini Urban wrote:
>>> Peter Ekberg schrieb:
>>> 
>>>> I have one problem with libtool 1.9d, that I suspect is still
>>>> present in 1.9f. If I specify -lpthread when linking, libtool
>>>> searches for a real file matching -lpthread, like this:
>>>> 
>>>> *** Warning: linker path does not have real file for library
>>>> -lpthread. 
>>>> *** I have the capability to make that library automatically link
>>>> in when 
>>>> *** you link to this library.  But I can only do this if you have a
>>>> *** shared version of the library, which you do not appear to have
>>>> *** because I did check the linker path looking for a file starting
>>>> *** with libpthread and none of the candidates passed a file
>>>> format test 
>>>> *** using a file magic. Last file checked: /lib/libpthread.a
>>> 
>>> Then you have a binutils problem. The new magic for
>>> /lib/libpthread.a tells libtool that this is the import library.
>>> (which normally would be called libpthread.dll.a)
>> 
>> 
>> Actually I don't think I have problems with binutils, but thanks for
>> the useful pointer.
> 
> I think you do have. up-to-date?

Yes.

>> I have this in the generated libtool script:
>> --8<
>> # Method to check whether dependent libraries are shared objects.
>> deplibs_check_method="file_magic ^x86 archive import|^x86 DLL"
>> 
>> # Command to use when deplibs_check_method == "file_magic".
>> file_magic_cmd="func_win32_libid"
>> --8<
>> 
>> Is that what is expected?
> 
> yes, I posted the relevant snippet of this func_win32_libid function,
> so that you can check what's going on with your objdump and nm on
> your libpthread.a But you have a different/unsupported build so you
> should really step through your relevant func_win32_libid() function.

Ok, I pinpointed the problem. It wasn't a problem with binutils but
rather with configure.in. After a recent run of autoupdate it
contained:
_LT_SET_OPTION([disable-static])
_LT_SET_OPTION([dlopen])
_LT_SET_OPTION([win32-dll])
LT_INIT
(with some other stuff in between)

Changing that to
LT_INIT([disable-static dlopen win32-dll])
fixes the problem which was that $OBJDUMP was empty.

AC_CHECK_TOOL(OBJDUMP, objdump, false), among other things, wasn't
expanded without the above change in configure.in.

Thanks for the help, and sorry for the confusion.

(But I still think I have a point in that libtool should drop
 -lpthread just as it drops -lc and -lm. Why doesn't libtool
 drop -lpthread?)

Cheers,
Peter

--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

Chuck wrote:
> New alpha versions of libtool available for test.  This is
> very close to
> what libtool-2.0 will be.  Please evaluate.
> 
> NOTE: cygwin maintainers: do NOT release any updates of your packages
> built using this version of libtool!  Be sure to revert back to
> "regular" libtool-devel ("1.5.10-1") before packaging any of your
> "stuff" for official releases.
> 
> This version passes ALL existing libtool selftests on cygwin, for the
> first time ever. 

I have a problem with "make install" of a built executable.

Its wrapper script contains:
---8<
relink_command=""

# This environment variable determines our operation mode.
if test "$libtool_install_magic" = "%%%MAGIC variable%%%"; then
  # install mode needs the following variable:
  notinst_deplibs=''
else
---8<

and make install fails with:

libtool: install: invalid libtool wrapper script `xsendbut'

This is because this test is true in ltmain.m4sh:
---8<
  # Check the variables that should have been set.
  test -z "$notinst_deplibs" && \
func_fatal_error "invalid libtool wrapper script
\`$wrapper'"
---8<

Adding a space between the '' in the wrapper script makes it
work, of course.

It should be noted that this was with libtool-cvs rather
shortly before 1.9f hit the street, so it was not with the
exact version you refer to here. Very close though, and I
see no changes that should affect this behaviour.

Cheers,
Peter


--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

Chuck wrote:
> New alpha versions of libtool available for test.  This is
> very close to what libtool-2.0 will be.  Please evaluate.

I have further problems in that linking against -ldxguid prevents
a library from being linked as a dll. I only get a static lib,
which is not what I want.

I realize that /lib/w32api/libdxguid.a is not an import library,
but I have no problems with the generated dll if I disable the
test that prevent libtool from linking the dll.

Is this to be expected? If so, is there a recommended way to work
around it?

Cheers,
Peter

--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

Chuck wrote:
> Peter Ekberg wrote:
>> I have a problem with "make install" of a built executable.
> In your case, you have a wrapper script -- but an empty
>   noninst_deplibs. One of two things is true:
> 
> (1) your exe really truly does not depend on any uninstalled
> libraries. --> so need to investigate WHY a wrapper script was
> created at all.

It does not. The reason seems to be that $wrappers_required
does not get set to "no" since $build_libtool_libs is "yes"
in this snippet from the libtool script:
---8<--
  wrappers_required=yes
  case $host in
  *cygwin* | *mingw* )
if test "$build_libtool_libs" != yes; then
  wrappers_required=no
fi
;;
  *)
if test "$need_relink" = no || test "$build_libtool_libs" !=
yes; then
  wrappers_required=no
fi
;;
  esac
---8<--

$build_libtool_libs gets set to "yes" in the very beginning
of the libtool script and is not changed after that.

If I add this project specific brown-paper-bag hack to the
mix, "make install" works correctly:
---8<--
if test "$outputname" = "xsendbut.exe" ; then
  wrappers_required=no
fi
---8<--

> Needless to say, I haven't observed that behavior here.
> 
> BTW, does your version of libtool contain this ChangeLog entry?
> 
> 2004-10-09  Charles Wilson  
> 
>  * config/ltmain.m4sh (func_mode_link): don't relink
>  on cygwin/mingw; no need.  But do ensure that wrappers
>  are created unless doing a purely static build.
> 
> 'cause it touches exactly this bit of code.

That patch is in there, the guy who merged libtool-1.9-cvs
into the project claims that the only difference between our
libtool version and 1.9f is the version number (and a totally
unrelated local FreeBSD fix)...

BTW, this is the command that generates the wrapper script
when it shouldn't:
/bin/sh ../libtool --mode=link --tag=CC gcc  -g -O2 -D_REENTRANT
-D_THREAD_SAFE -DDEBUG -g -Wall -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wswitch -Wmissing-prototypes -Wreturn-type -Wshadow
-o xsendbut.exe  xsendbut.o -L/usr/X11R6/lib -lX11

I should perhaps note that xsendbut resides in a directory
where other executables are built that do indeed depend on
uninstalled libtool libs, if that is at all relevant?

On the off chance that you (or someone else) want to get
first hand experience of the problem, try libgii from cvs
available from:

cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/ggi login 
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/ggi co ggi-core/libgii
cd ggi-core/libgii
./autogen.sh
./configure
make
make install

xsendbut is in the demos subdir.

Cheers,
Peter


--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

Chuck wrote:
> New alpha versions of libtool available for test.  This is
> very close to what libtool-2.0 will be.  Please evaluate.

"make install-strip" on a shared library strips the import
lib, not the dll which was what I was hoping for.

Not a show-stopper I suppose...

 /bin/sh ../libtool --mode=install /usr/bin/install -c -s 'libgg.la'
'/usr/lib/libgg.la'
/usr/bin/install -c .libs/libgg.dll.a /usr/lib/libgg.dll.a
strip --strip-unneeded /usr/lib/libgg.dll.a
base_file=`basename ${file}`
 dlpath=`/bin/sh 2>&1 -c '. .libs/'${base_file}'i;echo $dlname'`
 dldir=/usr/lib/`dirname $dlpath`
 test -d $dldir || mkdir -p $dldir
 /usr/bin/install -c .libs/cyggg-0.dll $dldir/cyggg-0.dll
/usr/bin/install -c .libs/libgg.lai /usr/lib/libgg.la

Cheers,
Peter

--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

Chuck wrote:
> Gerrit P. Haase wrote:
>>> "make install-strip" on a shared library strips the import
>>> lib, not the dll which was what I was hoping for.
>>> Not a show-stopper I suppose...
>> 
>> Yes, this is a showstopper!  Import libraries may be broken after
>> stripping.
> 
> I'm going out of town for a few days, so in the words of a very wise
> man: 
> 
> patches gratefully considered

Here you go...

Patch against libtool-1.9f, works for me

Cheers,
Peter


install-strip.patch
Description: install-strip.patch
--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

Chuck wrote:
> It seems like a design decision was made, that IF in a given project
> there are ANY libtool libs, then libtool will "know" about it
> by having
> build_libtool_libs set to "yes".  And thus, every executable is
> *assumed* to be linked against those libs, and will therefore have a
> wrapper and be linked against those shared libs.

I have this feeling also. The right thing to do would perhaps be
to not generate the wrapper in the first place, but that feels
more complex than your proposal below...

> Except in your case, you have ONE executable that is NOT
> linked against
> any shared libs...and the wrapper-check fails.
> 
> Maybe the right answer here is to change the check so that instead of
> 
># Check the variables that should have been set.
>test -z "$notinst_deplibs" && \
>  func_fatal_error "invalid libtool wrapper script
> \`$wrapper'" 
> 
> it checks for some other magic instead (which would need to
> be added to
> the "make a wrapper" code)
> 
># Check the variables that should have been set.
>test -z "$generated_by_libtool_version" && \
>  func_fatal_error "invalid libtool wrapper script
> \`$wrapper'" 
> 
> where the "make a wrapper" code ensures that the following assignment
> appears in the wrapper 
> 
> ORIG> if test "$libtool_install_magic" = "%%%MAGIC variable%%%"; then
> ORIG>  # install mode needs the following variables:
> ORIG>  notinst_deplibs=
> NEW >  generated_by_libtool_version=$macro_version
> ORIG> else
> 
> 
> Our check wouldn't care about the actual VALUE of
> $generated_by_libtool_version -- only that it was, in fact, set to
> SOMETHING. 
> 
> 
> Can't flesh this out anymore right now, but you get the idea...

Yup, clear enough, here's a patch that does as you outlined. It
even works :-). Thanks a bunch!

Only one Cygwin related problem left on my list for libtool-1.9f,
and that is linking a libtool shared lib against
/usr/lib/w32api/libdxguid.a which is not recognized as an import
lib (and probably isn't one either, I don't know). But it works
to link a dll against it if I make it pass the import check by
brute force...
Any hints for that one?

Cheers,
Peter



install-nodeps-wrapper.patch
Description: install-nodeps-wrapper.patch
--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

I wrote:
> Chuck wrote:
>> Gerrit P. Haase wrote:
>>>> "make install-strip" on a shared library strips the import
>>>> lib, not the dll which was what I was hoping for.
>>>> Not a show-stopper I suppose...
>>> 
>>> Yes, this is a showstopper!  Import libraries may be broken after
>>> stripping.
>> 
>> I'm going out of town for a few days, so in the words of a very wise
>> man: 
>> 
>> patches gratefully considered
> 
> Here you go...
> 
> Patch against libtool-1.9f, works for me

Here's an update that properly quotes the argument to exit, I think.
It also removes os2 from the mix, as os2 does not seem to work with
import libs. At least not in the same way as cygwin/mingw/pw32...

Cheers,
Peter



install-strip2.patch
Description: install-strip2.patch
--
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/

IOC of UNESCO: survey on the IODE programme

[Peter Pissierssens]

If you are not involved in marine sciences/oceanography then please send a
blank message to [EMAIL PROTECTED] 

Dear colleague,

The "International Oceanographic Data and Information Exchange" (IODE)"
programme (http://www.iode.org) of the "Intergovernmental Oceanographic
Commission of UNESCO (IOC)" was established in 1961 to enhance marine research,
exploitation and development by facilitating the exchange of oceanographic data
and information between participating Member States and by meeting the needs of
users for data and information products.

The IOC is now undertaking a review of the IODE programme so we can ensure
that IODE effectively and efficiently addresses the needs of the ocean
science and observation community.
We believe that the best way to find out how we can better serve your needs
is by asking you, a marine expert, directly.  We therefore designed a short
web-based survey. The survey can be found on the following URL:
http://www.surveymonkey.com/s.asp?u=71514696388

Filling this survey will take only 5 minutes. It is subdivided in 5 pages
and has a total of 35 questions, most of which are answerable by picking from
a list of options. 

We thank you in advance for your cooperation. For any information on IODE
or on this survey please contact Peter Pissierssens, Head Ocean Services IOC
at [EMAIL PROTECTED] or [EMAIL PROTECTED] or find out more about
the IODE review on http://ioc3.unesco.org/iode/categories.php?category_no=86

Please note that your email address will NOT be used for any non-official
purpose unrelated to IOC. However if you do not wish to receive any other
messages from IOC then please send  blank message to [EMAIL PROTECTED] and we
will remove your address from our records.

Peter Pissierssens
Head, Ocean Services Section
Intergovernmental Oceanographic Commission of UNESCO
1 rue Miollis
75732 Paris Cedex 15
FRANCE
Tel: +33 1 45 68 40 46


--
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: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

[Peter Ekberg]

Chuck wrote:
> New alpha versions of libtool available for test.  This is
> very close to what libtool-2.0 will be.  Please evaluate.

Ok, I found another problem. You cannot add the flag
-Werror-implicit-function-declaration to CFLAGS as that
kills the build of the wrapper executable. While there,
clean up some other warnings as well, so that -Werror
also has a chance to work...

Here's the make output without the patch:

/bin/sh ../libtool --mode=link --tag=CC gcc  -g -O2 -D_REENTRANT
-D_THREAD_SAFE -DDEBUG -g -Wall -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wswitch -Wmissing-prototypes -Wreturn-type -Wshadow
-Wnested-externs -Wredundant-decls -Werror-implicit-function-declaration
-o demo.exe  demo.o ../gii/libgii.la
gcc -g -O2 -D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -Wall -Wpointer-arith
-Wsign-compare -Wstrict-prototypes -Wswitch -Wmissing-prototypes
-Wreturn-type -Wshadow -Wnested-externs -Wredundant-decls
-Werror-implicit-function-declaration -o .libs/demo.exe demo.o
../gii/.libs/libgii.dll.a
/home/peda/ggi2-cygwin/libgii/gg/.libs/libgg.dll.a -lpthread
libtool: link: creating demo.exe
.libs/lt-demo.c:68:1: warning: "DEBUG" redefined
:11:1: warning: this is the location of the previous
definition
.libs/lt-demo.c: In function `main':
.libs/lt-demo.c:110: warning: control reaches end of non-void function
.libs/lt-demo.c: In function `xstrdup':
.libs/lt-demo.c:125: error: implicit declaration of function `strcpy'
.libs/lt-demo.c:125: error: implicit declaration of function `strlen'
.libs/lt-demo.c: In function `find_executable':
.libs/lt-demo.c:241: error: implicit declaration of function `memcpy'
.libs/lt-demo.c:179: warning: unused variable `st'
.libs/lt-demo.c: In function `strendzap':
.libs/lt-demo.c:288: error: implicit declaration of function `strcmp'

Everything below the "libtool: link: creating demo.exe" line
disappears with the patch.

Cheers,
Peter


win32-wrapper-cleanup.patch
Description: win32-wrapper-cleanup.patch
--
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/

GGI works on Cygwin

[Peter Ekberg]

Hello!

I'm writing to inform that GGI works on Cygwin (and MinGW for
that matter). v2.1 release candidate 4 is available for
testing, see the announcement for details on how to get it:
http://marc.theaimsgroup.com/?l=ggi-develop&m=109958791202306&w=2

It has been working for a while, but this seemed like a good
time to promote the project as an issue with DirectX headers
have cleared up somewhat.

GGI stands for General Graphics Interface, and it is a project
that aims to develop a reliable, stable and fast graphics system
that works everywhere. We want to allow any program using GGI to
run on any platform requiring at most a recompile.

GGI on Cygwin supports both the X11 and the DirectX targets (in
addition to a bunch of other intermediate targets such as shared
memory and palette emulation etc).

See these files in the distribution for more detailed
instructions:
libgii-0.9.0/doc/README.directx
libggi-2.1.0/doc/README.directx

Project homepage: http://www.ggi-project.org/

Cheers,
Peter


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

libiconv and am--refresh question

[Peter Rehley]

Hello,
I'm compiling libiconv-1.9.2-1 and it works fine.  However if I were  
touch aclocal.m4 (e.g hypothetically customize the file), I get the  
following error during the build option.

(cd .libs && rm -f libiconv.la && ln -s ../libiconv.la libiconv.la)
make[1]: Leaving directory  
`/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
.build/lib'
cd srclib && make all
make[1]: Entering directory  
`/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
.build/srclib'
make[2]: Entering directory  
`/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
.build'
make[2]: *** No rule to make target `am--refresh'.  Stop.
make[2]: Leaving directory  
`/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
.build'
make[1]: ***  
[/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
srclib/Makefile.in] Error 1
make[1]: Leaving directory  
`/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
.build/srclib'
make: *** [all] Error 2

I've checked the makefiles and there is no rule anywhere for  
am--refresh.  There are references for it that were added from a patch  
that gets applied during prep phase.  Is there suppose to be user  
interaction in this case?  and if so what are the commands that one  
would need to do to fix this problem?  If this should be handled  
automatically, would this be considered a bug?

The commands that I used to get this error message are after untarring  
package:
./libiconv-1.9.2-1.sh prep
touch libiconv-1.9.2/aclocal.m4
./libiconv-1.9.2-1.sh conf
./libiconv-1.9.2-1.sh build

I'm including also the gzip of the above output.
Enjoy,
Peter
---
A Møøse once bit my sister


libiconv.log.gz
Description: GNU Zip compressed data
--
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: Apology

[Peter Rehley]

It's possible to deselect all (top level deselect), then select only 
cygwin and then download to local machine.  Then you would only have 
the package, setup wouldn't have installed it and you have what you 
need.

On Nov 15, 2004, at 9:56 AM, Darkfalz wrote:
Sorry about that last email, really. Please stop sending me abuse.
I'm just saying, it would be a good idea to have the zipped dll only 
as a quick and dirty download somewhere on the main page. Going 
through the installer can be a pain (when mirrors don't work etc) and 
then browsing through to deselect stuff when you only want the latest 
dll is just a lot of hassle.

Darkfalz
--
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/

Enjoy,
Peter
---
A Møøse once bit my sister
--
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: flex and dos source files. How is flex built for cygwin

[Peter Rehley]

Larry Hall wrote:
At 02:29 PM 11/19/2004, you wrote:
 

Hi,
We have a customer that is using flex under a custom version of cygwin that we provided 
them (with source).  The customer is having problems when their "*.l" files are 
in dos format.  Flex is taking the lines from the file and adding them into the lex.yy.c 
file untouched.  (i.e. they still have the \n\r at the end), and this causing problems 
later on.
I tried using the version of flex that comes with the latest version of cygwin 
(1.5.12) and flex changes the \n\r to just \n, which makes everything work 
fine.  Good I thought since the version of flex we provide is not the latest.  
I'll just recompile.
But when I tried that with the latest flex (2.5.4a-3) I get the same behavior 
that the customer is seeing.  I get this behavior even if I compile on the 
latest version of cygwin.
So, my question is what options are used for building flex?
   


Linking against /usr/lib/binmode.o perhaps?
 

Tried on cygwin 1.5.12
make clean
make LDFLAGS="/usr/lib/binmode.o",
and
make clean
make LDFLAGS="-lbinmode"
but neither helped
--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 

 


--
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: flex and dos source files. How is flex built for cygwin

[Peter Rehley]

Peter Rehley wrote:
Larry Hall wrote:
At 02:29 PM 11/19/2004, you wrote:
 

Hi,
We have a customer that is using flex under a custom version of 
cygwin that we provided them (with source).  The customer is having 
problems when their "*.l" files are in dos format.  Flex is taking 
the lines from the file and adding them into the lex.yy.c file 
untouched.  (i.e. they still have the \n\r at the end), and this 
causing problems later on.

I tried using the version of flex that comes with the latest version 
of cygwin (1.5.12) and flex changes the \n\r to just \n, which makes 
everything work fine.  Good I thought since the version of flex we 
provide is not the latest.  I'll just recompile.

But when I tried that with the latest flex (2.5.4a-3) I get the same 
behavior that the customer is seeing.  I get this behavior even if I 
compile on the latest version of cygwin.

So, my question is what options are used for building flex?
  

Linking against /usr/lib/binmode.o perhaps?
 

Tried on cygwin 1.5.12
make clean
make LDFLAGS="/usr/lib/binmode.o",
and
make clean
make LDFLAGS="-lbinmode"
but neither helped
However linking the /usr/lib/textmode.o did work
make LDFLAGS="/usr/lib/textmode.o" # <- did the job
Thanks Larry for pointing me in the right directory :)

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

 



--
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: flex and dos source files. How is flex built for cygwin

[Peter Rehley]

On Nov 20, 2004, at 12:07 AM, Reini Urban wrote:
Peter Rehley schrieb:
Peter Rehley wrote:
Larry Hall wrote:
We have a customer that is using flex under a custom version of 
cygwin that we provided them (with source).  The customer is 
having problems when their "*.l" files are in dos format.  Flex is 
taking the lines from the file and adding them into the lex.yy.c 
file untouched.  (i.e. they still have the \n\r at the end), and 
this causing problems later on.

I tried using the version of flex that comes with the latest 
version of cygwin (1.5.12) and flex changes the \n\r to just \n, 
which makes everything work fine.  Good I thought since the 
version of flex we provide is not the latest.  I'll just 
recompile.

But when I tried that with the latest flex (2.5.4a-3) I get the 
same behavior that the customer is seeing.  I get this behavior 
even if I compile on the latest version of cygwin.

So, my question is what options are used for building flex?
there's no build script and an inactive maintainer. we don't know. 
hopefully just the standard options.
./configure --prefix=/usr sharedstatedir=/var --mandir=/usr/share/man
make && make install
Using these options the behavior of flex differs from the flex that is 
shipped with cygwin.


Linking against /usr/lib/binmode.o perhaps?
He meant that by accident flex was linked against binmode.o, which is 
wrong. It was no advice to reproduce that error with linking against 
binmode or textmount.

Tried on cygwin 1.5.12
make clean
make LDFLAGS="/usr/lib/binmode.o",
and
make clean
make LDFLAGS="-lbinmode"
but neither helped
for sure not.
However linking the /usr/lib/textmode.o did work
make LDFLAGS="/usr/lib/textmode.o" # <- did the job
Thanks Larry for pointing me in the right directory :)
Oh god. This was the right direction? Sorry no.
If you open your flex input file in a *textmode mount* \r\n will get 
converted, if you open that in a binmode mount it will not get 
converted.
$ man mount
The filesystem has been mounted in binmode, but  the flex that comes 
with cygwin translates the files.  Both flex and the text file are on 
binmode mounts.

So it's entirely a user problem behind the keyboard, and does NOT need 
a changed linker line. Just tell the user to set this mount to 
textmode, so that his DOSEOL will get converted. Or convert the DOSEOL 
by basic commands like unix2dos.
Yes, there are things that the user can do to work around the problem, 
like saving the file as a unix file, and he is already using dos2unix.  
However when  I was doing research on this problem I found that the 
flex that comes with a standard cygwin distribution does the \r\n to \n 
translation when the directory is mounted in binmode.

When I compile flex, it doesn't do the translation.  If the flex that 
came with cygwin didn't do the translation, there would be no 
questions, but since it does something different, I wanted to know how 
it was compiled because it was obviously compiled differently.  Larry 
offered a suggestion that led me to the solution that flex had been 
linked with /usr/lib/textmode.o, because when I use that option I get 
the same behavior that I see with the flex shipped with cygwin.

It could be that the maintainer of flex used /usr/bin/textmode.o to 
ensure that dos files wouldn't cause problems.

But if you force linking against binmode or textmode, your flex binary 
will do no conversions at all, and will only work on the matching 
mount modes.
If I understand right, then a program linked with textmode won't do a 
translation in binmode? but this is not the behavior that I'm seeing
This is a pretty basic cygwin FAQ, and I wonder why this needs such a 
long and wrong consideration.
Just trying to figure why the flex packaged with cygwin behaves 
differently than one compiled on the system.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
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/

Enjoy,
Peter
---
A Møøse once bit my sister
--
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: flex and dos source files. How is flex built for cygwin

[Peter Rehley]

On Nov 20, 2004, at 10:19 AM, Reini Urban wrote:
Peter Rehley schrieb:
On Nov 20, 2004, at 12:07 AM, Reini Urban wrote:
Peter Rehley schrieb:
Peter Rehley wrote:
Larry Hall wrote:
We have a customer that is using flex under a custom version of 
cygwin that we provided them (with source).  The customer is 
having problems when their "*.l" files are in dos format.  Flex 
is taking the lines from the file and adding them into the 
lex.yy.c file untouched.  (i.e. they still have the \n\r at the 
end), and this causing problems later on.

I tried using the version of flex that comes with the latest 
version of cygwin (1.5.12) and flex changes the \n\r to just \n, 
which makes everything work fine.  Good I thought since the 
version of flex we provide is not the latest.  I'll just 
recompile.

But when I tried that with the latest flex (2.5.4a-3) I get the 
same behavior that the customer is seeing.  I get this behavior 
even if I compile on the latest version of cygwin.

So, my question is what options are used for building flex?

there's no build script and an inactive maintainer. we don't know. 
hopefully just the standard options.
./configure --prefix=/usr sharedstatedir=/var --mandir=/usr/share/man
make && make install
Using these options the behavior of flex differs from the flex that 
is shipped with cygwin.

Linking against /usr/lib/binmode.o perhaps?

He meant that by accident flex was linked against binmode.o, which 
is wrong. It was no advice to reproduce that error with linking 
against binmode or textmount.

Tried on cygwin 1.5.12
make clean
make LDFLAGS="/usr/lib/binmode.o",
and
make clean
make LDFLAGS="-lbinmode"
but neither helped

for sure not.
However linking the /usr/lib/textmode.o did work
make LDFLAGS="/usr/lib/textmode.o" # <- did the job
Thanks Larry for pointing me in the right directory :)
Oh god. This was the right direction? Sorry no.
If you open your flex input file in a *textmode mount* \r\n will get 
converted, if you open that in a binmode mount it will not get 
converted.
$ man mount
The filesystem has been mounted in binmode, but  the flex that comes 
with cygwin translates the files.  Both flex and the text file are on 
binmode mounts.
ok thanks, for confirmation.
so cgf should repackage it. it's obviously a bug.
I think so also because this isn't the behavior that occurs on linux or 
BSD.

And please add a hint how to reproduce from source, so we don't have 
to guess. Christofer claims that he didn't link against textmode.a, 
but it looks like so, or there was some deeper magic behind, which 
went away suddenly.
He is using automode.o, he said in one of the followups to this thread.
Hint should be included in original posting.  It has original make 
commands that I used plus a simple example for testing.  It also has 
instructions on how to build and run the simple sample

Modified build commands would be ./configure; make 
LDFLAGS="/usr/lib/automode.o"

--
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: Undelete

[Peter Rehley]

On Nov 20, 2004, at 11:20 AM, kent morris wrote:
I installed cygwin and found it does not meet my needs. How do I 
un-install it? WIN XP Control Panel does not show it in the add/remove 
window. I have not found any documentation on how to remove the 
program.
Did you see this?
http://cygwin.com/faq/faq0.html#SEC19
--
Kent Morris
May you live in interesting times

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

Enjoy,
Peter
---
A Møøse once bit my sister
--
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: flex and dos source files. How is flex built for cygwin

[Peter Rehley]

On Nov 22, 2004, at 9:21 AM, Igor Pechtchanski wrote:
On Sat, 20 Nov 2004, Peter Rehley wrote:
On Nov 20, 2004, at 10:19 AM, Reini Urban wrote:
[snip]
ok thanks, for confirmation.
so cgf should repackage it. it's obviously a bug.
I think so also because this isn't the behavior that occurs on linux 
or BSD.
Umm, which behavior are you talking about?  The automatic conversion 
of CRLF
line endings to LF?  This is Cygwin-specific behavior, and has nothing 
to do
with Linux or BSD.  It's there to avoid complaints from people who 
use, say,
notepad on binary mounts to edit their .flex files.
I suspected as much.
[snip]
Modified build commands would be
./configure; make LDFLAGS="/usr/lib/automode.o"

The above should really be
./configure; make LDLIBS="/usr/lib/automode.o"

make LIBS="-lintl /usr/lib/automode.o".  There is no LDLIBS in the flex 
source, and when setting LIBS the -lintl is needed because the LIBS in 
the Makefile had that value.
It may not matter for linking in a .o file, but it certainly will 
matter if
a -l form is used (as you tried earlier).


HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

Let's move along.  Nothing to see here.
--
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: flex and dos source files. How is flex built for cygwin (No longer on topic)

[Peter Rehley]

On Nov 22, 2004, at 11:00 AM, Igor Pechtchanski wrote:
[snip]

[snip]
Modified build commands would be
./configure; make LDFLAGS="/usr/lib/automode.o"

The above should really be
./configure; make LDLIBS="/usr/lib/automode.o"

make LIBS="-lintl /usr/lib/automode.o".  There is no LDLIBS in the 
flex
source, and when setting LIBS the -lintl is needed because the LIBS 
in the
Makefile had that value.
It *is* LDLIBS.  See "make -pf/dev/null | grep -C2 '^%: %.o'".  BTW, 
this
is not Cygwin-specific.
Ok, that's the built-in rule, but the flex Makefile isn't using the 
built-in rule.  See the rule for $(FLEX)


It may not matter for linking in a .o file, but it certainly will 
matter if
a -l form is used (as you tried earlier).

HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

Enjoy,
Peter
---
A Møøse once bit my sister
--
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: Failing to mount from nfs-server

[Peter Rehley]

On Dec 3, 2004, at 3:00 PM, Michael Butler wrote:
When I add -overs=2 to the mount command, I get a permission denied
error instead of the server down error.  Can anyone help me?
On Thu, 2 Dec 2004 15:06:08 -0800, Michael Butler 
<[EMAIL PROTECTED]> wrote:
I installed the latest cygwin with nfs-server and the required support
packges, along with nothing else extra.  I ran nfs-server-config,
changed my exports, and started the daemons in the windows services.
All 3 have "started" but when I try to mount shared directories from a
Fedora Core 2 client on the same network, I get
mount to NFS server '192.168.1.2' failed: server is down.
rpcinfo -p from the localhost and from the client both return the
following info:
  program vers proto   port
   102   tcp111
   102   udp111
   132   udp   2049  nfs
   132   tcp   2049  nfs
   151   udp850
   152   udp850
   151   tcp853
   152   tcp853
nmapping these ports shows each of them as open except for 850.  There
is no firewall software on the server machine.  My exports file is as
follows:
/mnt/c/export/root  *(ro,no_root_squash,sync)
/pub*(ro,no_root_squash,sync)
It seems to me as though this should be a working setup.  Did I miss 
something?
Try removing the '*' in the exports file and restarting things.  I've 
had problems with using only the *.  Your milage may vary though.


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

Enjoy,
Peter
---
A Møøse once bit my sister
--
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: Failing to mount from nfs-server

[Peter Rehley]

On Dec 3, 2004, at 4:00 PM, Michael Butler wrote:
How silly of me to not try this earlier.  Success!  Thank you.
On another note, is it a bug that * does not work in this version of
nfsd/mountd/whatever?  I have had it work with every other version of
nfsd.
I think that it would be a bug.  The manual says a * should match any 
machine, but it doesn't on cygwin.

Mike
On Fri, 3 Dec 2004 15:52:11 -0800, Peter Rehley <[EMAIL PROTECTED]> 
wrote:
Try removing the '*' in the exports file and restarting things.  I've
had problems with using only the *.  Your milage may vary though.
Enjoy,
Peter
---
A Møøse once bit my sister


Enjoy,
Peter
---
A Møøse once bit my sister
--
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/

short fread(), but no ferror/feof

[Peter Åstrand]

I've discovered that fread(ptr, size, nitems, stream) sometimes returns a
value less than "nitems", but does not set feof() nor ferror(). As I
understand, this is incorrect: All fread() documentation I've found
confirms this. For example, IEEE Std 1003.1 says:

"Upon successful completion, fread() shall return the number of elements
successfully read which is less than nitems only if a read error or
end-of-file is encountered."

I've only noticed the problem when using fread() on a pipe, and when
setting a (another) file descriptor in the same application in
close-on-exec mode. The details are on http://python.org/sf/1071516. I've
been using the latest Cygwin (as of 2004-12-04) on Windows 98.

To me, this looks like a Cygwin bug. Any ideas?

/Peter Åstrand <[EMAIL PROTECTED]>


--
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 setup via RDP fails

[Peter Åstrand]

I've discovered that it's not possible to install Cygwin on a Terminal
Server via RDP: The installation hangs somewhere between 0% and 5%. The
installation succeeds if installing from the server console, though.
Known bug?



/Peter Åstrand <[EMAIL PROTECTED]>


--
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: short fread(), but no ferror/feof

[Peter Astrand]

>> I've discovered that fread(ptr, size, nitems, stream) sometimes returns a
>> value less than "nitems", but does not set feof() nor ferror(). As I

>A simple, compilable test case with results shown on both linux and
>cygwin would prove your theory.

Here you go; example follows. Test run on Linux:

---
Got 66 bytes:
/bin/ls: /somebogus: Filen eller katalogen finns inte
/etc/passwd
|EOF has been reached.
---

Test run on Cygwin:

---
$ ./a.exe
Got 9 bytes:
/bin/ls: |
---

As you can see, the result is partial, and there is no EOF nor error.

I guess this is the problem described at
http://sources.redhat.com/ml/newlib/2004/msg00477.html. Perhaps you can
apply the suggested patch?

Example code follows.


#include 
#include 
#include 
#include 


void checked_close(int fd)
{
if (close(fd) == -1) {
perror("close");
exit(1);
}
}


void checked_pipe(int filedes[2])
{
if (pipe(filedes) == -1) {
perror("filedes");
exit(1);
}
}


int checked_dup2(int oldfd, int newfd)
{
int ret;
if ((ret = dup2(oldfd, newfd)) == -1) {
perror("dup2");
exit(1);
}
return ret;
}


int main()
{
int c2p[2];
int errpipe[2];
pid_t pid;
char errpipe_buf[16];
char buf[16394];
ssize_t errpipe_count;
size_t count;
FILE *output;

checked_pipe(c2p);
checked_pipe(errpipe);
fcntl(errpipe[1], F_SETFD, FD_CLOEXEC);

pid = fork();
switch (pid) {
case -1:
perror("fork");
exit(1);
break;

case 0:
/* child */
checked_close(c2p[0]);
checked_close(errpipe[0]);
dup2(c2p[1], 1);
dup2(c2p[1], 2);
checked_close(c2p[1]);
execlp("/bin/ls", "/bin/ls", "/etc/passwd", "/somebogus");
/* If we are still around, exec failed */
write(errpipe[1], "1", 1);
_exit(255);
break;

default:
/* parent */
break;
}

checked_close(errpipe[1]);
checked_close(c2p[1]);

errpipe_count = read(errpipe[0], errpipe_buf, 1);
switch (errpipe_count) {
case -1:
perror("read");
exit(1);
break;
case 0:
/* EOF, good */
break;
default:
/* Our "1", exec failed */
fprintf(stderr, "exec in child failed\n");
exit(1);
break;
}

/* now read output from child, via a FILE stream */
if ((output = fdopen(c2p[0], "rb")) == NULL) {
perror("fdopen");
exit(1);
}

setvbuf(output, 0, _IONBF, 0);
clearerr(output);
count = fread(buf, 1, sizeof(buf), output);
if (count >= 0) {
fprintf(stderr, "Got %d bytes:\n", count);
fprintf(stderr, "%s|", buf);
}
if (feof(output)) {
fprintf(stderr, "EOF has been reached.\n");
}
if (ferror(output)) {
fprintf(stderr, "An error occured.\n");
}

return 0;
}

/Peter Åstrand <[EMAIL PROTECTED]>


--
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: short fread(), but no ferror/feof

[Peter Astrand]

On Thu, 9 Dec 2004, Igor Pechtchanski wrote:

> > >> I've discovered that fread(ptr, size, nitems, stream) sometimes returns a
> > >> value less than "nitems", but does not set feof() nor ferror(). As I
> >
> > >A simple, compilable test case with results shown on both linux and
> > >cygwin would prove your theory.
> >
> > Here you go; example follows. Test run on Linux:

> According to <http://sources.redhat.com/ml/newlib/2004/msg00478.html>, the
> patch was checked in on Oct 26.  Cygwin uses the latest version of newlib.
> Cygwin 1.5.12-1 was released on Nov 10, so it should contain this patch.
>
> You can verify this by downloading the Cygwin source package, and looking
> at newlib/libc/stdio/fread.c.

I've tested http://sources.redhat.com/ml/newlib/2004/txt3.txt on
Cygwin, and it works. So, most probably, Cygwin uses the "fixed" newlib.


However, since my example code
(http://cygwin.com/ml/cygwin/2004-12/msg00305.html) still fails, something
is still wrong. Is it possible the the "fix" above actually caused this
problem?


/Peter Åstrand <[EMAIL PROTECTED]>


--
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: short fread(), but no ferror/feof

[Peter Astrand]

Dave Korn wrote:

>  The fix and the problem Peter is seeing are orthogonal.
>
>  The fix referred to above fixes this problem:
>
>http://sources.redhat.com/ml/newlib/2004/msg00478.html
>"Hence, one can see that fread() in unbuffered mode always returns the
>specified count instead of the number of elements actually read."
>
>  That is why, as Peter has observed, fread() returns the number of
>elements
>actually read.  Without the patch, it would have been returning the entire
>number requested, which would have been even wronger.

Ah, thanks for clarifying this.


>  However Peter's problem is that when fread() does a partial read, it doesn't
>set either the EOF mark or the error indication on the file stream.  A strict
>reading of the fread() specification suggests that it should have set one of
>those.

IMO, there's no room for intepretation in this situation: As I stated
in my original post, IEEE Std 1003.1 is very clear:

"fread() shall return the number of elements successfully read which is
less than nitems only if a read error or end-of-file is encountered."


>OTOH, there isn't actually any error or EOF here.  It could possibly
>be argued from the specified behaviour of read() and pipes that the
>error mark should be set and that errno should be EAGAIN.  It may well
>be in practice that errno does indeed have the value EAGAIN but
>fread() can't return -1 because otherwise the application wouldn't
>know how much data it _had_ read.

I've discussed this issue with some local gurus, and the consensus is that
fread() should do as many read() calls as it takes. This is what glibc
does, for example (if I understand the source correctly). Basically,
fread() means "read everything". It's just plain wrong to return a partial
result, unless EOF or an error occured.


>  Of course, Peter can always detect when this situation has
>occurred, precisely because fread() returns a value that, while >= 0,
>is < the number of elements requested, and when feof() and ferror()
>both return zero, his code could deduce that it's a short read from a
>pipe and try again.

If you can convince the Python developers to add these checks to the
already-complicated fread() invocation in fileobject.c, I will stop
complaining... But fread() shouldn't behave like that.


(Please CC me on replies.)

/Peter Åstrand <[EMAIL PROTECTED]>


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