Windows 2003 & Cygwin User Authentication

2003-11-15 Thread Vesa Tikkanen 
Hi,

I started to use Cygwin recently. I'm having a problem with
authentication. I cannot login unless the user belongs to DomainAdmins
group.

I haven't modified my installation anyway. After installation I have
just added cygwin/bin directory to path environment variable and added
new environment variable cygwin=ntsec tty

The system is part of the Active directory Network with multiple domain
controllers.


Sincerely

Vesa Tikkanen


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

[Fwd: Re: [Module::Build] Alzabo / Module::Build Cygwin installation problem]

2003-11-15 Thread Randy W. Sims 
On 11/14/2003 5:42 PM, Randy W. Sims wrote:

> There is still a problem to be worked out, but I'm not yet sure where 
the problem is. Can you tell post your perl & Cwd version.
>
> Dave, What versions of perl, Cwd, & M::B have you tested Alzabo with?
>
> This problem doesn't seem directly related to Cygwin. It definately 
should not be an error to 'use Cwd', so this has to be a problem in 
M::B, Cwd, or perl. Right???
>

Ok, this might in fact be a Cygwin problem. Cygwin & Cwd. The following 
produces the error "Usage: Cwd::cwd() at Module.pm line 6." under Cygwin 
perl 5.8.x, but not under MSWin32 perl 5.6.x & 5.8.x. Also if I change 
Cwd to Carp I get no error. Can anyone test to make sure this does not 
produce errors on any other systems?

Thanks,
Randy.
-><8-
# Module.pm
package Module;
sub new {
  my $p = shift;
  $p->cwd;
}
sub cwd {
  require Cwd;
  Cwd::cwd;
}
1;
-><8-
-><8-
# test.pl
package MyModule;
use Module;
use base 'Module';
use Cwd;
package main;
MyModule->new;
-><8-

--- Begin Message ---
On 11/14/2003 5:42 PM, Randy W. Sims wrote:
There is still a problem to be worked out, but I'm not yet sure where 
the problem is. Can you tell post your perl & Cwd version.

Dave, What versions of perl, Cwd, & M::B have you tested Alzabo with?

This problem doesn't seem directly related to Cygwin. It definately 
should not be an error to 'use Cwd', so this has to be a problem in 
M::B, Cwd, or perl. Right???

Ok, this might in fact be a Cygwin problem. Cygwin & Cwd. The following 
produces the error "Usage: Cwd::cwd() at Module.pm line 6." under Cygwin 
perl 5.8.x, but not under MSWin32 perl 5.6.x & 5.8.x. Also if I change 
Cwd to Carp I get no error. Can anyone test to make sure this does not 
produce errors on any other systems?

Thanks,
Randy.
-><8-
# Module.pm
package Module;
sub new {
  my $p = shift;
  $p->cwd;
}
sub cwd {
  require Cwd;
  Cwd::cwd;
}
1;
-><8-
-><8-
# test.pl
package MyModule;
use Module;
use base 'Module';
use Cwd;
package main;
MyModule->new;
-><8-

--- End Message ---
--
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: For masochists: the leap o faith

2003-11-15 Thread Christopher Faylor 
On Sat, Nov 15, 2003 at 07:07:26PM +1100, Robert Collins wrote:
>On Sat, 2003-11-15 at 15:43, Christopher Faylor wrote:
>>Yes, I've already (obviously?) been to SUSv3.  I wasn't talking about
>>standards.  I was talking about common practice.
>>
>>If you have a common practice web site that you want to show me then
>>that might be a convincing argument.  Otherwise, I'll have to fall back
>>on my personal UNIX experience.
>
>http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2003-04/msg00600.html
>
>Part of a thread on this in another project.  Seems like the hurd
>follows the no-PATH_MAX, use pathconf() always approach.  Which means
>that everything thats portable to the hurd, will Do The Right Thing, if
>we eliminate the PATH_MAX and MAXPATHLEN defines.  In my digging, I
>found that PATH_MAX, if defined, MUST be the largest path length
>possible.  Presumably thats so that programs with static buffers won't
>run into trouble.

I mention "common practice" and you point me at a discussion which talks
about the Hurd???  The Hurd?

Wow.

cgf

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

Re: For masochists: the leap o faith

2003-11-15 Thread Christopher Faylor 
On Sat, Nov 15, 2003 at 11:45:34AM -0500, Christopher Faylor wrote:
>On Sat, Nov 15, 2003 at 07:07:26PM +1100, Robert Collins wrote:
>>On Sat, 2003-11-15 at 15:43, Christopher Faylor wrote:
>>>Yes, I've already (obviously?) been to SUSv3.  I wasn't talking about
>>>standards.  I was talking about common practice.
>>>
>>>If you have a common practice web site that you want to show me then
>>>that might be a convincing argument.  Otherwise, I'll have to fall back
>>>on my personal UNIX experience.
>>
>>http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2003-04/msg00600.html
>>
>>Part of a thread on this in another project.  Seems like the hurd
>>follows the no-PATH_MAX, use pathconf() always approach.  Which means
>>that everything thats portable to the hurd, will Do The Right Thing, if
>>we eliminate the PATH_MAX and MAXPATHLEN defines.  In my digging, I
>>found that PATH_MAX, if defined, MUST be the largest path length
>>possible.  Presumably thats so that programs with static buffers won't
>>run into trouble.
>
>I mention "common practice" and you point me at a discussion which talks
>about the Hurd???  The Hurd?
>
>Wow.

Btw, I've moved this discussion here from cygwin-patches because we are
talking about a change which could impact a number of people.  Robert is
submitting patches which increase the maximum path length for NT-class
systems.

My concern is that PATH_MAX will be increased for this change.  It will
no longer reflect the win32 api MAX_PATH value and I was wondering if
that would cause problems for existing applications.

I thought the cygwin mailing list would be a wider audience for this
type of thing than cygwin-patches, especially since no one is offering
opinions in cygwin-patches.

cgf

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

Re: chmod

2003-11-15 Thread Brian Ford 
On Sat, 15 Nov 2003, Lorenzo Travaglio wrote:

> > Ugh.  Again, what OS and what filesystem, and:
> Sorry. Win98.
>
And FAT32, and did you read these?

> Brian Ford wrote:
> > More likely, you are running an NT variant at work and 9x at home?  See:
> >
> > http://cygwin.com/faq/faq_toc.html#TOC45 and
> > http://cygwin.com/cygwin-ug-net/highlights.html#OV-HI-PERM
> >

And again:
> > In that case, this is not Xfree86 related, so next time please use the
> > main [EMAIL PROTECTED] mailing list.  Also, see:
> >

And you must not have read this *still*, because you did not attach
cygcheck output.
> > http://www.cygwin.com/problems.html
> >
> > for how to report this issue correctly so that someone can answer without
> > guessing.  Thanks.
> >
>
I don't even really know what the question is anymore!  chmod is a no-op
on Win98.  Cygwin fakes permissions there, and it won't work.

If this is not clear enough, or did not answer your question, please
carefully follow the guidlines presented in the URL above, post to
the correct list with an informative subject line, and then maybe you'll
get the answer your looking for.

I'm sorry for being grumpy, but I just don't know what's left to tell.  I
guess WJM rubs off quickly, huh?

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

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

2003-11-15 Thread Christopher Faylor 
On Sat, Nov 15, 2003 at 11:21:41AM -0600, Brian Ford wrote:
>I'm sorry for being grumpy, but I just don't know what's left to tell.
>I guess WJM rubs off quickly, huh?

It's the subliminal messages we put in the cygwin DLL source code.  As
soon as you start to become more knowledgeable about cygwin, you
automatically become meaner.  Glad to see it's working.

cgf

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

mount and ln commands

2003-11-15 Thread Erica Ramsey 
I am having trouble mounting a linking to a directory. The mounted file 
doesn't go to "/" as I specified in the mount command instead it goes to  
/cygdrive/c/Documents\ and\ Settings/erica. What am I doing wrong? This is 
what I do:

$ mount -tf "c:\PalmDev" /PalmDev

$ ln -s "C:\Palm OS 5 SDK (68K) R3\Palm OS Support" /PalmDev/sdk5r3
ln: creating symbolic link `/PalmDev/sdk5r3' to `C:\\Palm OS 5 SDK (68K) 
R3\\Palm OS Support': No such file or directory

$ ls /
Packages  cygwin.bat   cygwin.ico  lib   tmp  var
bin   cygwin.bat~  etc sbin  usr
** No /PalmDev
$ ls /PalmDev
ls: /PalmDev: No such file or directory
$ ls ../Documents\ and\ Settings/erica
Application Data  My Documents  Recent  _viminfo
ntuser.dat.LOG
Cookies   NTUSER.DATSendTo  _vimrc  ntuser.ini
Desktop   NetHood   Start Menu  _vimrc~ 
plugin131.trace
Favorites PalmDev <<== It went here!!!

$ mount
C:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type system 
(binmo
de)
C:\cygwin\bin on /usr/bin type user (binmode)
C:\cygwin\lib on /usr/lib type user (binmode)
c:\PalmDev on /PalmDev type system (textmode) <<== ??
C:\cygwin on / type user (binmode)
c: on /cygdrive/c type user (binmode,noumount)

$ cd /PalmDev
bash: cd: /PalmDev: No such file or directory
$ umount /PalmDev

== environment =
$ set
!::='::\'
!C:='C:\cygwin\bin'
ALLUSERSPROFILE='C:\Documents and Settings\All Users'
ANT_HOME='C:\jakarta-ant-1.3'
APPDATA='C:\Documents and Settings\erica\Application Data'
BASH=/usr/bin/bash
BASH_VERSINFO=([0]="2" [1]="05b" [2]="0" [3]="1" [4]="release" 
[5]="i686-pc-cygw
in")
BASH_VERSION='2.05b.0(1)-release'
COLUMNS=80
COMMONPROGRAMFILES='C:\Program Files\Common Files'
COMPUTERNAME=GALAXY5
COMSPEC='C:\WINNT\system32\cmd.exe'
CVS_RSH=/bin/ssh
DDKROOT='c:\NTDDK2'
DIRSTACK=()
DISPLAY=:0.0
EPOCROOT='\Symbian\6.1\Series60\'
EUID=1000
GROUPS=()
HISTFILE=/cygdrive/c/home/.bash_history
HISTFILESIZE=500
HISTSIZE=500
HOME=/cygdrive/c/home
HOMEDRIVE=C:
HOMEPATH='\Documents and Settings\erica'
HOSTNAME=GALAXY5
HOSTTYPE=i686
HSINCDIR='C:\Handspring\prc-tools\PalmDev\include\Handspring'
IFS=$' \t\n'
INCLUDE='C:\Program Files\Microsoft Visual 
Studio\VC98\atl\include;C:\Program Fi
les\Microsoft Visual Studio\VC98\mfc\include;C:\Program Files\Microsoft 
Visual S
tudio\VC98\include'
INFOPATH=/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr
/autotool/stable/info:
J2EE_HOME='C:\j2sdkee1.3.1'
JAVA_HOME='C:\j2sdk1.4.0'
LIB='C:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;C:\Program 
Files\Micr
osoft Visual Studio\VC98\lib'
LINES=25
LOGONSERVER='\\GALAXY5'
MACHTYPE=i686-pc-cygwin
MAILCHECK=60
MAKE_MODE=unix
MANPATH=/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl
/man
MSDEVDIR='C:\Program Files\Microsoft Visual Studio\Common\MSDev98'
NUMBER_OF_PROCESSORS=1
OLDPWD=/
OPTERR=1
OPTIND=1
OS=Windows_NT
OS2LIBPATH='C:\WINNT\system32\os2\dll;'
OSTYPE=cygwin
PALMDEVDIR='C:\Handspring\prc-tools\PalmDev'
PALMOSINC='%PALMDEVDIR%\sdk-3.5\include'
PATH='/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Perl/bin/:/cygdriv
e/c/PROGRA~1/Borland/CBUILD~1/Bin:/cygdrive/c/PROGRA~1/Borland/CBUILD~1/Projects
/Bpl:/cygdrive/c/Perl/bin/:/cygdrive/c/winnt/system32:/cygdrive/c/Handspring/prc
-tools/bin:/cygdrive/c/Program Files/Microsoft Visual 
Studio/Common/Tools/WinNT:
/cygdrive/c/Program Files/Microsoft Visual 
Studio/Common/MSDev98/Bin:/cygdrive/c
/Program Files/Microsoft Visual Studio/Common/Tools:/cygdrive/c/Program 
Files/Mi
crosoft Visual 
Studio/VC98/bin:/:/cygdrive/c/vim/vim60:/cygdrive/c/Symbian/6.1/S
hared/epoc32/gcc/bin:/cygdrive/c/Symbian/6.1/Shared/epoc32/tools:/cygdrive/c/per
l/bin:/cygdrive/c/unix/usr/local/wbin:/cygdrive/c/unix/bin:/cygdrive/c/j2sdk1.4.
2_02/bin:.'
PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PIPESTATUS=([0]="0")
PPID=1
PRCTOOLSDIR='C:\Handspring\prc-tools'
PRINTER='HP LaserJet 2100 Series PS'
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER='x86 Family 6 Model 8 Stepping 1, GenuineIntel'
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0801
PROGRAMFILES='C:\Program Files'
PROMPT='$P$G'
PS1=$'\\[\\033]0;[EMAIL PROTECTED] \\[\\033[33m\\w\\033[0m\\]\n$ 
'
PS2='> '
PS4='+ '
PWD=/cygdrive/c/home
ROOTDIR='C:\PROGRA~1\RATIONAL\RATION~1\NUTCROOT'
SHELL='C:\PROGRA~1\RATIONAL\RATION~1\NUTCROOT\mksnt\sh.exe'
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:moni
tor
SHLVL=1
SYSTEMDRIVE=C:
SYSTEMROOT='C:\WINNT'
TEMP=/cygdrive/c/DOCUME~1/erica/LOCALS~1/Temp
TERM=cygwin
TMP=/cygdrive/c/DOCUME~1/erica/LOCALS~1/Temp
TMPDIR=/cygdrive/c/DOCUME~1/erica/LOCALS~1/Temp
UID=1000
USER=erica
USERDOMAIN=GALAXY5
USERNAME=erica
USERPROFILE='C:\Documents and Settings\erica'
WINDIR='C:\WINNT'
X11PATH=/usr/X11R6/bin
_=set
f=
$

_
Crave some Miles Davis or Grateful Dead?  Your old favorites are always 
pl

RE: Will next cygwin1.dll release have the select() fix?

2003-11-15 Thread Brian Kelly 
Why do I feel like I'm watching an Ed Wood movie?

Thank God you guys write better code than you do comedy.

Suggested ad copy for "attracting" more non-contributing end-users:

Cygwin! - Come for the software, stay for the BERATEMENT!

:-l

bits and bytes may break my code, but your 'word's will never abend me!

-bk

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Christopher Faylor
Sent: Friday, November 14, 2003 4:25 PM
To: [EMAIL PROTECTED]
Subject: Re: Will next cygwin1.dll release have the select() fix?

On Fri, Nov 14, 2003 at 02:18:36PM -0600, Brian Ford wrote:
>On Fri, 14 Nov 2003, Christopher Faylor wrote:
>
>> On Fri, Nov 14, 2003 at 02:10:53PM -0600, Brian Ford wrote:
>> >On Fri, 14 Nov 2003 [EMAIL PROTECTED] wrote:
>>
>> Gold star for Brian!
>>
>Thanks!  But, be carefull.  We're both Brian :D.

I thought of that a millisecond after sending the email:

"Gold star for Brian Ford!"

cgf

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


--
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: For masochists: the leap o faith

2003-11-15 Thread Brian Ford 
On Sat, 15 Nov 2003, Christopher Faylor wrote:

> Btw, I've moved this discussion here from cygwin-patches because we are
> talking about a change which could impact a number of people.  Robert is
> submitting patches which increase the maximum path length for NT-class
> systems.
>
> My concern is that PATH_MAX will be increased for this change.  It will
> no longer reflect the win32 api MAX_PATH value and I was wondering if
> that would cause problems for existing applications.
>
Would this affect gcc -mno-cygwin?  That would seem bad.

> I thought the cygwin mailing list would be a wider audience for this
> type of thing than cygwin-patches, especially since no one is offering
> opinions in cygwin-patches.
>
Well, since your soliciting opinions...

I don't have much of one other than I'd really prefer to keep
PATH_MAX/MAX_PATH and define them to the largest allowable path so they
can still be used for sizing arrays.  I don't really care if that lenght
is not always supported.

I would assume that any application that goes to the trouble of doing
something other than bailing with an error in that case should actually
use pathconf.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: Will next cygwin1.dll release have the select() fix?

2003-11-15 Thread Christopher Faylor 
On Sat, Nov 15, 2003 at 01:37:04PM -0500, Brian Kelly wrote:
>Why do I feel like I'm watching an Ed Wood movie?
>
>Thank God you guys write better code than you do comedy.
>
>Suggested ad copy for "attracting" more non-contributing end-users:
>
>Cygwin! - Come for the software, stay for the BERATEMENT!

You're confused.  There was zero comedy intended or implied in the
below.

I was actually given Brian Ford a gold star for answering your questions
correctly.  Go to the cygwin web site and look for the gold stars link.

--
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: For masochists: the leap o faith

2003-11-15 Thread Christopher Faylor 
On Sat, Nov 15, 2003 at 01:09:00PM -0600, Brian Ford wrote:
>On Sat, 15 Nov 2003, Christopher Faylor wrote:
>
>> Btw, I've moved this discussion here from cygwin-patches because we are
>> talking about a change which could impact a number of people.  Robert is
>> submitting patches which increase the maximum path length for NT-class
>> systems.
>>
>> My concern is that PATH_MAX will be increased for this change.  It will
>> no longer reflect the win32 api MAX_PATH value and I was wondering if
>> that would cause problems for existing applications.
>>
>Would this affect gcc -mno-cygwin?  That would seem bad.

No.  It should have no effect.  Different header files.

>> I thought the cygwin mailing list would be a wider audience for this
>> type of thing than cygwin-patches, especially since no one is offering
>> opinions in cygwin-patches.
>>
>Well, since your soliciting opinions...
>
>I don't have much of one other than I'd really prefer to keep
>PATH_MAX/MAX_PATH and define them to the largest allowable path so they
>can still be used for sizing arrays.  I don't really care if that lenght
>is not always supported.

Ok.  That was one plan.  I was concerned that a program might be assuming that
since it had carefully checked that a path was <= PATH_MAX, everything was
fine when on a Windows 98 system, it could conceivably fail.

I know that this isn't exactly a 100% safe and sanctioned use of PATH_MAX but
it seems like the possibility exists that working code could be broken by
this change.

Robert seems to be leaning towards removing the PATH_MAX define entirely
now, however.

>I would assume that any application that goes to the trouble of doing
>something other than bailing with an error in that case should actually
>use pathconf.

That's the way I'd write my code but I'm not certain that all of the currently
running code is so robust.

cgf

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

Re: For masochists: the leap o faith

2003-11-15 Thread Brian Ford 
On Sat, 15 Nov 2003, Christopher Faylor wrote:

> On Sat, Nov 15, 2003 at 01:09:00PM -0600, Brian Ford wrote:
> >Well, since your soliciting opinions...
> >
> >I don't have much of one other than I'd really prefer to keep
> >PATH_MAX/MAX_PATH and define them to the largest allowable path so they
> >can still be used for sizing arrays.  I don't really care if that lenght
> >is not always supported.
>
> Ok.  That was one plan.  I was concerned that a program might be assuming that
> since it had carefully checked that a path was <= PATH_MAX, everything was
> fine when on a Windows 98 system, it could conceivably fail.
>
> I know that this isn't exactly a 100% safe and sanctioned use of PATH_MAX but
> it seems like the possibility exists that working code could be broken by
> this change.
>
Working buggy code, yes.  I wouldn't sweat it.  I would be simple to fix.

> Robert seems to be leaning towards removing the PATH_MAX define entirely
> now, however.
>
Like I said before, this doesn't seem like a very good idea.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: Will next cygwin1.dll release have the select() fix?

2003-11-15 Thread Brian . Kelly 

BRAVO!

My hearty congratulations to Mr. Ford.

I'm sure it will look good on his resume.

>>>  *I was actually given Brian Ford*

I thought slavery in this country ended with the Civil War, or is Mr. Ford
a form of *artificial intelligence*?

Anyhow - how much do you want for him/it?

;-D

-bk






"Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com
on 11/15/2003 02:11:20 PM

Please respond to [EMAIL PROTECTED]

Sent by:[EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc: (bcc: Brian Kelly/WTC1/Empire)

Subject:Re: Will next cygwin1.dll release have the select() fix?


On Sat, Nov 15, 2003 at 01:37:04PM -0500, Brian Kelly wrote:
>Why do I feel like I'm watching an Ed Wood movie?
>
>Thank God you guys write better code than you do comedy.
>
>Suggested ad copy for "attracting" more non-contributing end-users:
>
>Cygwin! - Come for the software, stay for the BERATEMENT!

You're confused.  There was zero comedy intended or implied in the
below.

I was actually given Brian Ford a gold star for answering your questions
correctly.  Go to the cygwin web site and look for the gold stars link.

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







"WellChoice, Inc." made the following
 annotations on 11/15/2003 02:36:07 PM
--
Attention!  This electronic message contains information that may be legally
confidential and/or privileged.  The information is intended solely for the
individual or entity named above and access by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution,
or use of the contents of this information is prohibited and may be unlawful.
If you have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Release/Disclosure Statement


--
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: Will next cygwin1.dll release have the select() fix?

2003-11-15 Thread Brian Ford 
On Sat, 15 Nov 2003 [EMAIL PROTECTED] wrote:

> BRAVO!
>
> My hearty congratulations to Mr. Ford.
>
> I'm sure it will look good on his resume.
>
> >>>  *I was actually given Brian Ford*
>
> I thought slavery in this country ended with the Civil War, or is Mr. Ford
> a form of *artificial intelligence*?
>
Yeah, that's it!  I'm just a robot creation of Chris'.  That happens
automatically when you start hacking on Cygwin code, like Chris said.

> Anyhow - how much do you want for him/it?
>
> ;-D
>
Sorry, not for sale.

In all fairness, I did answer your question, all be it in a somewhat
sarcastic manner.  Reread the quote below.

I'm sure it was not really deserving of a gold star.  So, I'll gladly
relinquish it if it'll make you feel better.

Brian Ford wrote:
> On Fri, 14 Nov 2003 [EMAIL PROTECTED] wrote:
>> Chris Faylor wrote:
>>> I'm wondering what you think the term "snapshot" means.
>>>
>> cvs - as opposed to setup.exe
>>
>What do you think the cvs repository is for?
>
>> So I take it I'm wrong and can get the select() fix via default setup.exe?
>>
>Not now, but the next release will be based off cvs.  Doh!
>
>That is what snapshots are for, to test for a yet to be determined
>future release.
>
>>> Standard flip answer: Definitely by December 2004.
>>>
>> Is there such a thing as a standard "non-flip" answer?
>>
> Cygwin is a voluteer effort.  Releases do not happen on a schedule.
> Volunteer yourself, or take what you get.
>

Anyway, can we *please* just drop this noise now.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: The End - Will next cygwin1.dll release have the select() fix?

2003-11-15 Thread Brian Kelly 
> Anyway, can we *please* just drop this noise now.

Agreed - enough.

> I'll gladly relinquish it if it'll make you feel better.

HECK NO!! cgf doesn't give those out every day - and besides, in my not
so humble opinion you've contributed MORE than enough to deserve one
outside of this *noise* - as you put it. All kidding aside, the work
done by all contributors *IS* appreciated VERY MUCH and my hat is off to
you. Cygwin is improving almost daily, and it is entirely because of
contributions like yours. (I hope cgf sees fit to include this with the
chronology posted on the website).

-bk

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Brian Ford
Sent: Saturday, November 15, 2003 3:10 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Will next cygwin1.dll release have the select() fix?

On Sat, 15 Nov 2003 [EMAIL PROTECTED] wrote:

> BRAVO!
>
> My hearty congratulations to Mr. Ford.
>
> I'm sure it will look good on his resume.
>
> >>>  *I was actually given Brian Ford*
>
> I thought slavery in this country ended with the Civil War, or is Mr.
Ford
> a form of *artificial intelligence*?
>
Yeah, that's it!  I'm just a robot creation of Chris'.  That happens
automatically when you start hacking on Cygwin code, like Chris said.

> Anyhow - how much do you want for him/it?
>
> ;-D
>
Sorry, not for sale.

In all fairness, I did answer your question, all be it in a somewhat
sarcastic manner.  Reread the quote below.

I'm sure it was not really deserving of a gold star.  So, I'll gladly
relinquish it if it'll make you feel better.

Brian Ford wrote:
> On Fri, 14 Nov 2003 [EMAIL PROTECTED] wrote:
>> Chris Faylor wrote:
>>> I'm wondering what you think the term "snapshot" means.
>>>
>> cvs - as opposed to setup.exe
>>
>What do you think the cvs repository is for?
>
>> So I take it I'm wrong and can get the select() fix via default
setup.exe?
>>
>Not now, but the next release will be based off cvs.  Doh!
>
>That is what snapshots are for, to test for a yet to be determined
>future release.
>
>>> Standard flip answer: Definitely by December 2004.
>>>
>> Is there such a thing as a standard "non-flip" answer?
>>
> Cygwin is a voluteer effort.  Releases do not happen on a schedule.
> Volunteer yourself, or take what you get.
>

Anyway, can we *please* just drop this noise now.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
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: For masochists: the leap o faith

2003-11-15 Thread Robert Collins 
On Sun, 2003-11-16 at 06:09, Brian Ford wrote:
> On Sat, 15 Nov 2003, Christopher Faylor wrote:
> 
> > Btw, I've moved this discussion here from cygwin-patches because we are
> > talking about a change which could impact a number of people.  Robert is
> > submitting patches which increase the maximum path length for NT-class
> > systems.
> >
> > My concern is that PATH_MAX will be increased for this change.  It will
> > no longer reflect the win32 api MAX_PATH value and I was wondering if
> > that would cause problems for existing applications.
> >
> >
> Well, since your soliciting opinions...
> 
> I don't have much of one other than I'd really prefer to keep
> PATH_MAX/MAX_PATH and define them to the largest allowable path so they
> can still be used for sizing arrays.  I don't really care if that lenght
> is not always supported.

MAX_PATH -will not- change. It's a win32 define, not a cygwin or posix
define.

If you want to use static arrays, and don't care about supporting the
full system facilities: just use an arbitrary figure that is big enough
for your users. Remember: 640K is all you need.

> I would assume that any application that goes to the trouble of doing
> something other than bailing with an error in that case should actually
> use pathconf.

Right. The posix specs (a couple of links to opengroup are in the thread
in cygwin-patches) place the following limits:
1) if defined PATH_MAX must be the largest value [f]pathconf will
return.
2) if PATH_MAX isn't defined, and [f]pathconf doesn't have an arbitrary
limit, then calling pathconf on _PC_PATH_MAX where no limit exists can
return -1 and clear errno. For us calling pathconf _PC_PATH_MAX on / ,
we can return the current global maximum. (Note that the global maximum
we can support is actually the DOS maximum path length + the path from
the cygwin mount table. I.e. if you mount d:\[250 times]\[250
times]\[250 time] at /foo, the max path from /foo is -NOT-
CYG_MAX_PATH (the new internal buffer size), but is rather:
CYG_MAX_PATH 
  - 4 (the \\?\ prefix)
  - 1 (NULL)
  - len (d:\[250 times]\[250 times]\[250 times]
 =
  ~= CYG_MAX_PATH - 760.

encouraging the use of MAX_PATH when we have this underlying variability
is not a good thing IMO.

Chris has noted that posixly correct behaviour and common practice may
diverge. I think for this scenario, that posix behaviour allows the most
accurate representation of the variety programs may encounter on cygwin
at runtime. Therefore we'll get the best results (and perhaps uncover a
few portability bugs) going that way.

We have two choices (no particular order of preference):
a) make MAX_PATH and posix friends the maximum length path cygwin will
accept/return. Return ENAMETOOLONG on path calls on win9x, or winnt
FAT[32] calls. Update pathconf to return appropriate values.
b) blow away MAX_PATH and MAXPATHLEN so that programs using cygwin
fallback to pathconf, or 'good enough for me' static arrays.  Update
pathconf to return appropriate values.

I've no particular preference: either will support the change reasonably
well. I'm mainly keen to see the thing inside cygwin, able to be used
and understood.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Squid Patch for Cygwin 1.5

2003-11-15 Thread Robert Collins 
On Wed, 2003-11-05 at 08:06, Christian Weinberger wrote:
> After some investigation I found an interim solution to get the current 
> cygwin squid version (2.4-STABLE7) working with the new 1.5 DLL series. 
> This has been tested and works for me with 1.5.5, but should work with 
> all 1.5 versions.
> 
> A posting from Tom Oehser gave the necessary input:
> The problem is that squid assumes a maximum number of file handles 
> avalable (RLIMIT_NOFILE) of 8192. The autoconf test does not work on 
> cygwin, so it always returns the maximum value. This has always been 
> that way on the cygwin platform.
> But with version 1.5, there are fewer ressources available (less than 
> 8192) and this causes squid to fail.

Which is strange, as NOFILE is still defined at 8192. I definately need
to have a poke around in here. If possible I'll try and get cygwin's
poll size lifted again: it'd be a shame to be limiting the number of
fd's squid can use unnecessarily.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Include Problem

2003-11-15 Thread Bill C. Riemers 
> It doesn't.  Cygwin != Linux.
>
> Also, AFAIK, if a Linux application is directly including linux/*, it is
> broken.

Not necessarily.  Not every application is designed to work across different
platforms.  Sometimes a programmer may choice to sacrifice portability for
some other advantage.  In fact in some cases they may include system include
files like thos in "linux/*" just prevent people from compiling on an
unsupported platform.

Bill



--
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: Learning zsh

2003-11-15 Thread Joshua Daniel Franklin 
On Fri, Nov 14, 2003 at 11:32:58PM -0500, Christopher Faylor wrote:
> Lets recap:
> 1) X posts a message about a non-cygwin topic

Sorry, but X postings are off-topic for this list.

(ducks)

--
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: Learning zsh

2003-11-15 Thread Christopher Faylor 
On Sat, Nov 15, 2003 at 03:39:36PM -0600, Joshua Daniel Franklin wrote:
>On Fri, Nov 14, 2003 at 11:32:58PM -0500, Christopher Faylor wrote:
>> Lets recap:
>> 1) X posts a message about a non-cygwin topic
>
>Sorry, but X postings are off-topic for this list.
>
>(ducks)

Heh.  Probably the funniest message in this thread.

cgf

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

cpan/gcc cannot compile perl module after cygwin 1.5*

2003-11-15 Thread Brian . Kelly 
Before the upgrade to 1.5* - 64 bit cygwin, this used to compile with the
default configuration just fine.
Now it can't. I am aware that the entire perl IPC distribution never did
ever work with cygwin - especially named pipes. However, the Semaphore
module *did* - and before the 1.5* upgrade, compiled flawlessly with the
default configuration. Not only that, but the resulting Semaphore.pm
*worked* flawlessly as well - and is an integral part of a production
system I now maintain. Luckily, the compiled binary from the previous
version of cygwin/gcc combo works just as flawlessly with current 64-bit
release of cygwin - but I can no longer compile it with the default
installation. I have backups of the binary - so there are no real problems
currently. However, since I can't and don't want to roll-back cygwin, I
need to find a way to successfully compile it with the latest version of
cygwin/gcc. If someone can see a quick fix - or work around - to this it
would obviously be a BIG help and be much appreciated.

Brian Kelly


cpan> install IPC::Semaphore
R
unning install for module IPC::Semaphore
Running make for G/GB/GBARR/IPC-SysV-1.03.tar.gz
CPAN: Digest::MD5 loaded ok
Checksum for
/cygdrive/c/temp/.cpan/sources/authors/id/G/GB/GBARR/IPC-SysV-1.03.tar.gz
ok
Scanning cache /cygdrive/c/temp/.cpan/build for sizes
IPC-SysV-1.03/
IPC-SysV-1.03/SysV.pm
IPC-SysV-1.03/Msg.pm
IPC-SysV-1.03/MANIFEST
IPC-SysV-1.03/ChangeLog
IPC-SysV-1.03/Makefile.PL
IPC-SysV-1.03/t/
IPC-SysV-1.03/t/sem.t
IPC-SysV-1.03/t/msg.t
IPC-SysV-1.03/README
IPC-SysV-1.03/SysV.xs
IPC-SysV-1.03/Semaphore.pm
Removing previously used /cygdrive/c/temp/.cpan/build/IPC-SysV-1.03

  CPAN.pm: Going to build G/GB/GBARR/IPC-SysV-1.03.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for IPC::SysV
/usr/bin/perl.exe /usr/lib/perl5/5.8.0/ExtUtils/xsubpp  -typemap
/usr/lib/perl5/5.8.0/ExtUtils/typema
p  SysV.xs > SysV.xsc && mv SysV.xsc SysV.c
Running Mkbootstrap for IPC::SysV ()
cp Msg.pm blib/lib/IPC/Msg.pm
p  SysV.xs > SysV.xsc && mv SysV.xsc SysV.c
cp Semaphore.pm blib/lib/IPC/Semaphore.pm
cp SysV.pm blib/lib/IPC/SysV.pm
gcc -c   -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DUSEIMPORTLIB -O3
-DVERSION=\"1.03\" -DXS_VER
SION=\"1.03\"  "-I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE"   SysV.c
chmod 644 SysV.bs
cp SysV.bs blib/arch/auto/IPC/SysV/SysV.bs
chmod 644 blib/arch/auto/IPC/SysV/SysV.bs
SysV.xs: In function `XS_IPC__Msg__stat_pack':
SysV.xs:69: storage size of `ds' isn't known
SysV.xs: In function `XS_IPC__Msg__stat_unpack':
SysV.xs:89: dereferencing pointer to incomplete type
SysV.xs:92: dereferencing pointer to incomplete type
SysV.xs:95: dereferencing pointer to incomplete type
SysV.xs:97: dereferencing pointer to incomplete type
SysV.xs:99: dereferencing pointer to incomplete type
SysV.xs:101: dereferencing pointer to incomplete type
SysV.xs:103: dereferencing pointer to incomplete type
SysV.xs:105: dereferencing pointer to incomplete type
SysV.xs:107: dereferencing pointer to incomplete type
SysV.xs:109: dereferencing pointer to incomplete type
SysV.xs:111: dereferencing pointer to incomplete type
SysV.xs:113: dereferencing pointer to incomplete type
SysV.xs:115: dereferencing pointer to incomplete type
SysV.xs:117: dereferencing pointer to incomplete type
SysV.xs: In function `XS_IPC__Semaphore__stat_unpack':
SysV.xs:135: dereferencing pointer to incomplete type
SysV.xs:138: dereferencing pointer to incomplete type
SysV.xs:140: invalid use of undefined type `struct semid_ds'
SysV.xs:140: dereferencing pointer to incomplete type
SysV.xs:141: invalid use of undefined type `struct semid_ds'
SysV.xs:141: dereferencing pointer to incomplete type
SysV.xs:142: invalid use of undefined type `struct semid_ds'
SysV.xs:142: dereferencing pointer to incomplete type
SysV.xs:143: invalid use of undefined type `struct semid_ds'
SysV.xs:143: dereferencing pointer to incomplete type
SysV.xs:144: invalid use of undefined type `struct semid_ds'
SysV.xs:144: dereferencing pointer to incomplete type
SysV.xs:145: invalid use of undefined type `struct semid_ds'
SysV.xs:145: dereferencing pointer to incomplete type
SysV.xs:146: invalid use of undefined type `struct semid_ds'
SysV.xs:146: dereferencing pointer to incomplete type
SysV.xs:147: invalid use of undefined type `struct semid_ds'
SysV.xs:147: dereferencing pointer to incomplete type
SysV.xs: In function `XS_IPC__Semaphore__stat_pack':
SysV.xs:158: storage size of `ds' isn't known
SysV.xs: In function `XS_IPC__SysV_ftok':
SysV.xs:194: `no_func' undeclared (first use in this function)
SysV.xs:194: (Each undeclared identifier is reported only once
SysV.xs:194: for each function it appears in.)
SysV.xs:194: warning: `return' with a value, in function returning void
make: *** [SysV.o] Error 1
  /usr/bin/make -j3 -- NOT OK
Running make test
  Can't test without successful make
Running make install
  make had returned bad status, install seems impossible

cpan>



"WellChoice, Inc." made the follo

IGNORE: Re: cpan/gcc cannot compile perl module after cygwin 1.5*

2003-11-15 Thread Brian . Kelly 
Oops!! My goof - I meant Win32::Semaphore.  DOH!

-bk




[EMAIL PROTECTED]@cygwin.com on 11/15/2003 05:10:54 PM

Sent by:[EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc: (bcc: Brian Kelly/WTC1/Empire)

Subject:cpan/gcc cannot compile perl module after cygwin 1.5*


Before the upgrade to 1.5* - 64 bit cygwin, this used to compile with the
default configuration just fine.
Now it can't. I am aware that the entire perl IPC distribution never did
ever work with cygwin - especially named pipes. However, the Semaphore
module *did* - and before the 1.5* upgrade, compiled flawlessly with the
default configuration. Not only that, but the resulting Semaphore.pm
*worked* flawlessly as well - and is an integral part of a production
system I now maintain. Luckily, the compiled binary from the previous
version of cygwin/gcc combo works just as flawlessly with current 64-bit
release of cygwin - but I can no longer compile it with the default
installation. I have backups of the binary - so there are no real problems
currently. However, since I can't and don't want to roll-back cygwin, I
need to find a way to successfully compile it with the latest version of
cygwin/gcc. If someone can see a quick fix - or work around - to this it
would obviously be a BIG help and be much appreciated.

Brian Kelly


cpan> install IPC::Semaphore
R
unning install for module IPC::Semaphore
Running make for G/GB/GBARR/IPC-SysV-1.03.tar.gz
CPAN: Digest::MD5 loaded ok
Checksum for
/cygdrive/c/temp/.cpan/sources/authors/id/G/GB/GBARR/IPC-SysV-1.03.tar.gz
ok
Scanning cache /cygdrive/c/temp/.cpan/build for sizes
IPC-SysV-1.03/
IPC-SysV-1.03/SysV.pm
IPC-SysV-1.03/Msg.pm
IPC-SysV-1.03/MANIFEST
IPC-SysV-1.03/ChangeLog
IPC-SysV-1.03/Makefile.PL
IPC-SysV-1.03/t/
IPC-SysV-1.03/t/sem.t
IPC-SysV-1.03/t/msg.t
IPC-SysV-1.03/README
IPC-SysV-1.03/SysV.xs
IPC-SysV-1.03/Semaphore.pm
Removing previously used /cygdrive/c/temp/.cpan/build/IPC-SysV-1.03

  CPAN.pm: Going to build G/GB/GBARR/IPC-SysV-1.03.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for IPC::SysV
/usr/bin/perl.exe /usr/lib/perl5/5.8.0/ExtUtils/xsubpp  -typemap
/usr/lib/perl5/5.8.0/ExtUtils/typema
p  SysV.xs > SysV.xsc && mv SysV.xsc SysV.c
Running Mkbootstrap for IPC::SysV ()
cp Msg.pm blib/lib/IPC/Msg.pm
p  SysV.xs > SysV.xsc && mv SysV.xsc SysV.c
cp Semaphore.pm blib/lib/IPC/Semaphore.pm
cp SysV.pm blib/lib/IPC/SysV.pm
gcc -c   -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DUSEIMPORTLIB -O3
-DVERSION=\"1.03\" -DXS_VER
SION=\"1.03\"  "-I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE"   SysV.c
chmod 644 SysV.bs
cp SysV.bs blib/arch/auto/IPC/SysV/SysV.bs
chmod 644 blib/arch/auto/IPC/SysV/SysV.bs
SysV.xs: In function `XS_IPC__Msg__stat_pack':
SysV.xs:69: storage size of `ds' isn't known
SysV.xs: In function `XS_IPC__Msg__stat_unpack':
SysV.xs:89: dereferencing pointer to incomplete type
SysV.xs:92: dereferencing pointer to incomplete type
SysV.xs:95: dereferencing pointer to incomplete type
SysV.xs:97: dereferencing pointer to incomplete type
SysV.xs:99: dereferencing pointer to incomplete type
SysV.xs:101: dereferencing pointer to incomplete type
SysV.xs:103: dereferencing pointer to incomplete type
SysV.xs:105: dereferencing pointer to incomplete type
SysV.xs:107: dereferencing pointer to incomplete type
SysV.xs:109: dereferencing pointer to incomplete type
SysV.xs:111: dereferencing pointer to incomplete type
SysV.xs:113: dereferencing pointer to incomplete type
SysV.xs:115: dereferencing pointer to incomplete type
SysV.xs:117: dereferencing pointer to incomplete type
SysV.xs: In function `XS_IPC__Semaphore__stat_unpack':
SysV.xs:135: dereferencing pointer to incomplete type
SysV.xs:138: dereferencing pointer to incomplete type
SysV.xs:140: invalid use of undefined type `struct semid_ds'
SysV.xs:140: dereferencing pointer to incomplete type
SysV.xs:141: invalid use of undefined type `struct semid_ds'
SysV.xs:141: dereferencing pointer to incomplete type
SysV.xs:142: invalid use of undefined type `struct semid_ds'
SysV.xs:142: dereferencing pointer to incomplete type
SysV.xs:143: invalid use of undefined type `struct semid_ds'
SysV.xs:143: dereferencing pointer to incomplete type
SysV.xs:144: invalid use of undefined type `struct semid_ds'
SysV.xs:144: dereferencing pointer to incomplete type
SysV.xs:145: invalid use of undefined type `struct semid_ds'
SysV.xs:145: dereferencing pointer to incomplete type
SysV.xs:146: invalid use of undefined type `struct semid_ds'
SysV.xs:146: dereferencing pointer to incomplete type
SysV.xs:147: invalid use of undefined type `struct semid_ds'
SysV.xs:147: dereferencing pointer to incomplete type
SysV.xs: In function `XS_IPC__Semaphore__stat_pack':
SysV.xs:158: storage size of `ds' isn't known
SysV.xs: In function `XS_IPC__SysV_ftok':
SysV.xs:194: `no_func' undeclared (first use in this function)
SysV.xs:194: (Each undeclared identifier is reported only once
SysV.xs:194: for each function it appears in.)
SysV.xs:194: warning: `ret

trying again - cpan/gcc cannot compile perl module after cygwin 1.5*

2003-11-15 Thread Brian . Kelly 
Before the upgrade to 1.5* - 64 bit cygwin, this used to compile with the
default configuration just fine. Now it can't. I am aware that the entire
perl libwin32-0.191 distribution never did work completely with cygwin -
especially named pipes. However, the Win32::Semaphore module *did* - and
before the 1.5* upgrade, compiled flawlessly with the default
configuration. Not only that, but the resulting Win32::Semaphore.pm
*worked* flawlessly as well - and is an integral part of a production
system I now maintain. Luckily, the compiled binary from the previous
version of cygwin/gcc combo works just as flawlessly with the current
64-bit release of cygwin - but I can no longer compile it with the default
installation. I have backups of the binary - so there are no real problems
currently. However, since I can't and don't want to roll-back cygwin, I
need to find a way to successfully compile it with the latest version of
cygwin/gcc. If someone can see a quick fix - or work around - to this it
would obviously be a BIG help and be much appreciated.

Of course I'm aware that cygwin is now *64* bit compiled, and that I'm
looking to compile a *32* bit module. So I guess my first question, is
there backward compatibilty? And, if there is, how can I invoke it for
successful compilation? Also - any hope that the default installation will
ever again compile this, or is there now a need for a Win64::Semaphore
module?

Brian Kelly

- make
cp Semaphore.pm blib/lib/Win32/Semaphore.pm
/usr/bin/perl.exe /usr/lib/perl5/5.8.0/ExtUtils/xsubpp  -typemap
/usr/lib/perl5/5.8.0/ExtUtils/typema
p -typemap typemap  Semaphore.xs > Semaphore.xsc && mv Semaphore.xsc
Semaphore.c
gcc -c   -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DUSEIMPORTLIB -O3
-DVERSION=\"1.02\" -DXS_VER
SION=\"1.02\"  "-I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE"
Semaphore.c
Semaphore.c: In function `XS_Win32__Semaphore_release':
Semaphore.c:139: warning: cast to pointer from integer of different size
Running Mkbootstrap for Win32::Semaphore ()
chmod 644 Semaphore.bs
rm -f blib/arch/auto/Win32/Semaphore/Semaphore.dll
LD_RUN_PATH="" ld2  -s -L/usr/local/lib Semaphore.o  -o
blib/arch/auto/Win32/Semaphore/Semaphore.dll
 /usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE/libperl.dll.a
gcc -shared -o  Semaphore.dll -Wl,--out-implib=libSemaphore.dll.a -Wl,
--export-all-symbols -Wl,--enab
le-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib Semaphore.o
/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE/libperl.dll.a
Creating library file: libSemaphore.dll.a
Semaphore.o(.text+0x208):Semaphore.c: undefined reference to
`_CreateSemaphoreA'
Semaphore.o(.text+0x620):Semaphore.c: undefined reference to
`_OpenSemaphoreA'
Semaphore.o(.text+0x939):Semaphore.c: undefined reference to `_CloseHandle'
Semaphore.o(.text+0xc6a):Semaphore.c: undefined reference to
`_ReleaseSemaphore'
collect2: ld returned 1 exit status
perlld: *** system() failed to execute
gcc -shared -o  Semaphore.dll -Wl,--out-implib=libSemaphore.dll.a -Wl,
--export-all-symbols -Wl,--enab
le-auto-import -Wl,--stack,8388608 \
-s -L/usr/local/lib Semaphore.o
/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE/libperl.dll.a

make: *** [blib/arch/auto/Win32/Semaphore/Semaphore.dll] Error 1
[EMAIL PROTECTED] /cygdrive/c/temp/.cpan/build/libwin32-0.191/Semaphore



"WellChoice, Inc." made the following
 annotations on 11/15/2003 05:41:41 PM
--
Attention!  This electronic message contains information that may be legally
confidential and/or privileged.  The information is intended solely for the
individual or entity named above and access by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution,
or use of the contents of this information is prohibited and may be unlawful.
If you have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Release/Disclosure Statement


--
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: trying again - cpan/gcc cannot compile perl module after cygwin 1.5*

2003-11-15 Thread Robert Collins 
On Sun, 2003-11-16 at 09:41, [EMAIL PROTECTED] wrote:
> Of course I'm aware that cygwin is now *64* bit compiled, and that I'm
> looking to compile a *32* bit module. So I guess my first question, is
> there backward compatibilty? And, if there is, how can I invoke it for
> successful compilation? Also - any hope that the default installation will
> ever again compile this, or is there now a need for a Win64::Semaphore
> module?

Huh? Win32 != the 32 in cygwin that has been changed to 64. Win32 is a
published set of API's from MS. the 32 bit limitation cygwin has was for
file offsets and similar typedefs.

Why not just just walk through the erroring bits and see whats going on.
My WAG is that they used incorrect typedefs.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

No /bin directory

2003-11-15 Thread François-Denis Gonthier 
Hello all

Something just happened with my Cygwin installation.  I just had to
reinstall Cygwin from the net because I accidentally broke some things.
Anyway, the reason doesn't matter.

The install went apparently fine until I noticed to absence of the Bin
directory.  I've looked on Google for that problem but found nothing.  I
think post-install scripts that should have been executed weren't.

Is there a way to fix that?  Is there something I should have done that I
didn't?  Is my system broken in any way?

Thank you in advance

François-Denis



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