RE: Problem compiling perl module Term::ReadKey under cygwin

RE: Problem compiling perl module Term::ReadKey under cygwin

[Brad Porter]

Are you actually running it under a "command" prompt or a "cmd" prompt?

Since "command.com" is a DOS emulator for NT, the InsufficientMemory Error
sounds like a problem that might occur in DOS emulation...

cmd (CMD.EXE) is a NT native app.

Just some thoughts...

-brad


-----Original Message-----
From: Steve Kelem [ mailto:kelem@adaptivesilicon.com ]
Sent: Thursday, June 15, 2000 10:52 AM
To: cygwin@sourceware.cygnus.com
Subject: Re: Problem compiling perl module Term::ReadKey under cygwin


So, what do I need to download to get gcc to work?
(If I could download, which I can't because I get an Insufficient Memory
message if I try to run
it from a
WinNT Command Prompt window. After 2 requests to this group, I STILL have no
clue about what to
do to fix this problem!)

Steve

Chris Faylor wrote:

> On Thu, Jun 15, 2000 at 12:41:51AM -0400, Charles S. Wilson wrote:
> >Steve -
> >  Worked for me -- but I had to create E:\tmp. A few clues about my
> >setup:
> >
> >F:\cygwin == /
> >E:\ = /e
> >$HOME = /e/Users/cwilson
> >
> >I ran cpan as 'cwilson', building in /e/Users/cwilson/.cpan/*.  So, the
> >'CURRENT DRIVE' was E: even though perl is installed into /usr/local
> >(F:\cygwin\usr\local).
> >
> >CYGWIN LIST:
> >
> >I tracked down the problem: the choose_temp_base() routine in libiberty
> >(which is linked by dllwrap.exe) defines '\\' as the path separator on
> >all _WIN32 platforms. This routine checks the environment variable
> >$TMPDIR, $TMP, and $TEMP, followed by {DIRSEP}tmp, and
> >{DIRSEP}usr{DIRSEP}tmp. So, in my case $TEMP=/tmp. Then, the routine
> >adds {DIRSEP}ccXXXXXX where 'X' is a digit.
> >
> >Therefore, '/tmp\ccXXXXXX'.
> >
> >To whom should a patch for libiberty be sent?
>
> This is the code in the current libiberty:
>
> ifndef IN_GCC
> #if defined (__MSDOS__) || (defined (_WIN32) && ! defined (__CYGWIN__) &&
! defined (_UWIN))
> #define DIR_SEPARATOR '\\'
> #endif
> #endif
>
> It should do the correct thing for cygwin now, so there's no need to send
> a patch to anyone.
>
> cgf
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Chris Faylor]

On Thu, Jun 15, 2000 at 09:52:09AM -0700, Steve Kelem wrote:
>So, what do I need to download to get gcc to work?

Did you see my announcement:

"Subject: New gcc/binutils available for testing"

>(If I could download, which I can't because I get an Insufficient
>Memory message if I try to run it from a WinNT Command Prompt window.
>After 2 requests to this group, I STILL have no clue about what to do
>to fix this problem!)

Unfortunately, that's because no one has a clue as to why you are having
a problem.  AFAIK, you are the only person reporting this problem so
we don't have much data to go on.

It sounds like you need to use the "unpack via tar" method to install until
you can figure out why you are having a problem.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Steve Kelem]

So, what do I need to download to get gcc to work?
(If I could download, which I can't because I get an Insufficient Memory message if I try to run
it from a
WinNT Command Prompt window. After 2 requests to this group, I STILL have no clue about what to
do to fix this problem!)

Steve

Chris Faylor wrote:

> On Thu, Jun 15, 2000 at 12:41:51AM -0400, Charles S. Wilson wrote:
> >Steve -
> >  Worked for me -- but I had to create E:\tmp. A few clues about my
> >setup:
> >
> >F:\cygwin == /
> >E:\ = /e
> >$HOME = /e/Users/cwilson
> >
> >I ran cpan as 'cwilson', building in /e/Users/cwilson/.cpan/*.  So, the
> >'CURRENT DRIVE' was E: even though perl is installed into /usr/local
> >(F:\cygwin\usr\local).
> >
> >CYGWIN LIST:
> >
> >I tracked down the problem: the choose_temp_base() routine in libiberty
> >(which is linked by dllwrap.exe) defines '\\' as the path separator on
> >all _WIN32 platforms. This routine checks the environment variable
> >$TMPDIR, $TMP, and $TEMP, followed by {DIRSEP}tmp, and
> >{DIRSEP}usr{DIRSEP}tmp. So, in my case $TEMP=/tmp. Then, the routine
> >adds {DIRSEP}ccXXXXXX where 'X' is a digit.
> >
> >Therefore, '/tmp\ccXXXXXX'.
> >
> >To whom should a patch for libiberty be sent?
>
> This is the code in the current libiberty:
>
> ifndef IN_GCC
> #if defined (__MSDOS__) || (defined (_WIN32) && ! defined (__CYGWIN__) && ! defined (_UWIN))
> #define DIR_SEPARATOR '\\'
> #endif
> #endif
>
> It should do the correct thing for cygwin now, so there's no need to send
> a patch to anyone.
>
> cgf
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Charles S. Wilson]

Earnie Boyd wrote:
> 
> --- "Charles S. Wilson" <cwilson@ece.gatech.edu> wrote:
> -8<-
> >
> > CYGWIN LIST:
> >
> > I tracked down the problem: the choose_temp_base() routine in libiberty
> > (which is linked by dllwrap.exe) defines '\\' as the path separator on
> > all _WIN32 platforms. This routine checks the environment variable
> > $TMPDIR, $TMP, and $TEMP, followed by {DIRSEP}tmp, and
> > {DIRSEP}usr{DIRSEP}tmp. So, in my case $TEMP=/tmp. Then, the routine
> > adds {DIRSEP}ccXXXXXX where 'X' is a digit.
> >
> 
> The code I'm looking at, which I updated from CVS yesterday uses a '/' for
> DIR_SEPARATOR if __CYGWIN__ is defined.  The macro DIRSEP doesn't exist.  Thbe
> relavent code is:

Yep. I was looking at the cygwin gcc-2.95.2-1-src.tar.gz source code,
which was used to build the version of gcc everyone (until last night)
was using. However, even that version doesn't use 'DIRSEP' -- it uses
'DIR_SEPARATOR' but I didn't feel like typing that four or five times in
my message. Sorry if that caused confusion.

> 
> > Therefore, '/tmp\ccXXXXXX'.
> >
> > To whom should a patch for libiberty be sent?
> >
> 
> I don't think one is needed.
> 

You are correct. And I am relieved. :-)

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Earnie Boyd]

--- "Charles S. Wilson" <cwilson@ece.gatech.edu> wrote:
-8<-
> 
> CYGWIN LIST:
> 
> I tracked down the problem: the choose_temp_base() routine in libiberty
> (which is linked by dllwrap.exe) defines '\\' as the path separator on
> all _WIN32 platforms. This routine checks the environment variable
> $TMPDIR, $TMP, and $TEMP, followed by {DIRSEP}tmp, and
> {DIRSEP}usr{DIRSEP}tmp. So, in my case $TEMP=/tmp. Then, the routine
> adds {DIRSEP}ccXXXXXX where 'X' is a digit.
> 

The code I'm looking at, which I updated from CVS yesterday uses a '/' for
DIR_SEPARATOR if __CYGWIN__ is defined.  The macro DIRSEP doesn't exist.  Thbe
relavent code is:

-----8<--------
#ifndef IN_GCC
#if defined (__MSDOS__) || (defined (_WIN32) && ! defined (__CYGWIN__) && !
defi
ned (_UWIN))
#define DIR_SEPARATOR '\\'
#endif
#endif

#ifndef DIR_SEPARATOR
#define DIR_SEPARATOR '/'
#endif
-----8<--------

> Therefore, '/tmp\ccXXXXXX'.
> 
> To whom should a patch for libiberty be sent?
> 

I don't think one is needed.

Regards,

=====
---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://www.freeyellow.com/members5/gw32/index.html >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Charles S. Wilson]

> 
> I'm not sure who the "everyone" you're referring to but I've only seen
> only one thing that could be characterised as criticism.  I thanked
> someone for understanding the reason for the change to Cygwin.
> Hopefully that was not seen as a slam against the person who submitted
> the patch.
> 
> I am also thankful that someone took the time to track down what needed
> to be changed but I haven't reached a point where I think there is a
> crying need to change cygwin back to its old behavior.  I try to
> minimize the number of options available for the CYGWIN environment
> variable, too.  This is just in the interests of not presenting too many
> things for people to tweak that make problem debugging harder.

I understand. There are already too many CYGWIN options for me to keep
track of. 

> 
> >FWIW, I *did* track down this error. It's actually in libiberty, not
> >perl, and is the result cygwin's unusual status as a unix platform
> >running under windows: _WIN32 is defined, so libiberty uses '\' as the
> >path separator. Once I figure out to whom the patch should go (since
> >everybody seems to maintain their own version -- gcc, cygwin, binutils,
> >etc) I'll submit it.
> 
> gcc and binutils have somewhat separate versions of libiberty.  Cygwin
> uses the binutils version.  The binutils version is imported from gcc
> regularly.
> 
> But you don't need to do anything.  It's already fixed in CVS in both
> binutils and gcc (and has been for some time) and I've made an
> experimental version of binutils available with the fix.

Well, that serves me right for debugging with the tarball versions
instead of CVS. :-)

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Chris Faylor]

On Thu, Jun 15, 2000 at 01:05:58AM -0400, Charles S. Wilson wrote:
>Everyone else on the planet disagrees with both him and me.  Fine.
>That's okay, that's what open source is all about.

There are certainly people who agree with you, Chuck.  Earnie is one.

>In any case, I find it ironic that everyone's being so hard on that guy.
>He did what we all want people to do on this list!!! He
>
>(a) noticed a problem
>(b) proposed a patch
>(c) accepted criticism
>(d) proposed a revised patch
>
>It doesn't matter if the patch wasn't accepted. The fact is, on one hand
>we criticize folks for whining about bugs without attempting to fix it
>themselve -- we tell them to submit a patch. That does not mean we have
>to accept all patches that come in -- but when one DOES come in, let's
>not ridicule the submitter, OK?

I'm not sure who the "everyone" you're referring to but I've only seen
only one thing that could be characterised as criticism.  I thanked
someone for understanding the reason for the change to Cygwin.
Hopefully that was not seen as a slam against the person who submitted
the patch.

I am also thankful that someone took the time to track down what needed
to be changed but I haven't reached a point where I think there is a
crying need to change cygwin back to its old behavior.  I try to
minimize the number of options available for the CYGWIN environment
variable, too.  This is just in the interests of not presenting too many
things for people to tweak that make problem debugging harder.

>FWIW, I *did* track down this error. It's actually in libiberty, not
>perl, and is the result cygwin's unusual status as a unix platform
>running under windows: _WIN32 is defined, so libiberty uses '\' as the
>path separator. Once I figure out to whom the patch should go (since
>everybody seems to maintain their own version -- gcc, cygwin, binutils,
>etc) I'll submit it.

gcc and binutils have somewhat separate versions of libiberty.  Cygwin
uses the binutils version.  The binutils version is imported from gcc
regularly.

But you don't need to do anything.  It's already fixed in CVS in both
binutils and gcc (and has been for some time) and I've made an
experimental version of binutils available with the fix.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Charles S. Wilson]

> >
> >To whom should a patch for libiberty be sent?
> 
> This is the code in the current libiberty:
> 
> ifndef IN_GCC
> #if defined (__MSDOS__) || (defined (_WIN32) && ! defined (__CYGWIN__) && ! defined (_UWIN))
> #define DIR_SEPARATOR '\\'
> #endif
> #endif
> 
> It should do the correct thing for cygwin now, so there's no need to send
> a patch to anyone.
> 

Wonderful! Thanks for letting me know, so I didn't waste the time...

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Chris Faylor]

On Thu, Jun 15, 2000 at 12:41:51AM -0400, Charles S. Wilson wrote:
>Steve -
>  Worked for me -- but I had to create E:\tmp. A few clues about my
>setup:
>
>F:\cygwin == /
>E:\ = /e
>$HOME = /e/Users/cwilson
>
>I ran cpan as 'cwilson', building in /e/Users/cwilson/.cpan/*.  So, the
>'CURRENT DRIVE' was E: even though perl is installed into /usr/local
>(F:\cygwin\usr\local).
>
>CYGWIN LIST:
>
>I tracked down the problem: the choose_temp_base() routine in libiberty
>(which is linked by dllwrap.exe) defines '\\' as the path separator on
>all _WIN32 platforms. This routine checks the environment variable
>$TMPDIR, $TMP, and $TEMP, followed by {DIRSEP}tmp, and
>{DIRSEP}usr{DIRSEP}tmp. So, in my case $TEMP=/tmp. Then, the routine
>adds {DIRSEP}ccXXXXXX where 'X' is a digit.
>
>Therefore, '/tmp\ccXXXXXX'.
>
>To whom should a patch for libiberty be sent?

This is the code in the current libiberty:

ifndef IN_GCC
#if defined (__MSDOS__) || (defined (_WIN32) && ! defined (__CYGWIN__) && ! defined (_UWIN))
#define DIR_SEPARATOR '\\'
#endif
#endif

It should do the correct thing for cygwin now, so there's no need to send
a patch to anyone.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Charles S. Wilson]

 >
> >   This is the second complaint in two days I've gotten on this
> > cygwin-perl-/tmp issue.
> >
> This is arguably a lame excuse for your patch since as you said above,
> "...hack to work around an error in the perlbuild scripts ('\'
> shouldn't be used as a path separator)..."
> 
> Are we then supposed to change the OS and tools in order to excuse
> ourselves from fixing the bugs in our applications?
> Try this analogous scenario. Pragrammer to Microsoft Engineer: "I keep
> getting null pointer exceptions in my program, you should change Windows
> so that references to uninitialized data will now return the constant
> value 0xDEADBEEF instead of causing an exception."
> Let's stick to a convention for awhile, please!  The current one has my
> vote.
> 

Steve -
  That was not my patch. @#$!@#$. I happen to think that other guy, the
one who initially presented the patch to allow the behavior I described,
was right. Everyone else on the planet disagrees with both him and me.
Fine. That's okay, that's what open source is all about.

Your example above is flawed, though. If MS originally threw
'0xDEADBEEF' in response to a reference to uninitialized data (stupid as
that may be), then you would expect thousands of programs to test for
'0xDEADBEEF' -- and respond appropriately, such as running atexit() or
performing cleanup before shutting down. Then, MS comes along and says,
"OK, boys, from now on, we're gonna throw an exception. Instant coredump
-- you can't cleanup before exiting."

Wouldn't it be understandable if the programmers asked for a return to
the earlier behavior? Personally, I think that the mere presence of '\'
in a path should not be enough to indicate Windowsism. But reasonable
people can disagree, and your side won. For now. <g>

In any case, I find it ironic that everyone's being so hard on that guy.
He did what we all want people to do on this list!!! He

(a) noticed a problem
(b) proposed a patch
(c) accepted criticism
(d) proposed a revised patch

It doesn't matter if the patch wasn't accepted. The fact is, on one hand
we criticize folks for whining about bugs without attempting to fix it
themselve -- we tell them to submit a patch. That does not mean we have
to accept all patches that come in -- but when one DOES come in, let's
not ridicule the submitter, OK?

FWIW, I *did* track down this error. It's actually in libiberty, not
perl, and is the result cygwin's unusual status as a unix platform
running under windows: _WIN32 is defined, so libiberty uses '\' as the
path separator. Once I figure out to whom the patch should go (since
everybody seems to maintain their own version -- gcc, cygwin, binutils,
etc) I'll submit it.

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Charles S. Wilson]

Steve -
  Worked for me -- but I had to create E:\tmp. A few clues about my
setup:

F:\cygwin == /
E:\ = /e
$HOME = /e/Users/cwilson

I ran cpan as 'cwilson', building in /e/Users/cwilson/.cpan/*.  So, the
'CURRENT DRIVE' was E: even though perl is installed into /usr/local
(F:\cygwin\usr\local).

CYGWIN LIST:

I tracked down the problem: the choose_temp_base() routine in libiberty
(which is linked by dllwrap.exe) defines '\\' as the path separator on
all _WIN32 platforms. This routine checks the environment variable
$TMPDIR, $TMP, and $TEMP, followed by {DIRSEP}tmp, and
{DIRSEP}usr{DIRSEP}tmp. So, in my case $TEMP=/tmp. Then, the routine
adds {DIRSEP}ccXXXXXX where 'X' is a digit.

Therefore, '/tmp\ccXXXXXX'.

To whom should a patch for libiberty be sent?

--Chuck


Steve Kelem wrote:
> 
> "Charles S. Wilson" wrote:
> 
> > *I* know of no problems using cpan updates with my perl -- it works fine
> > for me. I haven't tried Term::ReadKey though.
> 
> Can you give it a try? If it works for you, then the problem is something on
> my system.  If it fails for you,
> then it's probably a more general problem.  I run:
> 
> perl -MCPAN -e shell
> install Term::ReadKey
> 
> > However, your problem is different. It's because of a recent change to
> > cygwin -- see the recent cygwin mailing list thread entitled 'Wierd
> > patch problem' starting with
> > http://sourceware.cygnus.com/ml/cygwin/2000-05/msg00671.html
> >
> > The change to cygwin is that ANY path that contains a backslash is
> > interpreted as a windows path, so /tmp\cc001120.base becomes "CURRENT
> > DRIVE:\\tmp\\cc001181.base".
> >
> > I think you need to create a \tmp directory in the root of the drive in
> > which you're building. So, if you're building in /usr/local/ and /usr is
> > mounted from F:\cygwin, then create F:\tmp
> 
> I have cygwin installed in H:\. There is a tmp directory in H:\..  There is no
> special mount for /tmp.
> $TMP points to C:\TEMP, which also exists.
> 
> Steve

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Charles S. Wilson]

Steve -
  Worked for me -- but I had to create E:\tmp. A few clues about my
setup:

F:\cygwin == /
E:\ = /e
$HOME = /e/Users/cwilson

I ran cpan as 'cwilson', building in /e/Users/cwilson/.cpan/*.  So, the
'CURRENT DRIVE' was E: even though perl is installed into /usr/local
(F:\cygwin\usr\local).

CYGWIN LIST:

I tracked down the problem: the choose_temp_base() routine in libiberty
(which is linked by dllwrap.exe) defines '\\' as the path separator on
all _WIN32 platforms. This routine checks the environment variable
$TMPDIR, $TMP, and $TEMP, followed by {DIRSEP}tmp, and
{DIRSEP}usr{DIRSEP}tmp. So, in my case $TEMP=/tmp. Then, the routine
adds {DIRSEP}ccXXXXXX where 'X' is a digit.

Therefore, '/tmp\ccXXXXXX'.

To whom should a patch for libiberty be sent?

--Chuck


Steve Kelem wrote:
> 
> "Charles S. Wilson" wrote:
> 
> > *I* know of no problems using cpan updates with my perl -- it works fine
> > for me. I haven't tried Term::ReadKey though.
> 
> Can you give it a try? If it works for you, then the problem is something on
> my system.  If it fails for you,
> then it's probably a more general problem.  I run:
> 
> perl -MCPAN -e shell
> install Term::ReadKey
> 
> > However, your problem is different. It's because of a recent change to
> > cygwin -- see the recent cygwin mailing list thread entitled 'Wierd
> > patch problem' starting with
> > http://sourceware.cygnus.com/ml/cygwin/2000-05/msg00671.html
> >
> > The change to cygwin is that ANY path that contains a backslash is
> > interpreted as a windows path, so /tmp\cc001120.base becomes "CURRENT
> > DRIVE:\\tmp\\cc001181.base".
> >
> > I think you need to create a \tmp directory in the root of the drive in
> > which you're building. So, if you're building in /usr/local/ and /usr is
> > mounted from F:\cygwin, then create F:\tmp
> 
> I have cygwin installed in H:\. There is a tmp directory in H:\..  There is no
> special mount for /tmp.
> $TMP points to C:\TEMP, which also exists.
> 
> Steve

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Chris Faylor]

On Wed, Jun 14, 2000 at 11:20:44PM -0400, Terry Lincoln wrote:
>Let's stick to a convention for awhile, please!  The current one has my
>vote.

Thanks.  I anticipated that the current behavior would flush out some
buggy code.  Some of it was actually in some of the tools on sourceware.

It's obvious to me that if a UNIX application is using '\' to indicate
a path separator, it's just plain broken.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Terry Lincoln]

----- Original Message -----
From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
To: "Steve Kelem" <kelem@adaptivesilicon.com>
Cc: <kjahds@kjahds.com>; "Cygwin" <cygwin@sourceware.cygnus.com>;
<khan@NanoTech.wisc.edu>
Sent: Wednesday, June 14, 2000 1:07 PM
Subject: Re: Problem compiling perl module Term::ReadKey under cygwin


> *I* know of no problems using cpan updates with my perl -- it works fine
> for me. I haven't tried Term::ReadKey though.
>
> However, your problem is different. It's because of a recent change to
> cygwin -- see the recent cygwin mailing list thread entitled 'Wierd
> patch problem' starting with
> http://sourceware.cygnus.com/ml/cygwin/2000-05/msg00671.html
>
> The change to cygwin is that ANY path that contains a backslash is
> interpreted as a windows path, so /tmp\cc001120.base becomes "CURRENT
> DRIVE:\\tmp\\cc001181.base".
>
> I think you need to create a \tmp directory in the root of the drive in
> which you're building. So, if you're building in /usr/local/ and /usr is
> mounted from F:\cygwin, then create F:\tmp
>
> This is a hack to work around an error in the perlbuild scripts ('\'
> shouldn't be used as a path separator) but it works okay on most unices.
> It's just showing up now on cygwin (and only cygwin) because of the
> recent change in cygwin's path handling.
>
> Cygwin List:
>   I think this argues for the recently proposed (and shot down) patch
> that establishes (yet another) CYGWIN= setting so that, if set, paths
> are interpreted as windows paths if and only if they contain ALL '\' and
> no '/'. If that CYGWIN= setting is unset, behavior is unchanged from the
> current.
>
>   This is the second complaint in two days I've gotten on this
> cygwin-perl-/tmp issue.
>
This is arguably a lame excuse for your patch since as you said above,
"...hack to work around an error in the perlbuild scripts ('\'
shouldn't be used as a path separator)..."

Are we then supposed to change the OS and tools in order to excuse
ourselves from fixing the bugs in our applications?
Try this analogous scenario. Pragrammer to Microsoft Engineer: "I keep
getting null pointer exceptions in my program, you should change Windows
so that references to uninitialized data will now return the constant
value 0xDEADBEEF instead of causing an exception."
Let's stick to a convention for awhile, please!  The current one has my
vote.

> --Chuck

Regards, Terry
>
>
> Steve Kelem wrote:
---->snip<-----




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Trevor Forbes]

----- Original Message -----
From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
To: "Steve Kelem" <kelem@adaptivesilicon.com>
Cc: <kjahds@kjahds.com>; "Cygwin" <cygwin@sourceware.cygnus.com>;
<khan@NanoTech.wisc.edu>
Sent: Thursday, 15 June 2000 2:37
Subject: Re: Problem compiling perl module Term::ReadKey under cygwin


> *I* know of no problems using cpan updates with my perl -- it works fine
> for me. I haven't tried Term::ReadKey though.
>
> However, your problem is different. It's because of a recent change to
> cygwin -- see the recent cygwin mailing list thread entitled 'Wierd
> patch problem' starting with
> http://sourceware.cygnus.com/ml/cygwin/2000-05/msg00671.html
>
> The change to cygwin is that ANY path that contains a backslash is
> interpreted as a windows path, so /tmp\cc001120.base becomes "CURRENT
> DRIVE:\\tmp\\cc001181.base".
>

I had a similar problem with Xfree and
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/bin/ld:
Can't open base file /tmp\cc001024.base
See the Xfree list for details :)

The fix for me, was TEMP had be set  eg TEMP=E:\Temp
and  TMPDIR had to be unset. This is the ONLY way Xfree would compile for
me.

Trevor




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problem compiling perl module Term::ReadKey under cygwin

[Steve Kelem]

"Charles S. Wilson" wrote:

> *I* know of no problems using cpan updates with my perl -- it works fine
> for me. I haven't tried Term::ReadKey though.

Can you give it a try? If it works for you, then the problem is something on
my system.  If it fails for you,
then it's probably a more general problem.  I run:

perl -MCPAN -e shell
install Term::ReadKey


> However, your problem is different. It's because of a recent change to
> cygwin -- see the recent cygwin mailing list thread entitled 'Wierd
> patch problem' starting with
> http://sourceware.cygnus.com/ml/cygwin/2000-05/msg00671.html
>
> The change to cygwin is that ANY path that contains a backslash is
> interpreted as a windows path, so /tmp\cc001120.base becomes "CURRENT
> DRIVE:\\tmp\\cc001181.base".
>
> I think you need to create a \tmp directory in the root of the drive in
> which you're building. So, if you're building in /usr/local/ and /usr is
> mounted from F:\cygwin, then create F:\tmp

I have cygwin installed in H:\. There is a tmp directory in H:\..  There is no
special mount for /tmp.
$TMP points to C:\TEMP, which also exists.

Steve

Re: Problem compiling perl module Term::ReadKey under cygwin

[Charles S. Wilson]

*I* know of no problems using cpan updates with my perl -- it works fine
for me. I haven't tried Term::ReadKey though.

However, your problem is different. It's because of a recent change to
cygwin -- see the recent cygwin mailing list thread entitled 'Wierd
patch problem' starting with
http://sourceware.cygnus.com/ml/cygwin/2000-05/msg00671.html

The change to cygwin is that ANY path that contains a backslash is
interpreted as a windows path, so /tmp\cc001120.base becomes "CURRENT
DRIVE:\\tmp\\cc001181.base".

I think you need to create a \tmp directory in the root of the drive in
which you're building. So, if you're building in /usr/local/ and /usr is
mounted from F:\cygwin, then create F:\tmp

This is a hack to work around an error in the perlbuild scripts ('\'
shouldn't be used as a path separator) but it works okay on most unices.
It's just showing up now on cygwin (and only cygwin) because of the
recent change in cygwin's path handling.

Cygwin List:
  I think this argues for the recently proposed (and shot down) patch
that establishes (yet another) CYGWIN= setting so that, if set, paths
are interpreted as windows paths if and only if they contain ALL '\' and
no '/'. If that CYGWIN= setting is unset, behavior is unchanged from the
current.

  This is the second complaint in two days I've gotten on this
cygwin-perl-/tmp issue.

--Chuck


Steve Kelem wrote:
> 
> I'm getting some compilation errors when trying to install some perl
> modules using cpan in cygwin 1.0 with the net updates.  I'm running
> Windows NT 4.0 SP6a.
> 
> One error has to do with sgtty.  Ken, do you know if that's a problem?
> Does Term::ReadKey require sgtty?
> I believe Chris Faylor @ Red Hat said there's no support for sgtty in
> cygwin, and no plans for support.
> 
> I installed Charles Wilson's Perl for Cygwin 1.0 (I have the CD.) on
> Windows NT 4.0 SP6a.
> Charles, is there a known problem with the cpan updates or the
> Term::ReadKey module using your perl?
> 
> Mumit, I've searched the cygwin archives for a solution to the collect2
> problem, and it isn't clear what the status is for this bug.
> 
> Any idea what's wrong?  I tried installing ld.exe as collect-ld.exe in
> the directory with cc1.exe
> 
> Help!
> Steve Kelem
> 
> Here's the transcript:
> % gcc --version
> 2.95.2
> % cpan_update
> cpan shell -- CPAN exploration and modules installation (v1.54)
> ReadLine support enabled
> 
> Can't ioctl TIOCGETP: Invalid argument
> Consider installing Term::ReadKey from CPAN site nearby
>         at http://www.perl.com/CPAN
> Or use
>         perl -MCPAN -e shell
> to reach CPAN. Falling back to 'stty'.
>         If you do not want to see this warning, set PERL_READLINE_NOWARN
> 
> in your environment.
> cpan> install Term::ReadKey
> Going to read /home/Kelem/.cpan/sources/authors/01mailrc.txt.gz
> Going to read
> /home/Kelem/.cpan/sources/modules/02packages.details.txt.gz
> Scanning cache /home/Kelem/.cpan/build for sizes
> Going to read /home/Kelem/.cpan/sources/modules/03modlist.data.gz
> Running make for K/KJ/KJALB/TermReadKey-2.14.tar.gz
> CPAN: MD5 loaded ok
> Checksum for
> /home/Kelem/.cpan/sources/authors/id/K/KJ/KJALB/TermReadKey-2.14.ta
> r.gz ok
> TermReadKey-2.14/
> TermReadKey-2.14/genchars.pl
> TermReadKey-2.14/README
> TermReadKey-2.14/MANIFEST
> TermReadKey-2.14/test.pl
> TermReadKey-2.14/ReadKey.pm
> TermReadKey-2.14/Makefile.PL
> TermReadKey-2.14/Configure.pm
> TermReadKey-2.14/ppport.h
> TermReadKey-2.14/ReadKey.xs
> Removing previously used /home/Kelem/.cpan/build/TermReadKey-2.14
> 
>   CPAN.pm: Going to build K/KJ/KJALB/TermReadKey-2.14.tar.gz
> 
> Checking if your kit is complete...
> Looks good
> Writing Makefile for Term::ReadKey
> mkdir blib
> mkdir blib/lib
> mkdir blib/lib/Term
> mkdir blib/arch
> mkdir blib/arch/auto
> mkdir blib/arch/auto/Term
> mkdir blib/arch/auto/Term/ReadKey
> mkdir blib/lib/auto
> mkdir blib/lib/auto/Term
> mkdir blib/lib/auto/Term/ReadKey
> mkdir blib/man3
> cp ReadKey.pm blib/lib/Term/ReadKey.pm
> AutoSplitting blib/lib/Term/ReadKey.pm (blib/lib/auto/Term/ReadKey)
> /usr/local/bin/perl -I/usr/local/lib/perl5/5.6.0 genchars.pl
> 
> Writing termio/termios section of cchars.h... Done.
> Checking for sgtty...
>         Sgtty NOT found.
> Writing sgtty section of cchars.h... Done.
> /usr/local/bin/perl -I/usr/local/lib/perl5/5.6.0/cygwin
> -I/usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/5.6.0/ExtUtils/xsubpp
> -typemap usr/local/lib/perl5/5.6.0/ExtUtils/typemap ReadKey.xs >
> ReadKey.xsc && mv ReadKey.xsc ReadKey.c
> Please specify prototyping behavior for ReadKey.xs (see perlxs manual)
> gcc -c  -fno-strict-aliasing -I/usr/local/include -DUSEIMPORTLIB -O
> -DVERSION=\"2.14\" -DXS_VERSION=\"2.14\"
> -I/usr/local/lib/perl5/5.6.0/cygwin/CORE  ReadKey.c
> Running Mkbootstrap for Term::ReadKey ()
> chmod 644 ReadKey.bs
> LD_RUN_PATH="" ld2 -o blib/arch/auto/Term/ReadKey/ReadKey.dll
> -L/usr/local/lib ReadKey.o
> /usr/local/lib/perl5/5.6.0/cygwin/CORE/libperl5_6_0.a
> dllwrap --dllname ReadKey.dll --driver-name gcc --dlltool dlltool
> --export-all-symbols --as as --output-def libReadKey.def --output-lib
> libReadKey.a \
>  -L/usr/local/lib ReadKey.o
> /usr/local/lib/perl5/5.6.0/cygwin/CORE/libperl5_6_0.a
> Warning: no export definition file provided
> dllwrap will create one, but may not be what you want
> /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/collect-ld: Can't open base file
> /tmp\cc001181.base
> collect2: ld returned 1 exit status
> dllwrap: gcc exited with status 1
> perlld: *** system() failed to execute
> dllwrap --dllname ReadKey.dll --driver-name gcc --dlltool dlltool
> --export-all-symbols --as as --output-def libReadKey.def --output-lib
> libReadKey.a \
>  -L/usr/local/lib ReadKey.o
> /usr/local/lib/perl5/5.6.0/cygwin/CORE/libperl5_6_0.a
> 
> make: *** [blib/arch/auto/Term/ReadKey/ReadKey.dll] Error 1
>   /bin/make  -- NOT OK
> Running make test
>   Oops, make had returned bad status
> Running make install
>   Oops, make had returned bad status

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Problem compiling perl module Term::ReadKey under cygwin

[Steve Kelem]

I'm getting some compilation errors when trying to install some perl
modules using cpan in cygwin 1.0 with the net updates.  I'm running
Windows NT 4.0 SP6a.

One error has to do with sgtty.  Ken, do you know if that's a problem?
Does Term::ReadKey require sgtty?
I believe Chris Faylor @ Red Hat said there's no support for sgtty in
cygwin, and no plans for support.

I installed Charles Wilson's Perl for Cygwin 1.0 (I have the CD.) on
Windows NT 4.0 SP6a.
Charles, is there a known problem with the cpan updates or the
Term::ReadKey module using your perl?

Mumit, I've searched the cygwin archives for a solution to the collect2
problem, and it isn't clear what the status is for this bug.

Any idea what's wrong?  I tried installing ld.exe as collect-ld.exe in
the directory with cc1.exe

Help!
Steve Kelem

Here's the transcript:
% gcc --version
2.95.2
% cpan_update
cpan shell -- CPAN exploration and modules installation (v1.54)
ReadLine support enabled

Can't ioctl TIOCGETP: Invalid argument
Consider installing Term::ReadKey from CPAN site nearby
        at http://www.perl.com/CPAN
Or use
        perl -MCPAN -e shell
to reach CPAN. Falling back to 'stty'.
        If you do not want to see this warning, set PERL_READLINE_NOWARN

in your environment.
cpan> install Term::ReadKey
Going to read /home/Kelem/.cpan/sources/authors/01mailrc.txt.gz
Going to read
/home/Kelem/.cpan/sources/modules/02packages.details.txt.gz
Scanning cache /home/Kelem/.cpan/build for sizes
Going to read /home/Kelem/.cpan/sources/modules/03modlist.data.gz
Running make for K/KJ/KJALB/TermReadKey-2.14.tar.gz
CPAN: MD5 loaded ok
Checksum for
/home/Kelem/.cpan/sources/authors/id/K/KJ/KJALB/TermReadKey-2.14.ta
r.gz ok
TermReadKey-2.14/
TermReadKey-2.14/genchars.pl
TermReadKey-2.14/README
TermReadKey-2.14/MANIFEST
TermReadKey-2.14/test.pl
TermReadKey-2.14/ReadKey.pm
TermReadKey-2.14/Makefile.PL
TermReadKey-2.14/Configure.pm
TermReadKey-2.14/ppport.h
TermReadKey-2.14/ReadKey.xs
Removing previously used /home/Kelem/.cpan/build/TermReadKey-2.14

  CPAN.pm: Going to build K/KJ/KJALB/TermReadKey-2.14.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for Term::ReadKey
mkdir blib
mkdir blib/lib
mkdir blib/lib/Term
mkdir blib/arch
mkdir blib/arch/auto
mkdir blib/arch/auto/Term
mkdir blib/arch/auto/Term/ReadKey
mkdir blib/lib/auto
mkdir blib/lib/auto/Term
mkdir blib/lib/auto/Term/ReadKey
mkdir blib/man3
cp ReadKey.pm blib/lib/Term/ReadKey.pm
AutoSplitting blib/lib/Term/ReadKey.pm (blib/lib/auto/Term/ReadKey)
/usr/local/bin/perl -I/usr/local/lib/perl5/5.6.0 genchars.pl

Writing termio/termios section of cchars.h... Done.
Checking for sgtty...
        Sgtty NOT found.
Writing sgtty section of cchars.h... Done.
/usr/local/bin/perl -I/usr/local/lib/perl5/5.6.0/cygwin
-I/usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/5.6.0/ExtUtils/xsubpp
-typemap usr/local/lib/perl5/5.6.0/ExtUtils/typemap ReadKey.xs >
ReadKey.xsc && mv ReadKey.xsc ReadKey.c
Please specify prototyping behavior for ReadKey.xs (see perlxs manual)
gcc -c  -fno-strict-aliasing -I/usr/local/include -DUSEIMPORTLIB -O
-DVERSION=\"2.14\" -DXS_VERSION=\"2.14\"
-I/usr/local/lib/perl5/5.6.0/cygwin/CORE  ReadKey.c
Running Mkbootstrap for Term::ReadKey ()
chmod 644 ReadKey.bs
LD_RUN_PATH="" ld2 -o blib/arch/auto/Term/ReadKey/ReadKey.dll
-L/usr/local/lib ReadKey.o
/usr/local/lib/perl5/5.6.0/cygwin/CORE/libperl5_6_0.a
dllwrap --dllname ReadKey.dll --driver-name gcc --dlltool dlltool
--export-all-symbols --as as --output-def libReadKey.def --output-lib
libReadKey.a \
 -L/usr/local/lib ReadKey.o
/usr/local/lib/perl5/5.6.0/cygwin/CORE/libperl5_6_0.a
Warning: no export definition file provided
dllwrap will create one, but may not be what you want
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/collect-ld: Can't open base file
/tmp\cc001181.base
collect2: ld returned 1 exit status
dllwrap: gcc exited with status 1
perlld: *** system() failed to execute
dllwrap --dllname ReadKey.dll --driver-name gcc --dlltool dlltool
--export-all-symbols --as as --output-def libReadKey.def --output-lib
libReadKey.a \
 -L/usr/local/lib ReadKey.o
/usr/local/lib/perl5/5.6.0/cygwin/CORE/libperl5_6_0.a

make: *** [blib/arch/auto/Term/ReadKey/ReadKey.dll] Error 1
  /bin/make  -- NOT OK
Running make test
  Oops, make had returned bad status
Running make install
  Oops, make had returned bad status