Using and linking CRT functions from Cygwin runtime binaries

[Rafael Kitover via Cygwin]

Hi, haven't been here in a while.

I am building a Cygwin runtime dependent library with some Win32 API
code. I ran into a couple of issues related to CRT functions (MSVCRT
in the case of the Cygwin dll.)

I got a linker error for an undefined symbol for the CRT function
`stricmp()`. For the time being I added a trivial reimplementation.

What I'd like to know is whether it is possible to link CRT functions
to Cygwin runtime dependent binaries at all, and if so how.

The other problem, which I am fixing on the MinGW-w64 list, is that
some MinGW Win32 API headers fail to compile because some CRT
functions are undefined under Cygwin, in this case `sprintf_s()`. What
is the right way to fix this?

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

Re: SHELLOPTS=igncr and bash --posix

[Rafael Kitover]

On 12/30/2011 1:06 AM, Dave Korn wrote:
> On 29/12/2011 21:40, Rafael Kitover wrote:
>> Some of my bash scripts, particularly ones that are #!/bin/bash --posix
>> trigger a nasty warning when I have SHELLOPTS=igncr set in my ~/.zshrc:
>>
>> rkitover@eeebox ~/src/scala % echo $SHELLOPTS
>> igncr
>> rkitover@eeebox ~/src/scala % bash --posix
>> bash: SHELLOPTS: readonly variable
>>
>> this is rather unsightly so I have turned off SHELLOPTS for now.
>>
>> Is this a bug? 
> 
>   Bug in your script I'm afraid.  SHELLOPTS is indeed a readonly variable, it
> can only be set outside bash before starting it, definitely not from within a
> startup script.  (Perhaps the reason it seems associated with --posix is
> because that selects different startup files?  I'm guessing that you may have
> ENV=~/.zshrc because it's not normal behaviour for bash to read zsh's startup
> file!)

I don't have ENV set.

If I comment out the SHELLOPTS setting in ~/.zshrc then do this the
problem still appears:

rkitover@eeebox ~ % export SHELLOPTS=igncr
rkitover@eeebox ~ % bash --posix
bash: SHELLOPTS: readonly variable
%{
%}(%n@%m)[%h] %{%}%~%{%}
$

I do not have a ~/.profile, and ~/.bash_profile just reads ~/.bashrc. I
do not set SHELLOPTS in ~/.bashrc, it only has set -o igncr.

> 
>> If so, is a fix possible?
> 
>   Use "set -o igncr" instead.

But if I want to use CRLF #/bin/sh scripts from zsh, then I have to set
SHELLOPTS.

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

broke my perlbrewed perl with rebase

[Rafael Kitover]

I made a perl to test some stuff with perlbrew, a 5.12.0.

I installed some CPAN modules into it, then I needed to rebase because
of mapping errors.

I made a copy of perlrebase and modified it thusly:

#!/bin/sh

baseaddr=0x5700

perl=`which perl`

dll=$(ldd $perl | $perl -anle 'print $F[2] if /cygperl/')

echo $dll >> rebase.lst
/usr/bin/find ~/perl5 -name \*.dll >> rebase.lst
/usr/bin/cat rebase.lst | /usr/bin/xargs chmod ug+w
[ -e /usr/bin/peflags.exe ] && /usr/bin/peflags -t $perl
/usr/bin/rebase -v -b $baseaddr -T rebase.lst
[ -e /usr/bin/peflags.exe ] && /usr/bin/grep \.dll rebase.lst \
| /usr/bin/peflags -d0 -T - >/dev/null

perlbrew puts its stuff into ~/perl5/perlbrew

I ran this script, and now my perlbrewed perl no longer works at all. It
exits immediately when I run it, not even perl -v works.

This is what I see in gdb `which perl` after doing a run:
Starting program:
/c/Users/rkitover/perl5/perlbrew/perls/perl-5.12.0/bin/perl
[New Thread 8156.0x9ec]
[Inferior 1 (process 8156) exited with code 0305]

The perlbrew command I used was:
perlbrew install -n -j 3 perl-5.12.0 -D DEBUGGING -D optimize="-ggdb3"
-D usethreads

Did I do something wrong with rebase here?

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

SHELLOPTS=igncr and bash --posix

[Rafael Kitover]

Some of my bash scripts, particularly ones that are #!/bin/bash --posix
trigger a nasty warning when I have SHELLOPTS=igncr set in my ~/.zshrc:

rkitover@eeebox ~/src/scala % echo $SHELLOPTS
igncr
rkitover@eeebox ~/src/scala % bash --posix
bash: SHELLOPTS: readonly variable

this is rather unsightly so I have turned off SHELLOPTS for now.

Is this a bug? If so, is a fix possible?

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

perlrebase, is there no better way?

[Rafael Kitover]

perlrebase is great, but it has some shortcomings.

You often have to break out of a cpan install and run it then continue,
then break out again, etc. to install some modules.

It doesn't automatically detect local::lib and perlbrew libs (perhaps I
can patch it for that.) Maybe support for a list of other dirs in
~/.perlrebase would be good.

What if ExtUtils::MakeMaker and Module::Build, in the code for the .dll
link stage, would automatically rebase the resulting .dll to some
address as set in /etc/perlrebase.conf?

Reini, what do you think?

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

Re: Double click to select within VIM behavior change

[Rafael Kitover]

On 12/28/2011 12:22 PM, Keith Christian wrote:
...
> NOTE  I'm not talking about double clicking text in the VIM window
> that turns on the "-- VISUAL --" selection indicator, since that
> operates solely within the VIM editor, and does not allow pasting the
> selected text elsewhere.
> 
> VIM no longer behaves this way.  Has there been a change in VIM or in
> the way Cygwin handles text in Mintty or PuttyCYG windows?
...

No idea, but in mintty you can hold shift to override the application's
use of the mouse. So holding shift will let you double click on words or
select text for pasting anywhere in the vim window, regardless of what
the 'mouse' option is set to. You can also :set mouse= to turn off vim's
use of the mouse, set mouse=a to turn it back on.

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

Re: vim colorscheme

[Rafael Kitover]

On 12/28/2011 4:47 PM, dirtyfishtank wrote:
> 
> Hey all. Does anyone know how to change the color scheme for the vim editor
> in Cygwin. 
> 
> I have the 'color' folder installed and in vi/vim mode I can use
> :colorscheme  to temporarily change the color of the background,
> but it only works with certain color schemes not all of them. Also, how do I
> set one of these colourschemes as a default. There is no vimrc file within
> the cygwin directory. 
> 
> Ideally I want to use the "pablo" or "torte" color scheme (which are
> installed in the 'color' folder) as they are easy to follow for development.
> 
> Any help would be great

You can make a .vimrc in your home directory as specified in
/etc/passwd, usually /home/something (echo $HOME).

If you are using the windows console rather than mintty the number of
colors is very limited, I believe 8 or 16. If you use mintty you have
256 colors which is much nicer for vim.

I use this color scheme with mintty:
http://cachemiss.com/files/256_darkdot.vim

third-party color schemes go into ~/.vim/colors

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

Re: mouse doesn't work in vim in screen in mintty

[Rafael Kitover]

On 12/9/2011 8:23 PM, Rafael Kitover wrote:
> When I run vim in mintty without screen, the mouse works, but inside
> screen it does not.
> 
> I tried changing the TERM to xterm before launching vim, but that
> doesn't help, my TERM in screen is set to screen-256color and outside it
> to xterm-256color.
> 
> When I ssh to my linux in mintty and run vim inside screen there, the
> mouse works fine.

After investigating this problem further, I found a fix:

alias vim="vim -c 'set ttymouse=xterm2'"

For whatever reason, this command has to run AFTER vim has started up
and read the ~/.vimrc, putting this command into the ~/.vimrc has no effect.

Seems like some sort of bug, but for now I will use the alias.

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

mouse doesn't work in vim in screen in mintty

[Rafael Kitover]

When I run vim in mintty without screen, the mouse works, but inside
screen it does not.

I tried changing the TERM to xterm before launching vim, but that
doesn't help, my TERM in screen is set to screen-256color and outside it
to xterm-256color.

When I ssh to my linux in mintty and run vim inside screen there, the
mouse works fine.

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

Re: Perl: Operation "bool": no method found

[Rafael Kitover]

On 3/11/2011 2:02 PM, Reini Urban wrote:
> 2011/3/9 Ken Brown:
>> On 3/8/2011 8:42 PM, Rafael Kitover wrote:
>>> On 3/8/2011 2:14 PM, Ken Brown wrote:
>>>>
>>>> I'm trying to build biber (http://biblatex-biber.sourceforge.net/) for
>>>> Cygwin.  It is written in Perl.  The documentation says to start by
>>>> running `perl Build.PL' in order to make sure that I have all the
>>>> required modules.  This fails as follows:
>>>>
>>>> $ perl Build.PL
>>>> Operation "bool": no method found, argument in overloaded package
>>>> version at /usr/lib/perl5/5.10/Module/Build/Base.pm line 1568.
>>>>
>>>> Line 1568 of Base.pm is
>>>>
>>>>   return $^V ? $self->perl_version_to_float(sprintf "%vd", $^V) : $];
>>>>
>>>> I know practically nothing about Perl, but I was hoping I could still
>>>> build biber by following instructions.  I would appreciate any hints as
>>>> to how to track down the problem.  I'm attaching Build.PL as well as
>>>> cygcheck output.
>>>>
>>>> Ken
>>>
>>> I had similar bizarre error messages related to $^V, specifically the
>>> construct sprintf "%vd", $^V, in my case related to CPAN::Reporter for
>>> doing test reports from cpan shell.
>>>
>>> This is something related to the $^V being a version.pm object, as it is
>>> in new perls, but the version class not being available for some reason,
>>> hence perl trying to call nonexistant overloaded methods.
>>>
>>> Reini, what do you think?
>>
>> Problem solved: I asked for help on the biblatex-biber forum and was told
>> that Cygwin's Module::Build module is outdated and needs to be updated via
>>
>>  perl -MCPAN -e "install Module::Build"
>>
>> This worked.
> 
> Oh my, Module::Build is my special friend and should die a painful death IMHO.
> Looks like I need to roll another small update this weekend.

Do you mean updating the version of Module::Build? That just hides the
actual problem...

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

Re: native console apps from #!/bin/sh scripts

[Rafael Kitover]

On 3/11/2011 10:34 AM, Andrew DeFaria wrote:
> On 03/11/11 02:59, Rafael Kitover wrote:
>> I can run native console apps from a console in a cygwin shell fine,
>> however, for some reason they don't work correctly from a #!/bin/sh
>> script.
>>
>> E.g., for activestate perl:
>>
>> TERM=dumb /c/Perl/bin/perl -MCPAN -e shell
>>
>> run from zsh prompt works correctly with readline support.
>>
>> Now if I put that in a script:
>>
>> #!/bin/sh
>>
>> TERM=dumb /c/Perl/bin/perl -MCPAN -e shell
>>
>> then when I run the script the readline support is disabled for some
>> reason.
>>
>> What are differences in environment in a script as opposed to the
>> regular prompt that would cause this? And is there a workaround?
>>
>> Does it have something to do with STDIN redirection away from the
>> console?
> Have you tried using Cygwin's Perl instead of ActiveState?

I actually use cygwin, activestate and strawberry perl on this machine.
I have zsh functions to switch between them (set up PATH, aliases, etc..)

There are different issues with all three of them, for example DBD::ADO
does not work on Cygwin perl, which I needed for a recent project. I'd
like to get it to work on Cygwin, but I'm not sure where to start. I
asked about this issue on the list:

http://sourceware.org/ml/cygwin/2011-02/msg00240.html

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

native console apps from #!/bin/sh scripts

[Rafael Kitover]

I can run native console apps from a console in a cygwin shell fine,
however, for some reason they don't work correctly from a #!/bin/sh script.

E.g., for activestate perl:

TERM=dumb /c/Perl/bin/perl -MCPAN -e shell

run from zsh prompt works correctly with readline support.

Now if I put that in a script:

#!/bin/sh

TERM=dumb /c/Perl/bin/perl -MCPAN -e shell

then when I run the script the readline support is disabled for some reason.

What are differences in environment in a script as opposed to the
regular prompt that would cause this? And is there a workaround?

Does it have something to do with STDIN redirection away from the console?

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

Re: Perl: Operation "bool": no method found

[Rafael Kitover]

On 3/8/2011 2:14 PM, Ken Brown wrote:
> I'm trying to build biber (http://biblatex-biber.sourceforge.net/) for
> Cygwin.  It is written in Perl.  The documentation says to start by
> running `perl Build.PL' in order to make sure that I have all the
> required modules.  This fails as follows:
> 
> $ perl Build.PL
> Operation "bool": no method found, argument in overloaded package
> version at /usr/lib/perl5/5.10/Module/Build/Base.pm line 1568.
> 
> Line 1568 of Base.pm is
> 
>   return $^V ? $self->perl_version_to_float(sprintf "%vd", $^V) : $];
> 
> I know practically nothing about Perl, but I was hoping I could still
> build biber by following instructions.  I would appreciate any hints as
> to how to track down the problem.  I'm attaching Build.PL as well as
> cygcheck output.
> 
> Ken

I had similar bizarre error messages related to $^V, specifically the
construct sprintf "%vd", $^V, in my case related to CPAN::Reporter for
doing test reports from cpan shell.

This is something related to the $^V being a version.pm object, as it is
in new perls, but the version class not being available for some reason,
hence perl trying to call nonexistant overloaded methods.

Reini, what do you think?

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

Re: Detect mintty in .zshrc?

[Rafael Kitover]

On 3/4/2011 7:26 AM, Andy Koppe wrote:
> On 3 March 2011 18:31, Rafael Kitover wrote:
>> I put this block at the top of my .zshrc:
>>
>> if [ "$TERM" = "cygwin" -o "$TERM" = "dumb" ]; then
>>  export RUNNING_IN_CONSOLE=1
>>  export TERM=cygwin
>> fi
>>
>> later I switch on "$RUNNING_IN_CONSOLE" to see if I'm in a real console.
> 
> How come you need to guard against TERM==dumb? Cygwin shouldn't set it to 
> that.

When I installed SUA (and haven't played with it yet) it for some reason
set TERM=dumb in my control panel env vars. Cygwin apparently only sets
it to 'cygwin' if it's initially unset, which makes sense.

In addition, the native Perl readline implementation only turns on if
TERM is unset or is set to 'dumb', for some reason, so I have aliases in
my .zshrc to run scripts with TERM=dumb where I want the readline to be
on for ActivePerl/Strawberry.

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

Re: winmm.dll error 487 is easily reproducible

[Rafael Kitover]

On 3/4/2011 5:13 AM, Corinna Vinschen wrote:
> On Mar  4 05:03, Rafael Kitover wrote:
>> On 3/4/2011 4:52 AM, Corinna Vinschen wrote:
>>> On Mar  4 05:09, Andy Koppe wrote:
>>>> On 2 March 2011 13:08, EXCOFFIER Denis wrote:
>>>>> P.S.: By the way, what is the normal way to install snapshots? It is
>>>>> easy to replace cygwin1.dll (keeping around the working one), but in order
>>>>> to test the cygwin1 package in full (eg to check within stdio.h whether
>>>>> vsnprintf is included under __STRICT_ANSI__ or not)?
>>>>
>>>> You should usually install the cygwin-inst-*.tar.bz2 tarball
>>>> containing all the relevant headers and tools along with the DLL.
>>>>
>>>> There's a FAQ entry describing how to install it at
>>>> http://cygwin.com/faq-nochunks.html#faq.setup.snapshots.
>> ...
>>
>> I was just shutting everything down, going to c:\cygwin and untarring
>> from msysGit.
>>
>> But apparently that's not correct because now I have stuff in
>> C:\cygwin\usr\bin .
>>
>> Feature request: would it be possible to make the -inst snapshots not
>> depend on the mounts so you could just untar them from cmd/winrar/7zip/msys?
> 
> You could also just create two junction points
> 
>   C:/cygwin/usr/bin -> C:/cygwin/bin
>   C:/cygwin/usr/lib -> C:/cygwin/lib

Brilliant, thank you :)

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

Re: winmm.dll error 487 is easily reproducible

[Rafael Kitover]

On 3/4/2011 4:52 AM, Corinna Vinschen wrote:
> On Mar  4 05:09, Andy Koppe wrote:
>> On 2 March 2011 13:08, EXCOFFIER Denis wrote:
>>> P.S.: By the way, what is the normal way to install snapshots? It is
>>> easy to replace cygwin1.dll (keeping around the working one), but in order
>>> to test the cygwin1 package in full (eg to check within stdio.h whether
>>> vsnprintf is included under __STRICT_ANSI__ or not)?
>>
>> You should usually install the cygwin-inst-*.tar.bz2 tarball
>> containing all the relevant headers and tools along with the DLL.
>>
>> There's a FAQ entry describing how to install it at
>> http://cygwin.com/faq-nochunks.html#faq.setup.snapshots.
...

I was just shutting everything down, going to c:\cygwin and untarring
from msysGit.

But apparently that's not correct because now I have stuff in
C:\cygwin\usr\bin .

Feature request: would it be possible to make the -inst snapshots not
depend on the mounts so you could just untar them from cmd/winrar/7zip/msys?

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

Re: screen and native win console apps

[Rafael Kitover]

On 3/3/2011 1:51 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Rafael Kitover sent the following at Thursday, March 03, 2011 1:29 PM
>> It seems when in screen in the console, native windows programs that use
>> the console don't work correctly.
> 
> Not unexpected.  See the documentation.  The following is a good place to
> start.  Or search the mailing list.
> http://cygwin.com/cygwin-ug-net/using-effectively.html#using-console

I have a nice setup now with Console2:

https://sourceforge.net/projects/console/

and ansicon:

http://adoxa.110mb.com/ansicon/index.html

I have to start the shell through cmd.exe to activate the ansicon, like so:

cmd /c "c:\cygwin\bin\zsh.exe --login -i"

the tabs in Console2 are nice, not quite screen, but still good.

Maybe I'll look into getting console apps to work with screen, I doubt
it would be easy though...

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

Re: ssh and user env vars from control panel

[Rafael Kitover]

I made this block for my .zshrc and .bashrc :

if [ -z "$APPDATA" ]; then
  # ssh session, set env vars
  
  # this from Corinna at http://cygwin.com/ml/cygwin/2010-08/msg00246.html
  _sid=$(grep "^$USER:" /etc/passwd | sed -e 
's/[^:]*:[^:]*:[^:]*:[^:]*:[^:]*,\(S-1-5-[^:]*\):.*/\1/')
  _prof=$(cat /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows\ 
NT/CurrentVersion/ProfileList/${_sid}/ProfileImagePath)
  export APPDATA="${_prof}\\AppData\\Roaming"
  export LOCALAPPDATA="${_prof}\\AppData\\Local"
  unset _sid
  unset _prof

  echo | powershell -noprofile -command '$env = 
[environment]::GetEnvironmentVariables("User"); foreach ($key in $env.Keys) { 
$line = "export " + $key + "=" + "'\''" + $env.$key + "'\''"; write-host $line 
}' | while read -r env_var; do
ifecho $env_var | grep -q '^export HOME=' \
   || echo $env_var | grep -q '^export PATH='; then
  continue
fi
eval $env_var
  done
  unset env_var
fi

maybe someone else will find it useful.

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

Re: Detect mintty in .zshrc?

[Rafael Kitover]

On 3/3/2011 7:21 AM, Andy Koppe wrote:
> On 3 March 2011 10:10, Rafael Kitover wrote:
>> I was wondering if there's a way in my .zshrc to determine if the shell
>> is running in mintty or in a regular windows console.
> 
> Check $TERM. It defaults to 'xterm' in mintty and 'cygwin' in the console.
> 
> Andy

Thank you, that works for me, I put this block at the top of my .zshrc:

if [ "$TERM" = "cygwin" -o "$TERM" = "dumb" ]; then
  export RUNNING_IN_CONSOLE=1
  export TERM=cygwin
fi

later I switch on "$RUNNING_IN_CONSOLE" to see if I'm in a real console.

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

screen and native win console apps

[Rafael Kitover]

It seems when in screen in the console, native windows programs that use
the console don't work correctly.

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

Detect mintty in .zshrc?

[Rafael Kitover]

Hello,

I was wondering if there's a way in my .zshrc to determine if the shell
is running in mintty or in a regular windows console.

I need to know this to set some environment variables correctly.

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

ssh and user env vars from control panel

[Rafael Kitover]

Hello list,

I generally set most of my environment variables in the System control
panel for my user, instead of in my .bashrc/.zshrc

I noticed that when I log in to Cygwin via ssh, these environment
variables are not available.

Would this be considered a misfeature?

I'll probably hack together a little powershell script and stick it in
my .zshrc to set all these env vars so that I have them for ssh.

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

Re: ssh ... PTY allocation request failed on channel 0

[Rafael Kitover]

On 2/28/2011 8:51 PM, Mirko Vukovic wrote:
> On Mon, Feb 28, 2011 at 8:45 PM, Mirko Vukovic wrote:
>> Hello,
>>
>> I am trying to ssh to g...@github.com, and I get the error
>> "PTY allocation request failed on channel 0"
...

That message is coming from github.com, it does not allow opening
interactive sessions. You can only use it for git.

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

Re: The tree command

[Rafael Kitover]

On 2/15/2011 4:17 AM, Fergus wrote:
>>> The source is here:
>>> ftp://mama.indstate.edu/linux/tree/
>>> edit the Makefile to uncomment the Cygwin section and it will build
> cleanly.
> 
> Yes, works perfectly.
> FWIW: I wish I'd edited the Makefile additionally to so that
> prefix = /usr/local
> rather than the default /usr (but this is just a personal preference for
> the location of extras).
> Fergus

I use stow for this.

Like so:

mkdir /usr/local/stow
mkdir /usr/local/stow/tree-1.5.3
make
make install prefix=/usr/local/stow/tree-1.5.3
cd /usr/local/stow
stow tree-1.5.3

Now you have a symlink, /usr/local/bin/tree .

To remove the symlinks, you just do:

cd /usr/local/stow
stow -D tree-1.5.3

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

Re: The tree command

[Rafael Kitover]

On 2/14/2011 4:23 PM, Mark Hobley wrote:
> It would be really useful to have a tree command available from the 
> cygwin shell. has anyone managed to find a working tree command yet? We could
> really do with this in the cygwin archive.

The source is here:

ftp://mama.indstate.edu/linux/tree/

edit the Makefile to uncomment the Cygwin section and it will build cleanly.

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

Re: ADO does not work from bash

[Rafael Kitover]

On 2/9/2011 7:30 AM, Rafael Kitover wrote:
> I first reported this problem to the Win32::OLE Perl module RT queue,
> but as it turns out, the problem is in the Cygwin shell environment and
> not in the Cygwin perl or the module.
> 
> From Cygwin bash:
> 
> $ perl -MWin32::OLE -wle 'Win32::OLE->new("ADODB.Connection")'
> Win32::OLE(0.1709) error 0x8007007e: "The specified module could not be
> found" at -e line 1
> 
> In a cmd.exe window:
> 
> c:\users\rkitover>c:\cygwin\bin\perl -MWin32::OLE -wle
> "Win32::OLE->new(q{ADODB.Connection})"
> 
> c:\users\rkitover>
> 
> that executes successfully.
> 
> Any ideas what can cause this?
> 
> It seems unlikely to be environment variables as Cygwin leaves most
> environment variables alone, and COMSPEC is still set to cmd.exe.

Anyone have an idea?

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

ADO does not work from bash

[Rafael Kitover]

I first reported this problem to the Win32::OLE Perl module RT queue,
but as it turns out, the problem is in the Cygwin shell environment and
not in the Cygwin perl or the module.

>From Cygwin bash:

$ perl -MWin32::OLE -wle 'Win32::OLE->new("ADODB.Connection")'
Win32::OLE(0.1709) error 0x8007007e: "The specified module could not be
found" at -e line 1

In a cmd.exe window:

c:\users\rkitover>c:\cygwin\bin\perl -MWin32::OLE -wle
"Win32::OLE->new(q{ADODB.Connection})"

c:\users\rkitover>

that executes successfully.

Any ideas what can cause this?

It seems unlikely to be environment variables as Cygwin leaves most
environment variables alone, and COMSPEC is still set to cmd.exe.

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

Re: /bin/rebaseall fails

[Rafael Kitover]

On 2/8/2011 10:42 AM, David Means wrote:

When running rebaseall, I receive a #13 error from FixImage:

$ /bin/rebaseall
/usr/lib/cygicudata.dll: skipped because nonexistent
/usr/lib/cygicui18n.dll: skipped because nonexistent
/usr/lib/cygicuio.dll: skipped because nonexistent
/usr/lib/cygicule.dll: skipped because nonexistent
/usr/lib/cygiculx.dll: skipped because nonexistent
/usr/lib/cygicutu.dll: skipped because nonexistent
/usr/lib/cygicuuc.dll: skipped because nonexistent
FixImage (/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll) failed
  with last error = 13
$
You have to skip mingw .dlls, I was told this would be fixed in the next 
version of rebaseall.


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

Re: Default state of the desktop shortcut checkbox in setup.exe

[Rafael Kitover]

On 2/3/2011 6:26 AM, Bruce Cran wrote:

Hi,

I'd like to suggest making the default state of the desktop shortcut
checkbox in setup.exe unchecked. This would make it follow Microsoft's
desktop guidelines at
http://msdn.microsoft.com/en-us/library/aa511450.aspx . I don't know
about other people but it often irritates me that I need to uncheck it
each time because I don't like application icons on the desktop.



I second this request, I have my own icon using mintty, and it's 
annoying to also have to have the default icon to not have to click the 
checkbox every time I run setup...


By the way, I LOVE mintty, it is awesome :) Thinking about doing some 
work on it to read .Xdefaults for the color scheme (or at least have a 
configurable color scheme) and an option to detect URLs like the matcher 
plugin in urxvt or some of the Putty variants like KiTTy/Puttytray.


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

Re: bad PATH conversion under XP

[Rafael Kitover]

On 1/25/2011 7:14 PM, Cyrille Lefevre wrote:


Hi,

v2$ uname -a
CYGWIN_NT-5.1 PC213736 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin

aka

Windows XP Professional Ver 5.1 Build 2600 Service Pack 3

though SSH at least :

v2$ regtool get /machine/SYSTEM/CurrentControlSet/Control/Session\
Manager/Environment/PATH
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\orawin\BIN;C:\Program
Files\ATI Technologies\ATI Control Panel;"C:\Program
Files\Hummingbird\Connectivity\7.00\Accessories\";C:\Program
Files\QuickTime\QTSystem\;D:\sfu\Perl\bin\;D:\sfu\common\;C:\WINDOWS\system32\WindowsPowerShell\v1.0\;C:\Program
Files\Samsung\Samsung PC Studio 3\

gives :

/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/orawin/BIN:/cygdrive/c/Program
Files/ATI Technologies/ATI Control Panel:"C:/Program
Files/Hummingbird/Connectivity/7.00/Accessories/":/cygdrive/c/Program
Files/QuickTime/QTSystem/:/cygdrive/d/sfu/Perl/bin/:/cygdrive/d/sfu/common/:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0/:/cygdrive/c/Program
Files/Samsung/Samsung PC Studio 3/:/bin

note the unconverted path between double-quotes :

"C:/Program Files/Hummingbird/Connectivity/7.00/Accessories/"


I saw this problem on msys, I think it applies to cygwin as well.

If you just go into environment under advanced system settings in 
control panel and remove the double quotes, it will work correctly. I'm 
on Windows 7.




also, how about to get rid of final slashes (.../ => ...) ?


You could reprocess your PATH in your .bashrc, but the final slashes 
should have no effect on how the PATH is actually used...


I cobbled together this awk script, I don't actually know awk :)

export PATH=$(awk 
'BEGIN{RS="[:\n]"}{if(NR>1){printf(":")}sub(/\/$/,"",$0);printf("%s",$0)}' 
<<<$PATH)




this appear to work well under Windows Vista (i.e. : /cygdrive/c/Program
Files/Hummingbird/Connectivity/7.00/Accessories)

Regards,

Cyrille Lefevre


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

Re: windows paths in shebang lines

[Rafael Kitover]

On 1/23/2011 10:26 PM, Rafael Kitover wrote:

On 1/23/2011 5:59 PM, Jeremy Bopp wrote:

On 01/23/2011 03:47 PM, Rafael Kitover wrote:

When a script's shebang line has a windows path, rather than a cygwin
path, it does not work:

rkitover@eeebox ~
$ head -1 /cygdrive/c/Perl64/site/bin/ack
#!C:\Perl64\bin\perl

rkitover@eeebox ~
$ /cygdrive/c/Perl64/site/bin/ack --version
Can't open perl script "/cygdrive/c/Perl64/site/bin/ack": No such file
or directory

On msys (msysGit) this works correctly:

rkitover@EEEBOX ~
$ /c/Perl64/site/bin/ack --version
ack 1.94
Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe

Copyright 2005-2010 Andy Lester.

This program is free software. You may modify or distribute it
under the terms of the Artistic License v2.0.

Any chance this could be fixed? This would be a very nice feature for
users of Strawberry Perl and similar.


The problem is not that you're using a Windows path instead of a Cygwin
path in the shebang line; although, that is not officially supported
under Cygwin. Rather, the problem is that the version of Perl being run
as a result of that shebang line does not understand Cygwin paths.
That's why you see this error:

Can't open perl script "/cygdrive/c/Perl64/site/bin/ack": No such file
or directory

That's the Perl interpreter telling you that it doesn't understand the
path that was given to it for the ack script, so Perl is running at this
point which means that the shebang line is understood correctly. You
should probably go read about how shebang lines work in general, but the
short and sweet is that the shebang line is the first part of a command
line to be run where the last part is the command line used to run the
file that contains the shebang line itself. IOW, the command line used
in your first example is ultimately:

C:\Perl64\bin\perl /cygdrive/c/Perl64/site/bin/ack --version


Ahh yes, I wasn't thinking about this clearly, thank you for the
explanation :)



You have 3 potential solutions to your problem:

1) Run Perl explicitly with the Windows path to the script as an
argument:
/cygdrive/c/Perl64/bin/perl C:/Perl64/site/bin/ack

2) Change into the C: drive and use a relative path to the ack script
when you run it:
cd /cygdrive/c
Perl64/site/bin/ack

3) Change your cygdrive mount location to / so that the path to the ack
script will be /c/Perl64/site/bin/ack under Cygwin.

Option 3 is the real hack. I think it should work because it appears in
your successful example that the Perl you want to use is able to
translate paths such as /c/path/to/something to C:/path/to/something
internally. By adjusting the cygdrive mount location to /, you will
cause Cygwin to send a compatible path to Perl when you run the script
as /c/Perl64/site/bin/ack.

-Jeremy


Unfortunately, that's not enough to get it to work:

$ /c/Perl64/site/bin/ack --version
Can't open perl script "/c/Perl64/site/bin/ack": No such file or directory

$ /c/Perl64/bin/perl /c/Perl64/site/bin/ack --version
Can't open perl script "/c/Perl64/site/bin/ack": No such file or directory

$ /c/Perl64/bin/perl /Perl64/site/bin/ack --version
ack 1.94
Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe
...

msys seems to do something special for this to work correctly, it also
seems to translate its paths to windows paths when running windows
executables automatically, a very nice feature.

For this to work in cygwin I'd have to do something like mount c: as /,
which I'm guessing would break absolutely everything :)


I got this to work!

Along with "mount -c /" I did this:

mklink /D c:\c c:\

to create a directory junction.

Now:

$ head -1 /c/Perl64/site/bin/ack
#!C:\Perl64\bin\perl

rkitover@eeebox ~
$ /c/Perl64/site/bin/ack --version
ack 1.94
Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe

Yay!

Now I just need to convince activestate to use proper shebang lines 
instead of #!/usr/bin/perl .


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

Re: windows paths in shebang lines

[Rafael Kitover]

On 1/23/2011 6:12 PM, Andrew DeFaria wrote:

On 01/23/2011 05:59 PM, Jeremy Bopp wrote:

On 01/23/2011 03:47 PM, Rafael Kitover wrote:

When a script's shebang line has a windows path, rather than a cygwin
path, it does not work:

rkitover@eeebox ~
$ head -1 /cygdrive/c/Perl64/site/bin/ack
#!C:\Perl64\bin\perl

rkitover@eeebox ~
$ /cygdrive/c/Perl64/site/bin/ack --version
Can't open perl script "/cygdrive/c/Perl64/site/bin/ack": No such file
or directory

On msys (msysGit) this works correctly:

rkitover@EEEBOX ~
$ /c/Perl64/site/bin/ack --version
ack 1.94
Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe

Copyright 2005-2010 Andy Lester.

This program is free software. You may modify or distribute it
under the terms of the Artistic License v2.0.

Any chance this could be fixed? This would be a very nice feature for
users of Strawberry Perl and similar.

The problem is not that you're using a Windows path instead of a Cygwin
path in the shebang line; although, that is not officially supported
under Cygwin. Rather, the problem is that the version of Perl being run
as a result of that shebang line does not understand Cygwin paths.
That's why you see this error:

Can't open perl script "/cygdrive/c/Perl64/site/bin/ack": No such file
or directory

That's the Perl interpreter telling you that it doesn't understand the
path that was given to it for the ack script, so Perl is running at this
point which means that the shebang line is understood correctly. You
should probably go read about how shebang lines work in general, but the
short and sweet is that the shebang line is the first part of a command
line to be run where the last part is the command line used to run the
file that contains the shebang line itself. IOW, the command line used
in your first example is ultimately:

C:\Perl64\bin\perl /cygdrive/c/Perl64/site/bin/ack --version

You have 3 potential solutions to your problem:

1) Run Perl explicitly with the Windows path to the script as an
argument:
/cygdrive/c/Perl64/bin/perl C:/Perl64/site/bin/ack

2) Change into the C: drive and use a relative path to the ack script
when you run it:
cd /cygdrive/c
Perl64/site/bin/ack

3) Change your cygdrive mount location to / so that the path to the ack
script will be /c/Perl64/site/bin/ack under Cygwin.

Option 3 is the real hack. I think it should work because it appears in
your successful example that the Perl you want to use is able to
translate paths such as /c/path/to/something to C:/path/to/something
internally. By adjusting the cygdrive mount location to /, you will
cause Cygwin to send a compatible path to Perl when you run the script
as /c/Perl64/site/bin/ack.

-Jeremy


My question would be: Why are you running a C:\Perl64\bin\perl.exe
instead of just running /usr/bin/perl (AKA C:/Cygwin/bin/perl.exe)? IOW
why are you not running Cygwin's Perl. My guess is that
C:\Perl64\bin\perl.exe is some ActiveState based Perl and you'll only
run into problems using that with a "Cygwin frame of mine". Just run
Cygwin's Perl instead!


But I do! :)

I'm a CPAN developer, I love all perls and run as many of them as 
possible :)


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

Re: windows paths in shebang lines

[Rafael Kitover]

On 1/23/2011 5:59 PM, Jeremy Bopp wrote:

On 01/23/2011 03:47 PM, Rafael Kitover wrote:

When a script's shebang line has a windows path, rather than a cygwin
path, it does not work:

rkitover@eeebox ~
$ head -1 /cygdrive/c/Perl64/site/bin/ack
#!C:\Perl64\bin\perl

rkitover@eeebox ~
$ /cygdrive/c/Perl64/site/bin/ack --version
Can't open perl script "/cygdrive/c/Perl64/site/bin/ack": No such file
or directory

On msys (msysGit) this works correctly:

rkitover@EEEBOX ~
$ /c/Perl64/site/bin/ack --version
ack 1.94
Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe

Copyright 2005-2010 Andy Lester.

This program is free software.  You may modify or distribute it
under the terms of the Artistic License v2.0.

Any chance this could be fixed? This would be a very nice feature for
users of Strawberry Perl and similar.


The problem is not that you're using a Windows path instead of a Cygwin
path in the shebang line; although, that is not officially supported
under Cygwin.  Rather, the problem is that the version of Perl being run
as a result of that shebang line does not understand Cygwin paths.
That's why you see this error:

Can't open perl script "/cygdrive/c/Perl64/site/bin/ack": No such file
or directory

That's the Perl interpreter telling you that it doesn't understand the
path that was given to it for the ack script, so Perl is running at this
point which means that the shebang line is understood correctly.  You
should probably go read about how shebang lines work in general, but the
short and sweet is that the shebang line is the first part of a command
line to be run where the last part is the command line used to run the
file that contains the shebang line itself.  IOW, the command line used
in your first example is ultimately:

C:\Perl64\bin\perl /cygdrive/c/Perl64/site/bin/ack --version


Ahh yes, I wasn't thinking about this clearly, thank you for the 
explanation :)




You have 3 potential solutions to your problem:

1) Run Perl explicitly with the Windows path to the script as an argument:
   /cygdrive/c/Perl64/bin/perl C:/Perl64/site/bin/ack

2) Change into the C: drive and use a relative path to the ack script
when you run it:
   cd /cygdrive/c
   Perl64/site/bin/ack

3) Change your cygdrive mount location to / so that the path to the ack
script will be /c/Perl64/site/bin/ack under Cygwin.

Option 3 is the real hack.  I think it should work because it appears in
your successful example that the Perl you want to use is able to
translate paths such as /c/path/to/something to C:/path/to/something
internally.  By adjusting the cygdrive mount location to /, you will
cause Cygwin to send a compatible path to Perl when you run the script
as /c/Perl64/site/bin/ack.

-Jeremy


Unfortunately, that's not enough to get it to work:

$ /c/Perl64/site/bin/ack --version
Can't open perl script "/c/Perl64/site/bin/ack": No such file or directory

$ /c/Perl64/bin/perl /c/Perl64/site/bin/ack --version
Can't open perl script "/c/Perl64/site/bin/ack": No such file or directory

$ /c/Perl64/bin/perl /Perl64/site/bin/ack --version
ack 1.94
Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe
...

msys seems to do something special for this to work correctly, it also 
seems to translate its paths to windows paths when running windows 
executables automatically, a very nice feature.


For this to work in cygwin I'd have to do something like mount c: as /, 
which I'm guessing would break absolutely everything :)


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

windows paths in shebang lines

[Rafael Kitover]

When a script's shebang line has a windows path, rather than a cygwin 
path, it does not work:


rkitover@eeebox ~
$ head -1 /cygdrive/c/Perl64/site/bin/ack
#!C:\Perl64\bin\perl

rkitover@eeebox ~
$ /cygdrive/c/Perl64/site/bin/ack --version
Can't open perl script "/cygdrive/c/Perl64/site/bin/ack": No such file 
or directory


On msys (msysGit) this works correctly:

rkitover@EEEBOX ~
$ /c/Perl64/site/bin/ack --version
ack 1.94
Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe

Copyright 2005-2010 Andy Lester.

This program is free software.  You may modify or distribute it
under the terms of the Artistic License v2.0.

Any chance this could be fixed? This would be a very nice feature for 
users of Strawberry Perl and similar.


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

Re: failing to clone a git repo via ssh

[Rafael Kitover]

I just realized this bug is replicatable without having ssh access to 
our repo, you just need the cygwin sshd enabled, and the guy with access 
to the gitosis went off somewhere anyway...


Here are the steps:

cd ~
mkdir tmp
cd tmp
git clone git://git.shadowcat.co.uk/dbsrgits/DBIx-Class.git dbic_git_url
git clone `whoami`@localhost:tmp/dbic_git_url dbic_ssh

On 1/23/2011 5:01 AM, Rafael Kitover wrote:

This repo clones fine in msysgit and on linux over ssh, but on cygwin
this is what happens:

$ git clone dbsrg...@git.shadowcat.co.uk:DBIx-Class.git dbic
Cloning into dbic...
Warning: untrusted X11 forwarding setup failed: xauth key data not
generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
remote: Counting objects: 43957, done.
remote: Compressing objects: 100% (16772/16772), done.
fatal: The remote end hung up unexpectedly6 MiB | 384 KiB/s
fatal: early EOFs: 89% (39122/43957), 5.64 MiB | 402 KiB/s
fatal: index-pack failed

The git:// URL works fine
(git://git.shadowcat.co.uk/dbsrgits/DBIx-Class.git).

Come to #dbix-class on irc.perl.org if you want me to add your ssh key
added, or attach it here...

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



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

failing to clone a git repo via ssh

[Rafael Kitover]

This repo clones fine in msysgit and on linux over ssh, but on cygwin 
this is what happens:


$ git clone dbsrg...@git.shadowcat.co.uk:DBIx-Class.git dbic
Cloning into dbic...
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
remote: Counting objects: 43957, done.
remote: Compressing objects: 100% (16772/16772), done.
fatal: The remote end hung up unexpectedly6 MiB | 384 KiB/s
fatal: early EOFs:  89% (39122/43957), 5.64 MiB | 402 KiB/s
fatal: index-pack failed

The git:// URL works fine 
(git://git.shadowcat.co.uk/dbsrgits/DBIx-Class.git).


Come to #dbix-class on irc.perl.org if you want me to add your ssh key 
added, or attach it here...


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

Re: More Weird Perl .dll Errors

[Rafael Kitover]

So I did this:

mkdir ~/.cpan/CPAN
cp /usr/lib/perl5/5.10/CPAN/Config.pm ~/.cpan/CPAN/MyConfig.pm

Then in MyConfig.pm I did this:

'make_install_arg' => q[UNINST=1],
'mbuild_install_arg' => q[uninst=1],
'makepl_arg' => q[INSTALLDIRS=vendor],
'mbuildpl_arg' => q[--installdirs vendor],

Now everything seems to work OK.

Thanks very much again Reini for your quick fix to the Win7 perlrebase 
bug and for helping me debug this!


I'm going to continue playing with Cygwin Perl and submitting patches to 
CPAN modules for it :)


Also very happy that my perl utils like App::Nopaste now work.

On 1/18/2011 1:10 PM, Rafael Kitover wrote:

On 1/17/2011 2:28 PM, Reini Urban wrote:

2011/1/15 Rafael Kitover:

Hi Reini,

I'm not having any luck:

$ perl -MClass::XSAccessor -le 1
Can't load
'/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll'

for module Class::X
SAccessor: No such file or directory at
/usr/lib/perl5/5.10/i686-cygwin/XSLoader.pm line 70.
at /usr/lib/perl5/site_perl/5.10/i686-cygwin/Class/XSAccessor.pm line 11
Compilation failed in require.
BEGIN failed--compilation aborted.

$ perlrebase
...
ReBaseImage
(/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll)

failed with last e
rror = 6


bad, not loadable.


$ ls -l
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll

-rwxr-xrwx 1 rkitover None 52 Jan 15 15:41


The o+w perm will fail for -T taint mode, but this is not the problem
here.


/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/
XSAccessor.dll

$ peflags
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll

/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll:

coff(0x2106) pe(0x8000)


good


$ imagebase
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll

6864


good.


$ ldd
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll

ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x7748)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll
(0x7553)
KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll
(0x74d7)


bad.
This is all?
If so you have a mingw perl dll here, which cannot be loaded by cygwin
perl.


So the question becomes, how did I get a mingw dll? I used the CPAN
shell to install this module just like any other module.

The modules that work give me correct output:

$ perl -MSub::Name -le 1

rkitover@eeebox ~
$ ldd /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Sub/Name/Name.dll
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x7710)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x7667)
KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x7569)
cygwin1.dll => /usr/bin/cygwin1.dll (0x6100)
ADVAPI32.DLL => /cygdrive/c/Windows/syswow64/ADVAPI32.DLL (0x74d0)
msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x7491)
sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x7537)
RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x74f9)
SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x7475)
CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x7474)
cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x70e2)
cygperl5_10.dll => /usr/bin/cygperl5_10.dll (0x5701)
cygcrypt-0.dll => /usr/bin/cygcrypt-0.dll (0x6fb7)
cygssp-0.dll => /usr/bin/cygssp-0.dll (0x7022)

After 'look'ing into Class::XSAccessor:

perl Makefile.PL
make
...

$ ldd blib/arch/auto/Class/XSAccessor/XSAccessor.dll
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x7710)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x7667)
KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x7569)
cygwin1.dll => /usr/bin/cygwin1.dll (0x6100)
ADVAPI32.DLL => /cygdrive/c/Windows/syswow64/ADVAPI32.DLL (0x74d0)
msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x7491)
sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x7537)
RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x74f9)
SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x7475)
CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x7474)
cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x70e2)
cygperl5_10.dll => /usr/bin/cygperl5_10.dll (0x5701)
cygcrypt-0.dll => /usr/bin/cygcrypt-0.dll (0x6fb7)
cygssp-0.dll => /usr/bin/cygssp-0.dll (0x7022)

That all looks good.

$ make test
PERL_DL_NONLAZY=1 /usr/bin/perl.exe "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t
/*.t
...
...
All tests successful.
Files=23, Tests=451, 14 wallclock secs ( 0.75 usr 0.45 sys + 6.36 cusr
5.55 csys = 

Re: More Weird Perl .dll Errors

[Rafael Kitover]

On 1/17/2011 2:28 PM, Reini Urban wrote:

2011/1/15 Rafael Kitover:

Hi Reini,

I'm not having any luck:

$ perl -MClass::XSAccessor -le 1
Can't load
'/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll'
for module Class::X
SAccessor: No such file or directory at
/usr/lib/perl5/5.10/i686-cygwin/XSLoader.pm line 70.
  at /usr/lib/perl5/site_perl/5.10/i686-cygwin/Class/XSAccessor.pm line 11
Compilation failed in require.
BEGIN failed--compilation aborted.

$ perlrebase
...
ReBaseImage
(/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll)
failed with last e
rror = 6


bad, not loadable.


$ ls -l
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll
-rwxr-xrwx 1 rkitover None 52 Jan 15 15:41


The o+w perm will fail for -T taint mode, but this is not the problem here.


/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/
XSAccessor.dll

$ peflags
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll:
coff(0x2106) pe(0x8000)


good


$ imagebase
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll
6864


good.


$ ldd
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll
ntdll.dll =>  /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x7748)
kernel32.dll =>  /cygdrive/c/Windows/syswow64/kernel32.dll
(0x7553)
KERNELBASE.dll =>  /cygdrive/c/Windows/syswow64/KERNELBASE.dll
(0x74d7)


bad.
This is all?
If so you have a mingw perl dll here, which cannot be loaded by cygwin perl.


So the question becomes, how did I get a mingw dll? I used the CPAN 
shell to install this module just like any other module.


The modules that work give me correct output:

$ perl -MSub::Name -le 1

rkitover@eeebox ~
$ ldd /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Sub/Name/Name.dll
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x7710)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll 
(0x7667)
KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll 
(0x7569)

cygwin1.dll => /usr/bin/cygwin1.dll (0x6100)
ADVAPI32.DLL => /cygdrive/c/Windows/syswow64/ADVAPI32.DLL 
(0x74d0)

msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x7491)
sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll 
(0x7537)

RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x74f9)
SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll 
(0x7475)
CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll 
(0x7474)

cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x70e2)
cygperl5_10.dll => /usr/bin/cygperl5_10.dll (0x5701)
cygcrypt-0.dll => /usr/bin/cygcrypt-0.dll (0x6fb7)
cygssp-0.dll => /usr/bin/cygssp-0.dll (0x7022)

After 'look'ing into Class::XSAccessor:

perl Makefile.PL
make
...

$ ldd blib/arch/auto/Class/XSAccessor/XSAccessor.dll
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x7710)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll 
(0x7667)
KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll 
(0x7569)

cygwin1.dll => /usr/bin/cygwin1.dll (0x6100)
ADVAPI32.DLL => /cygdrive/c/Windows/syswow64/ADVAPI32.DLL 
(0x74d0)

msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x7491)
sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll 
(0x7537)

RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x74f9)
SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll 
(0x7475)
CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll 
(0x7474)

cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x70e2)
cygperl5_10.dll => /usr/bin/cygperl5_10.dll (0x5701)
cygcrypt-0.dll => /usr/bin/cygcrypt-0.dll (0x6fb7)
cygssp-0.dll => /usr/bin/cygssp-0.dll (0x7022)

That all looks good.

$ make test
PERL_DL_NONLAZY=1 /usr/bin/perl.exe "-MExtUtils::Command::MM" "-e" 
"test_harness(0, 'blib/lib', 'blib/arch')" t

/*.t
...
...
All tests successful.
Files=23, Tests=451, 14 wallclock secs ( 0.75 usr  0.45 sys +  6.36 cusr 
 5.55 csys = 13.12 CPU)

Result: PASS

So that one works.

$ make install
Files found in blib/arch: installing files in blib/lib into architecture 
dependent library tree
Installing 
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll

Appending installation info to /usr/lib/perl5/5.10/i686-cygwin/perllocal.pod

$ ldd 
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll

ntdll.dll

Re: More Weird Perl .dll Errors

[Rafael Kitover]

Hi Reini,

I'm not having any luck:

$ perl -MClass::XSAccessor -le 1
Can't load 
'/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll' 
for module Class::X
SAccessor: No such file or directory at 
/usr/lib/perl5/5.10/i686-cygwin/XSLoader.pm line 70.

 at /usr/lib/perl5/site_perl/5.10/i686-cygwin/Class/XSAccessor.pm line 11
Compilation failed in require.
BEGIN failed--compilation aborted.

$ perlrebase
...
ReBaseImage 
(/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll) 
failed with last e

rror = 6

$ ls -l 
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll
-rwxr-xrwx 1 rkitover None 52 Jan 15 15:41 
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/

XSAccessor.dll

$ peflags 
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll: 
coff(0x2106) pe(0x8000)


$ imagebase 
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll

6864

$ ldd 
/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/XSAccessor/XSAccessor.dll

ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x7748)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll 
(0x7553)
KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll 
(0x74d7)


On 1/14/2011 12:00 PM, Reini Urban wrote:

2011/1/14 Rafael Kitover:

I tried both peflagsall and rebaseall with a -T list including all .dlls
under /usr/lib/perl5 as well as /usr/bin/cygperl5_10.dll

But the error for MOP.dll persists.


The Class::MOP and Sub::Name dll's are different beasts.
If they do not load, (even windows refuses to load them apparently)
you'll have to recompile them, followed by a perlrebase.


I'm not sure that when I tried the rebaseall it ran through to completion,
because it gave me this error:

FixImage (/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll)
failed with last error = 13


You have to exclude all mingw dll's from rebaseall.
This will be fixed in the next rebase package.


This is Windows 7 64bit

On 1/14/2011 4:35 AM, Matthias Andree wrote:

Am 14.01.2011 10:21, schrieb Rafael Kitover:


Something weird happened to my Class::MOP .dll :

$ perl -MClass::MOP -le 1
Can't load
'/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/MOP/MOP.dll' for
module Class::MOP: No such fi
le or directory at /usr/lib/perl5/5.10/i686-cygwin/XSLoader.pm line 70.
   at /usr/lib/perl5/site_perl/5.10/i686-cygwin/Class/MOP.pm line 38
Compilation failed in require.
BEGIN failed--compilation aborted.

If I try to run perlrebase, I get this:

...
/usr/lib/perl5/5.10/i686-cygwin/auto/Time/Piece/Piece.dll: new base =
5790, new size = 1
/usr/lib/perl5/5.10/i686-cygwin/auto/Unicode/Normalize/Normalize.dll:
new base = 5791, new size = 5
/usr/lib/perl5/5.10/i686-cygwin/auto/Win32/Win32.dll: new base =
5796, new size = 2
/usr/lib/perl5/5.10/i686-cygwin/auto/Win32API/File/File.dll: new base =
5798, new size = 3
ReBaseImage
(/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/MOP/MOP.dll)
failed with last error = 6


Either no write+exec permission or broken dependency.


I tried doing a "notest force install Class::MOP" in CPAN shell, same
error after the installation finishes.


If it's not the perm (unlikely), check the imagebase of your new dll:

$ cat ~/bin/imagebase
#!/bin/sh
objdump -p $1 |grep ImageBase |cut -c12-

$ imagebase /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/MOP/MOP.dll
66c0

And check the bases of the dependant dll's also: Anything below
0x4000_ is broken.

$ ldd /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/MOP/MOP.dll
 ntdll.dll =>  /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x778b)
 kernel32.dll =>  /cygdrive/c/Windows/system32/kernel32.dll (0x777d)
 KERNELBASE.dll =>  /cygdrive/c/Windows/system32/KERNELBASE.dll
(0x75cb)
 cygwin1.dll =>  /usr/bin/cygwin1.dll (0x6100)
 ADVAPI32.DLL =>  /cygdrive/c/Windows/system32/ADVAPI32.DLL (0x7773)
 msvcrt.dll =>  /cygdrive/c/Windows/system32/msvcrt.dll (0x7660)
 sechost.dll =>  /cygdrive/c/Windows/SYSTEM32/sechost.dll (0x767e)
 RPCRT4.dll =>  /cygdrive/c/Windows/system32/RPCRT4.dll (0x766b)
 cyggcc_s-1.dll =>  /usr/bin/cyggcc_s-1.dll (0x67f0)
 cygperl5_10.dll =>  /usr/bin/cygperl5_10.dll (0x5601)
 cygcrypt-0.dll =>  /usr/bin/cygcrypt-0.dll (0x694d)
 cygssp-0.dll =>  /usr/bin/cygssp-0.dll (0x6728)
 SspiCli.dll =>  /cygdrive/c/Windows/system32/SspiCli.dll (0x7591)


I tried rebooting and running perlrebase again, same error.


Try rebaseall, or if you're under Vista or 7, peflagsall.


--
Problem reports:   

Re: More Weird Perl .dll Errors

[Rafael Kitover]

I tried both peflagsall and rebaseall with a -T list including all .dlls 
under /usr/lib/perl5 as well as /usr/bin/cygperl5_10.dll


But the error for MOP.dll persists.

I'm not sure that when I tried the rebaseall it ran through to 
completion, because it gave me this error:


FixImage 
(/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_sjlj-1.dll) failed 
with last error = 13


This is Windows 7 64bit

On 1/14/2011 4:35 AM, Matthias Andree wrote:

Am 14.01.2011 10:21, schrieb Rafael Kitover:

Something weird happened to my Class::MOP .dll :

$ perl -MClass::MOP -le 1
Can't load
'/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/MOP/MOP.dll' for
module Class::MOP: No such fi
le or directory at /usr/lib/perl5/5.10/i686-cygwin/XSLoader.pm line 70.
   at /usr/lib/perl5/site_perl/5.10/i686-cygwin/Class/MOP.pm line 38
Compilation failed in require.
BEGIN failed--compilation aborted.

If I try to run perlrebase, I get this:

...
/usr/lib/perl5/5.10/i686-cygwin/auto/Time/Piece/Piece.dll: new base =
5790, new size = 1
/usr/lib/perl5/5.10/i686-cygwin/auto/Unicode/Normalize/Normalize.dll:
new base = 5791, new size = 5
/usr/lib/perl5/5.10/i686-cygwin/auto/Win32/Win32.dll: new base =
5796, new size = 2
/usr/lib/perl5/5.10/i686-cygwin/auto/Win32API/File/File.dll: new base =
5798, new size = 3
ReBaseImage
(/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/MOP/MOP.dll)
failed with last error = 6

I tried doing a "notest force install Class::MOP" in CPAN shell, same
error after the installation finishes.

I tried rebooting and running perlrebase again, same error.


Try rebaseall, or if you're under Vista or 7, peflagsall.



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

More Weird Perl .dll Errors

[Rafael Kitover]

Something weird happened to my Class::MOP .dll :

$ perl -MClass::MOP -le 1
Can't load 
'/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/MOP/MOP.dll' for 
module Class::MOP: No such fi

le or directory at /usr/lib/perl5/5.10/i686-cygwin/XSLoader.pm line 70.
 at /usr/lib/perl5/site_perl/5.10/i686-cygwin/Class/MOP.pm line 38
Compilation failed in require.
BEGIN failed--compilation aborted.

If I try to run perlrebase, I get this:

...
/usr/lib/perl5/5.10/i686-cygwin/auto/Time/Piece/Piece.dll: new base = 
5790, new size = 1
/usr/lib/perl5/5.10/i686-cygwin/auto/Unicode/Normalize/Normalize.dll: 
new base = 5791, new size = 5
/usr/lib/perl5/5.10/i686-cygwin/auto/Win32/Win32.dll: new base = 
5796, new size = 2
/usr/lib/perl5/5.10/i686-cygwin/auto/Win32API/File/File.dll: new base = 
5798, new size = 3
ReBaseImage 
(/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Class/MOP/MOP.dll) 
failed with last error = 6


I tried doing a "notest force install Class::MOP" in CPAN shell, same 
error after the installation finishes.


I tried rebooting and running perlrebase again, same error.

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

Re: CPAN::Reporter with metabase on cygwin

[Rafael Kitover]

Hi Reini,

Yup my ~/.cpanreporter/config.ini is a DOS file.

The weird thing though is that most of the time the reports go through 
fine, and only sometimes I see this error.


Next time I see it I'll try to figure out what needs to be fixed.

By the way, I got Win32::Clipboard fixed for Cygwin :)

On 1/12/2011 4:44 PM, Reini Urban wrote:

2011/1/11 Rafael Kitover:

I've configured CPAN::Reporter and Test::Reporter::Transport::Metabase as
per http://wiki.cpantesters.org/wiki/QuickStart

But sometimes I see this really weird error message:

(./Build test exited with 0)
CPAN::Reporter: Test result is 'pass', All tests successful.
CPAN::Reporter: preparing a CPAN Testers report for Params-Validate-0.95
Catching error: "Operation \"\"\"\": no method found, argument in overloaded
package version at /usr/lib/perl5/
vendor_perl/5.10/Test/Reporter.pm line 289.\cJ" at
/usr/lib/perl5/5.10/CPAN.pm line 391
CPAN::shell() called at /usr/bin/cpan line 198

Is this a known issue?


Very strange. Never seen this one.
FYI: there's also a Bundle::CPANReporter2 on cpan for all needed new modules.


I could probably do some debugging...


Maybe your MyConfig.pm or ~/.cpanreporter/config.ini file contains
crlf; shared with mingw maybe.


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

CPAN::Reporter with metabase on cygwin

[Rafael Kitover]

Hello,

I've configured CPAN::Reporter and Test::Reporter::Transport::Metabase 
as per http://wiki.cpantesters.org/wiki/QuickStart


But sometimes I see this really weird error message:

(./Build test exited with 0)
CPAN::Reporter: Test result is 'pass', All tests successful.
CPAN::Reporter: preparing a CPAN Testers report for Params-Validate-0.95
Catching error: "Operation \"\"\"\": no method found, argument in 
overloaded package version at /usr/lib/perl5/
vendor_perl/5.10/Test/Reporter.pm line 289.\cJ" at 
/usr/lib/perl5/5.10/CPAN.pm line 391

CPAN::shell() called at /usr/bin/cpan line 198

Is this a known issue?

I could probably do some debugging...

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

perl module .dll rebasing issues

[Rafael Kitover]

Hello, it seems the 'perlrebase' script does not fix my DLL mapping 
errors that I see when trying to install modules from the CPAN shell.


This is what I see:

  CPAN.pm: Going to build A/AR/ARCANEZ/DBIx-Class-0.08126.tar.gz

  3 [main] perl 3164 C:\cygwin\bin\perl.exe: *** fatal error - 
unable to remap \\?\C:\cygwin\lib\perl5\5.10
\i686-cygwin\auto\Cwd\Cwd.dll to same address as parent: 0x9C != 
0x578

Stack trace:
Frame Function  Args
0088B0F8  6102749B  (0088B0F8, , , )
0088B3E8  6102749B  (61177B80, 8000, , 61179977)
0088C418  61004AFB  (611A136C, 6123EC6C, 009C, 0578)
End of stack trace

After running perlrebase, I get the same exact result.

I also tried closing all cygwin processes, going into cmd.exe and then:

cd \cygwin\bin
ash
./find /usr/lib/perl5 -name '*.dll' > perl_dlls.txt
./rebaseall -T ./perl-dlls.txt

but this doesn't help either.

I am running the latest cygwin (installed today) on Windows 7 64 bit on 
an eeebox eb1012 (nvidia ION chipset.)


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

[PATCH] building epic5 (cvs version) in cygwin

[Rafael Kitover]

Minor changes for building epic5 in Cygwin.

Change to perl.c based on 
http://www.mail-archive.com/modperl@perl.apache.org/msg09457.html


I would be happy to move the checks for static XS incompatibility and 
AF_INET6 support into proper autoconf tests, if you guys would prefer.


Please CC: me on responses, if possible, thank you!

Index: configure.in
===
RCS file: /home/cvs/repository/epic5/configure.in,v
retrieving revision 1.53
diff -u -3 -p -r1.53 configure.in
--- configure.in8 Sep 2006 22:52:49 -   1.53
+++ configure.in29 Sep 2006 20:29:29 -
@@ -230,7 +230,7 @@ dnl
 dnl Checking for headers, functions, and a type declarations
 dnl

-AC_CHECK_HEADERS(fcntl.h inttypes.h math.h ndbm.h netdb.h regex.h 
stddef.h stdint.h sys/fcntl.h sys/file.h sys/filio.h sys/select.h 
sys/sysctl.h sys/syslimits.h sys/time.h sys/un.h termcap.h,)
+AC_CHECK_HEADERS(fcntl.h inttypes.h math.h ndbm.h netdb.h regex.h 
stddef.h stdint.h sys/fcntl.h sys/file.h sys/filio.h sys/select.h 
sys/sysctl.h sys/syslimits.h sys/time.h sys/un.h ncurses/termcap.h 
termcap.h,)


 AC_CHECK_FUNC(arc4random, AC_DEFINE(HAVE_ARC4RANDOM),)
 AC_CHECK_FUNC(clock_gettime, AC_DEFINE(HAVE_CLOCK_GETTIME),)
Index: include/defs.h.in
===
RCS file: /home/cvs/repository/epic5/include/defs.h.in,v
retrieving revision 1.40
diff -u -3 -p -r1.40 defs.h.in
--- include/defs.h.in   8 Sep 2006 22:52:50 -   1.40
+++ include/defs.h.in   29 Sep 2006 20:29:29 -
@@ -396,5 +396,8 @@
 /* Define if you have the  header file.  */
 #undef HAVE_SYS_UN_H

+/* Define if you have the  header file.  */
+#undef HAVE_NCURSES_TERMCAP_H
+
 /* Define if you have the  header file.  */
 #undef HAVE_TERMCAP_H
Index: include/irc_std.h
===
RCS file: /home/cvs/repository/epic5/include/irc_std.h,v
retrieving revision 1.24
diff -u -3 -p -r1.24 irc_std.h
--- include/irc_std.h   4 Oct 2005 03:47:45 -   1.24
+++ include/irc_std.h   29 Sep 2006 20:29:29 -
@@ -68,8 +68,12 @@
 /*
  * Some systems define tputs, etc in this header
  */
-#ifdef HAVE_TERMCAP_H
-#include 
+#ifdef HAVE_NCURSES_TERMCAP_H
+# include 
+#else
+# ifdef HAVE_TERMCAP_H
+#  include 
+# endif
 #endif


Index: source/perl.c
===
RCS file: /home/cvs/repository/epic5/source/perl.c,v
retrieving revision 1.17
diff -u -3 -p -r1.17 perl.c
--- source/perl.c   9 Jun 2006 03:19:14 -   1.17
+++ source/perl.c   29 Sep 2006 20:29:29 -
@@ -56,7 +56,13 @@ STRLEN   trash;
 #define SvPV_nolen(x) SvPV((x),trash)
 #endif

-static XS (XS_cmd) {
+#ifdef __CYGWIN__
+# define EPIC_PERL_STATIC
+#else
+# define EPIC_PERL_STATIC static
+#endif
+
+EPIC_PERL_STATIC XS (XS_cmd) {
int foo;
dXSARGS;
for (foo=0; fooproto_type, "tcp4") == 0 ||
 my_stricmp(si->proto_type, "4") == 0)
s->protocol = AF_INET;
+#ifdef AF_INET6
else if (my_stricmp(si->proto_type, "tcp6") == 0 ||
 my_stricmp(si->proto_type, "6") == 0)
s->protocol = AF_INET6;
+#endif
else if (my_stricmp(si->proto_type, "tcp") == 0 ||
 my_stricmp(si->proto_type, "any") == 0)
s->protocol = AF_UNSPEC;

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

[PATCH] building epic4 (CVS version 1.39) in Cygwin

[Rafael Kitover]

This is a minor fix for building epic4 from CVS on Cygwin cleanly.

Please CC: me on responses, if possible. Thank you!

Index: configure
===
RCS file: /home/cvs/repository/epic4/configure,v
retrieving revision 1.39
diff -u -3 -p -r1.39 configure
--- configure   31 Jan 2004 16:52:06 -  1.39
+++ configure   29 Sep 2006 18:14:33 -
@@ -1723,7 +1723,7 @@ fi



-for ac_hdr in fcntl.h netdb.h regex.h sys/fcntl.h sys/file.h 
sys/select.h sys/syslimits.h sys/un.h sys/time.h termcap.h sys/filio.h 
sys/sysctl.h inttypes.h stdint.h
+for ac_hdr in fcntl.h netdb.h regex.h sys/fcntl.h sys/file.h 
sys/select.h sys/syslimits.h sys/un.h sys/time.h ncurses/termcap.h 
termcap.h sys/filio.h sys/sysctl.h inttypes.h stdint.h

 do
 ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'`
 echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6
Index: configure.in
===
RCS file: /home/cvs/repository/epic4/configure.in,v
retrieving revision 1.39
diff -u -3 -p -r1.39 configure.in
--- configure.in31 Jan 2004 16:28:32 -  1.39
+++ configure.in29 Sep 2006 18:14:34 -
@@ -180,7 +180,7 @@ dnl
 dnl Checking for headers, functions, and a type declarations
 dnl

-AC_CHECK_HEADERS(fcntl.h netdb.h regex.h sys/fcntl.h sys/file.h 
sys/select.h sys/syslimits.h sys/un.h sys/time.h termcap.h sys/filio.h 
sys/sysctl.h inttypes.h stdint.h)
+AC_CHECK_HEADERS(fcntl.h netdb.h regex.h sys/fcntl.h sys/file.h 
sys/select.h sys/syslimits.h sys/un.h sys/time.h ncurses/termcap.h 
termcap.h sys/filio.h sys/sysctl.h inttypes.h stdint.h)


 if test $termcap -eq 0 ; then
AC_CHECK_FUNC(setupterm, AC_DEFINE(HAVE_TERMINFO),)
Index: include/defs.h.in
===
RCS file: /home/cvs/repository/epic4/include/defs.h.in,v
retrieving revision 1.29
diff -u -3 -p -r1.29 defs.h.in
--- include/defs.h.in   22 Nov 2003 23:33:01 -  1.29
+++ include/defs.h.in   29 Sep 2006 18:14:34 -
@@ -333,5 +333,8 @@
 /* Define if you have the  header file.  */
 #undef HAVE_SYS_UN_H

+/* Define if you have the  header file.  */
+#undef HAVE_NCURSES_TERMCAP_H
+
 /* Define if you have the  header file.  */
 #undef HAVE_TERMCAP_H
Index: include/irc_std.h
===
RCS file: /home/cvs/repository/epic4/include/irc_std.h,v
retrieving revision 1.18
diff -u -3 -p -r1.18 irc_std.h
--- include/irc_std.h   6 Oct 2004 00:22:05 -   1.18
+++ include/irc_std.h   29 Sep 2006 18:14:34 -
@@ -63,8 +63,12 @@
 /*
  * Some systems define tputs, etc in this header
  */
-#ifdef HAVE_TERMCAP_H
-#include 
+#ifdef HAVE_NCURSES_TERMCAP_H
+# include 
+#else
+# ifdef HAVE_TERMCAP_H
+#  include 
+# endif
 #endif


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

[PATCH] rebase: Pick up more dlls when using rebaseall

[Rafael Kitover]

This modification to the rebaseall script will allow it to work on .dll extensions 
created by Perl modules downloaded from CPAN, ie
using perl -MCPAN -e shell, site python dlls, and any dlls that can be found in 
/usr/local, /install, /home and /opt. find does not
recurse into symlinked directories, so there should be no danger of rebasing dlls not 
intended for cygwin.

I thought about adding some code to ignore zsh dlls from the current version of zsh, 
but from my vague understanding of the progress
of that issue, the problem seems to be in rebase, related to some symbols not getting 
changed:
http://www.cygwin.com/ml/cygwin/2004-02/msg00573.html
so rebaseall should work with any version of zsh once rebase is fixed.

Also a minor nit about the rebase package, the readme is under /usr/doc/Cygwin rather 
than /usr/share/doc/Cygwin.

-- 
Rafael


rebaseall-moredlls.patch
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/

Re: new cygwin window from script?

[Rafael Kitover]

cygstart /cygwin.bat

-- 
Rafael

- Original Message - 
From: "linux dr." haughtmail.com>
To: cygwin.com>
Sent: Saturday, February 21, 2004 5:29 PM
Subject: new cygwin window from script?


> Sorry if this is a repost... didn't seem to post through nntp.
> 
> I'm trying to generate a new cygwin window in XP/2000, from within a tcsh 
> script in a current cygwin window.  How do I create a NEW window (as if I 
> clicked the cygwin icon on the desktop) as opposed to a new shell within the 
> same window?  Running tcsh from the DOS/Windows command line creates a new 
> window, as desired.  However, from within cygwin, just creates a new tcsh, not 
> a new window.  Can anyone help?  Thanks!

--
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: WML (perl-based program) segfaults

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Wolfgang Schnerring
>Sent: Tuesday, February 10, 2004 7:27 AM
>To: [EMAIL PROTECTED]
>Subject: WML (perl-based program) segfaults
>
[SNIP]
>Starting program: /cygdrive/d/wosc/install/Cygwin/wml-
>2.0.9/wml_backend/p3_eperl/eperl.exe README
>
>Program received signal SIGSEGV, Segmentation fault.
>0x1000ad60 in cygperl5_8_2!Perl_malloc () from /usr/bin/cygperl5_8_2.dll
>(gdb) bt
>#0  0x1000ad60 in cygperl5_8_2!Perl_malloc () from /usr/bin/cygperl5_8_2.dll
>#1  0x1007254c in cygperl5_8_2!Perl_sv_add_arena () from
>/usr/bin/cygperl5_8_2.dll
>#2  0x1007dc8b in cygperl5_8_2!Perl_newSVpvn () from /usr/bin/cygperl5_8_2.dll
>#3  0x10058488 in cygperl5_8_2!Perl_savesharedpv () from
>/usr/bin/cygperl5_8_2.dll
>#4  0x100586b7 in cygperl5_8_2!Perl_vmess () from /usr/bin/cygperl5_8_2.dll
>#5  0x10059171 in cygperl5_8_2!Perl_vcroak () from /usr/bin/cygperl5_8_2.dll
>#6  0x1005963f in cygperl5_8_2!Perl_croak_nocontext () from
>/usr/bin/cygperl5_8_2.dll
>[this sequence keeps repeating over and over]
>###
>
>Does anybody have an idea what I might be looking at here, and what I
>could do about it?

If this thing is mixing malloc/frees between dlls, like in a problem we saw a
few days ago, this wouldn't be surprising... If it works with 5.8.2 on linux,
then that's probably the case.

-- 
Rafael

--
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: Tk usage with / from perl in Cygwin env

[Rafael Kitover]

>-Original Message-
>From: linda w
>Sent: Thursday, February 19, 2004 5:24 PM
>Subject: Tk usage with / from perl in Cygwin env
>
>Has anyone tried using Tk from perl?
[SNIP]

According to Gerrit,
http://anfaenger.de/cygwin-1.5/perl/ 

-- 
Rafael

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

[Rafael Kitover]

>-Original Message-
>From: Krzysztof Duleba
>Sent: Thursday, February 19, 2004 4:11 PM
>Subject: Re: Assembler
>
>Krzysztof Duleba wrote:
>>
>> > Googling brought me to http://line.sourceforge.net,
>> > which may be more along the lines of what you seek.
>>
>> I tried it out, with no success. Binary version fails to run it's own
>hello
>> and rawhello programs and source produces so many serious errors during
>the
>> compilation that I have no hope to fix them all. Which doesn't mean that
>I'm
>> not trying to :-)
>
>I gave up. I see no chance to compile Line at all. And even if I succeed,
>Line will probably bail out.
>However, my own code already can change int 0x80-like system calls to
>appropriate function calls, if only the function has fixed number of
>arguments. I still don't have handling functions that can have different
>number of arguments, but it doesn't seem to be difficult too.
>I wanted to try out my app with some deassembler, but I haven't found
>anything interesting. Which one do you use (in Linux)?
>
>Regards
>Krzysztof Duleba

Maybe the linux emulation code in freebsd might prove useful?

-- 
Rafael

--
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: cygrunsrv feature request

[Rafael Kitover]

>-Original Message-
>From: Richard Duran
>Sent: Friday, February 20, 2004 1:28 AM
>Subject: cygrunsrv feature request
>
>Sorry if this is the wrong list, but is there any chance an option/flag
>could be added to "cygrunsrv -I" that would allow the program to show up
>(in ps) under a name other than "cygrunsrv"?
>
>Also, does anyone know how to write a proper service in perl? (How are
>other services "paused"?).
>
>-richard

To write services in Perl, you could try the Win32::Service module that's in
the perl-libwin32 package.

-- 
Rafael

--
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: piping problems with cron+4nt

[Rafael Kitover]

Perhaps try using the cygstart utility, in conjunction with --hide?

>-Original Message-
>From: Mironov, Leonid {PBG}
>Sent: Wednesday, February 18, 2004 12:59 AM
>Subject: piping problems with cron+4nt
>
>I've got a bunch of legacy 4NT batches I want to run from cygwin cron. When
>run from 4NT started from bash these batches work fine but when started from
>cron all lines with redirection and piping fail, e.g. when I run
>
>   dir>q
>
>file 'q' is not created,
>
>   dir|sort
>
>starts sort and it sits and waits for keyboard input. Also output from
>external programs is lost, e.g. if batch looks like
>
>   echo zzz
>   zip zzz *
>   echo qqq
>
>and is run as
>
>0  2   *   *   *   4NT.EXE /c
>ibackup.btm>>h:\\backup\\bk.log
>
>file h:\backup\bk.log will look like
>
>   zzz
>   qqq
>
>zip output is missing, although zip archive is created.
>
>Any ideas?
>
>Win XP SP1, just refreshed cygwin and 4NT to latest bulds whith no effect at
>all.
>
>:), Leo


--
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 extending perl-5.8.2-1 via CPAN: Storable.dll

[Rafael Kitover]

This is an issue related to rebasing DLLs.

There's a "rebaseall" utility in Cygwin to fix this, unfortunately it does not
pick up non-package DLLs, including Perl extensions installed from CPAN shell.
I've made some changes to that script so that it does...which reminds me I need
to send out a patch, or something. Anyway, my "rebaseall" script is attached.
To run it, close any all Cygwin processes, open a bash shell, and run it.

HTH

-- 
Rafael

>-Original Message-
>From: Tino Lange
>Sent: Tuesday, February 17, 2004 10:09 AM
>To: The Cygwin Mailing List
>Subject: problem extending perl-5.8.2-1 via CPAN: Storable.dll
>
>Gerrit P. Haase wrote:
>> perl-5.8.2-1 release has been uploaded to sourceware
>>-- it should be on the mirrors soon.
>
>Hi Gerrit, hi List!
>
>I have a problem updating modules within the CPAN Shell. Perl itself
>crashes due to problems with Storable.dll?
>
>> cpan> install Mail::SpamAssassin
>> Running install for module Mail::SpamAssassin
>> Running make for F/FE/FELICITY/Mail-SpamAssassin-2.63.tar.gz
>> CPAN: Digest::MD5 loaded ok
>> CPAN: Compress::Zlib loaded ok
>> Checksum for /home/Tino/.cpan/sources/authors/id/F/FE/FELICITY/Mail-
>SpamAssassin-2.63.tar.gz ok
>> Scanning cache /home/Tino/.cpan/build for sizes
>> C:\cygwin\bin\perl.exe (3080): *** unable to remap
>C:\cygwin\lib\perl5\5.8.2\cygwin-thread-multi-64int\auto\Storable\Storable.dll
>to same address as parent(0xCE) != 0x120
>>   4 [main] perl 3168 sync_with_child: child 3080(0x6B0) died before
>initialization with status code 0x1
>>6993 [main] perl 3168 sync_with_child: *** child state child loading dlls
>
>Can you give me a hint?
>I have searched the mailing list and the web for appropiate keywords,
>but I couldn't find a solution there.
>
>Attaches is a cygcheck.out. Please let me know if you need more information.
>
>Please always CC to me, since I'm not on the list.
>
>Thanks for your help!
>
>Tino


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

RE: search and replace tool

[Rafael Kitover]

Not really cygwin specific, you can do something like:

perl -pi -e 's/old text/new text/' `find /where -name '*.txt'`

note those are backticks surrounding the find.

Use -pi.bak to make backup files in case you screw up. You will of course need
to know how to use regular expressions (see man perlretut). If you need to do
multiline replaces, you should probably write a script, or use some other
solution.

-- 
Rafael

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>dAniel hAhler
>Sent: Wednesday, February 18, 2004 12:00 PM
>To: cygwin-list
>Subject: search and replace tool
>
>Hello cygwin-list,
>
>I'm looking for a search and replace tool to replace a text portion in
>a bunch (3500+) of files.
>
>That should be an easy one.. :)

--
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: DBD::Pg - $dbh->quote() causes core dump

[Rafael Kitover]

Hi Ian,

There was some memory allocation related funkiness in DBD::Pg that the attached
patch fixes. You can apply it to both 1.31 and 1.32_1.

Bug posted on CPAN:
http://rt.cpan.org/NoAuth/Bug.html?id=5357 

-- 
Rafael

>-Original Message-
>From: Ian Sealy
>Sent: Monday, February 16, 2004 11:09 AM
>To: Cygwincygwin.com
>Subject: Re: DBD::Pg - $dbh->quote() causes core dump
>
>Dear all,
>
>> Is anyone using the DBD::Pg Perl module under Cygwin? I'm trying to use
>> it on Windows XP with Perl 5.8.2-1 and DBI 1.40. The Cygwin DLL version
>> is 1.5.7.
>>
>> The module seems to build OK, but lots of the tests fail. The most
>> serious (from my point of view, because I tried to use the module
>> anyway) is that $dbh->quote() causes a core dump:
[SNIP]
>>
>> Any idea what's wrong?
>
>I've just realised that I've missed out one bit of, perhaps crucial,
>information. I'm building DBD::Pg against PostgreSQL 7.4.1-3.
>
>Any ideas? Thanks in advance.
>
>Cheers,
>Ian



DBD-Pg-1.31-cygwin.patch
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/

RE: localtime_r not returning local time

[Rafael Kitover]

Would it be a lot of overhead to have something like tzset be called in the
bootstrap code for launching Cygwin programs? Or maybe just have a DLL global
default, based on windows time zone, and just allow processes to reset it for
themselves (and any children.)

-- 
Rafael

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Yitzchak Scott-Thoennes
>Sent: Sunday, February 08, 2004 10:40 AM
>To: [EMAIL PROTECTED]
>Subject: localtime_r not returning local time
>
>localtime_r is (if no direct or indirect call to tzset has been made)
>returning UTC time.
>
>This is the source of the cygwin perl bug where perl's localtime() is
>returning UTC time.  See:
>http://groups.google.com/groups?selm=rt-3.0.8-26136-
>[EMAIL PROTECTED]
>
>Perl does not ever directly call tzset (except when perl code calls
>POSIX::tzset).  Should it do so (at least at startup), or should
>localtime_r be returning a TZ-based time even when tzset hasn't been
>called?
>
>My reading of susv3:
>   "Local timezone information is used as though localtime() calls tzset().
>
>   The relationship between a time in seconds since the Epoch used as
>   an argument to localtime() and the tm structure (defined in the
>header) is that the result shall be...corrected for timezone
>   and any seasonal time adjustments...
>
>   The same relationship shall apply for localtime_r().
>   ...
>   Unlike localtime(), the reentrant version is not required to set
>   tzname.
>
>is that while localtime_r need not (should not?) set the daylight,
>timezone, and tzname globals, it should still use local time as if
>tzset had been called.  Admittedly, the standard is vague on this
>point.
>
>--
>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: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]

[Rafael Kitover]

Please try installing perl-libwin32 package, and set:

export PERL5OPT="-MWin32"

in your environment.

HTH

-- 
Rafael

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>linda w
>Sent: Thursday, February 12, 2004 10:08 AM
>To: [EMAIL PROTECTED]
>Subject: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values,
>not names..?]
>
>I'm on an NT compatible (Windows XP) release trying to run the reg utils
>but I
>get an error message that IsWinNT is not defined, so they the reg utils
>fail to
>install.  Presumably IsWinNT is to differentiate between Protected and
>DOS-based versions of Windows but presumably wouldn't be defined on OS's
>where
>Windows compatibility is not possible or desired.
[SNIP]

--
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.7: make hangs on XP (with HT)

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Rolf Campbell
>Sent: Thursday, February 05, 2004 8:40 AM
>To: [EMAIL PROTECTED]
>Subject: 1.5.7: make hangs on XP (with HT)
>
>I've been trying to narrow the problem I've been having with make (-j)
>and processes locking up.  And I've made some progress.
>
>First, this happens with 1.5.6 -> 1.5.7 (and every snapshot in-between).
>
>I've tried this test on 3 configurations:
>WinXP (HyperThreaded): fails quickly (between 20 seconds and 3 minutes)
>Win2000 (Not HT): fails slowly (between 6 minutes and 20 minutes)
>WinXP (HT turned off): does not fail (ran it for about an hour and it
>was fine).
[SNIP]

This test would fail on me on WinXP on an HT machine very quickly with 1.5.7
and earlier snapshot, but with the most recent CVS it works fine :)

-- 
Rafael

--
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: compile needs netfilter_ipv4.h

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Henning
>Sent: Thursday, February 05, 2004 2:18 PM
>To: [EMAIL PROTECTED]
>Subject: compile needs netfilter_ipv4.h
>
>Hi
>
>I just installed cygwin and am trying to compile 'reaim' which requires
>'netfilter_ipv4.h' - a linux kernel header.
>
>Is there a package that contains the cygwin equivalent? or is it safe to
>simply copy the files it needs from the linux kernel sources?

No and no. You'll have to see if there are equivalents in the Win32 or native
APIs...

-- 
Rafael

--
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: Re: terminal size problems

[Rafael Kitover]

>$TERM is fine, but I found that forcing an eval `resize` on the remote
>side gets things to work.  I'm still confused about why this is neccessary
>for cygwin (I tried the latest snapshot as Brian suggested to no avail).
>Also the difference between telnet and rlogin behavior seems unexpected
>to me.  In any case, I'm happy as a clam now ... thanks for the help :)

There are some differences in how telnet and rlogin propagate environment
variables to the remote host, AFAIR.

-- 
Rafael

--
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: update via setup.exe removed NTFS junction?

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Robert Collins
>Sent: Tuesday, February 03, 2004 4:36 PM
>To: Robert R Schneck
>Cc: [EMAIL PROTECTED]
>Subject: Re: update via setup.exe removed NTFS junction?
>
>On Wed, 2004-02-04 at 11:25, Robert R Schneck wrote:
>
>> In fact you are correct.  setup.log.full contains:
>> 2004/02/03 22:59:17 Uninstalling man
>> ...
>> rmdir C:\cygwin/var/cache/man
>> rmdir C:\cygwin/var/cache
>> rmdir C:\cygwin/var
>
>> Indeed, calling rmdir on a junction point will remove it, I suppose
>> since there's an empty placeholder which gets removed.
>>
>>
>> > Short answer is: 'don't do that'.
>>
>> Reasonably good advice.  But it's possible that this should be
>> considered a bug: uninstalling man shouldn't even try to get rid of var,
>> perhaps?
>
>Nope. When uninstalling, directories are cleaned up. I'm not going to
>special case 'uninstall completely' when we don't need to.
>
>Sounds to me like the windows API has yet another idiocy.

Maybe either Cygwin or fileutils could have some support for NTFS junctions,
since they sound like a useful feature, or symlinks could be implemented as
junctions. While we're throwing around unrealistic ideas anyway :)

>
>Rob
>
>--
>GPG key available at: .

--
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: Text entry to command line program

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Ross Boulet
>Sent: Tuesday, February 03, 2004 4:28 PM
>To: [EMAIL PROTECTED]
>Subject: RE: Text entry to command line program
>
>>
>> Try something like:
>>
>> CYGWIN=notty sqlplus
>>
>
>Is that saying notty for sqlplus and tty for everything else?
>
>Is there any decent documentation for what the CYGWIN variable does?

http://cygwin.com/cygwin-ug-net/using-cygwinenv.html

-- 
Rafael

--
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: Segmentation fault (core dumped)

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Eva Bordeaux
>Sent: Tuesday, February 03, 2004 4:40 PM
>To: [EMAIL PROTECTED]
>Subject: Segmentation fault (core dumped)
>
>Hello, I try to run my program on Windows machine using Cygwin.
>
>$ make clean all
>gcc -c -o codon.o codon.ccreate_codon.c
>gcc -c -o linkcurve.o linkcurve.c
>subpart.c: In function `part_extractor_closed':
>subpart.c:179: warning: passing arg 2 of `strcat' makes pointer from integer
>wit
>hout a cast
>gcc -c -o suppress.o suppress.c
>gcc -c -o feature_match.o feature_match.c
>gcc -c -o ListDir.o ListDir.c
>gcc  main.o create_codon.o codon.o io.o k_smooth.o linkcurve.o lowe.o
>matrix.o p
>rematch.o subpart.o suppress.o feature_match.o ListDir.o   -lm  -o getmatch
>
>$ ./getmatch Query.raw 250 250 r rs
>check point 10 is fine
>Segmentation fault (core dumped)

Try this:

make clean all CC="gcc -g"
gdb --args ./getmatch Query.raw 250 250 r rs
(gdb) run

.. program runs and crashes

(gdb) bt

Then give the results to whoever wrote the program, or try to fix it yourself.

HTH

>
>When I run this on Unix machine at the lab in University , it works without
>any problem.
>What can be wrong? Maybe I didn't install all needed parts of compiler? When
>I installed Cygwin, I pick Base and all Devel categories.
>Any idea how to fix this is appreciated.
>Eva

-- 
Rafael

--
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 randomly hangs after upgrading to cygwin 1.5.7

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Volker Quetschke
>Sent: Tuesday, February 03, 2004 1:12 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Program randomly hangs after upgrading to cygwin 1.5.7
>
>Hi Rafael,
>> Are you using a win32 native compiled dmake or did you compile a copy of
>dmake
>> as a Cygwin binary? Either way, did you compile dmake with debugging
>support?
>
>as mentioned earlier in this thread, it is the cygwin binary. See the
>first message in this thread for cygcheck info of dmake, and the
>cygcheck output of my system.
>
>Thanks for looking at this
>
>   Volker

Just an idea that may be worth trying:

Make something like a /usr/local/bin/tracedmake

#!/bin/sh
strace -o /tmp/dmake-trace-$$ --flush-period=10 dmake $*

And try the build with MAKE=tracedmake, then when a make hangs, you should be
able to see the trace output in the last /tmp/dmake-trace* file for where or in
what process the dmake hangs.

Also if you compile dmake with debugging (gcc -g) you might then be able to
attach with CYGWIN=notty gdb --pid=.

If it's stuck inside the Cygwin dll, which is likely, then it would help to
compile the Cygwin dll from CVS, with --enable-debugging, and then you'd be
able to see where things are hanging in gdb with "dll cygwin1".

Also, any thoughts on how a smaller test case could be constructed without
trying to compile the whole of openoffice? Any pattern you notice about the
places where dmake hangs?

-- 
Rafael

--
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: Text entry to command line program

[Rafael Kitover]

Try something like:

CYGWIN=notty sqlplus

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Ross Boulet
>Sent: Monday, February 02, 2004 2:12 PM
>To: [EMAIL PROTECTED]
>Subject: RE: Text entry to command line program
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Ross Boulet
>> Sent: Monday, February 02, 2004 8:05 AM
>> To: [EMAIL PROTECTED]
>> Subject: Text entry to command line program
>>
>>
>> I've been having a problem for a while now on my XP laptop
>> with an Oracle
>> program (sqlplus).  When I start sqlplus, it prompts for a
>> user id and then
>> a password.  When I run it from the windows shell (cmd.exe)
>> it works as
>> expected, i.e. the user id is echoed and the password is not:
>>
>> c:\$temp>sqlplus
>>
>> SQL*Plus: Release 9.2.0.1.0 - Production on Mon Feb 2 07:24:24 2004
>>
>> Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
>>
>> Enter user-name: myid
>> Enter password:
>>
>>
>> In bash or ksh, the password gets echoed as well (and shouldn't be):
>>
>>
>> lap /home/rossboulet # sqlplus
>>
>> SQL*Plus: Release 9.2.0.1.0 - Production on Mon Feb 2 07:22:35 2004
>>
>> Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
>>
>> Enter user-name: myid
>> Enter password: mypass
>>
>>
>> Its been happening to me for the last several releases of
>> cygwin but I can't
>> say exactly when it started happening.  Any suggestions?
>>
>
>OK, my bad.  I found a couple of references to this behavior in the ML.  I
>was suspicious of the "CYGWIN=ntsec tty" environment variable (set for sshd)
>and had tried unsetting it in the shell to no avail.  I found that if I
>unset it with dos before I start the shell, the behavior reverts to what I
>expected (password not echoed).
>
>What am I losing in the shell with not having CYGWIN set?


--
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 randomly hangs after upgrading to cygwin 1.5.7

[Rafael Kitover]

Are you using a win32 native compiled dmake or did you compile a copy of dmake
as a Cygwin binary? Either way, did you compile dmake with debugging support?

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Volker Quetschke
>Sent: Sunday, February 01, 2004 7:41 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Program randomly hangs after upgrading to cygwin 1.5.7
>
>Volker Quetschke wrote:
>
>> This problem occured after upgrading from cygwin 1.5.5 to 1.5.7(second
>> version). During this I update all other installed cygwin packages to
>   updated
>> the current versions. (cygcheck -s -v -r is attached)
>>
>> The problem is that dmake, the make utility for building OpenOffice.org
>> seems to hang after a while. With a while I mean after several hours,
>> but in different places. (As far as one can say after two tries)
>> For each project are new dmake processes started, so I cannot run dmake
>> in gdb, I have to attach to the one that fails.
>
>The OOo build just finished with cygwin 1.5.5, any hints how to track
>down this problem.
>
>Volker
>
>--
>PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
>key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D

--
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: verilator on cygwin - unexplained errors

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Pinhas Krengel
>Sent: Friday, January 30, 2004 10:03 PM
>To: [EMAIL PROTECTED]
>Subject: Re: verilator on cygwin - unexplained errors
>
>If it works on your cygwin it means that somethin on my cygwin is bad.
>From the results of cygcheck that I attached on a former messag can you
>please tell the difference.
>Am I missing some package of cygwin or perl.

Good point.

>From your Cygwin_check.log:

Path:   c:\pini_prog\MinGW\bin
c:\pini_prog\cygwin\usr\local\bin
c:\pini_prog\cygwin\bin
c:\pini_prog\xilinx\bin\nt

You are trying to use MinGW gcc to compile a module for Cygwin Perl. This won't
work. The Cygwin gcc must be first in your path. Since you already have Cygwin,
you can just remove MinGW and use gcc -mno-cygwin when you need to compile a
MinGW app.

-- 
Rafael

>
>
>"Rafael Kitover" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> I went into perl -MCPAN -e shell, typed "install SystemC::Parser" and it
>> installed fine for me...
[SNIP]



--
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: FlexLexer.h

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Pinhas Krengel
>Sent: Saturday, January 31, 2004 12:08 AM
>To: [EMAIL PROTECTED]
>Subject: FlexLexer.h
>
>Is this files suppose to come with any package of cygwin.

This page:

http://cygwin.com/packages/ 

Will answer your question.

-- 
Rafael

--
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: Problems with tcl "exec" command and "sh" in Cygwin.

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Gancho Tenev
>Sent: Friday, January 30, 2004 7:51 PM
>To: [EMAIL PROTECTED]
>Subject: Problems with tcl "exec" command and "sh" in Cygwin.
>
[SNIP]
>script: 1.tcl
>--
>#!/bin/sh
># \
>exec tclsh "$0" ${1+"$@"}
>
>puts "result= [ exec 2.tcl ]"
>exit
>--
>
>script: 2.tcl
>--
>#!/bin/sh -e
># \
>exec tclsh "$0" ${1+"$@"}
>
>puts "Hello, World!"
>exit
>--
>
>
>* when I run on Unix:
>$./1.tcl
>result = Hello, World!
>
>
>* when I run it in Cygwin.
>$./1
>couldn't execute "2.tcl": no such file or directory
>while executing
>"exec 2.tcl "
>invoked from within
>"puts "result= [ exec 2.tcl ]""
>(file "./1.tcl" line 5)
[SNIP]
Try changing this to "[ exec /path/to/2.tcl ]".

>* But 2 days ago we decided to reinstall Cygwin (latest)
>and now it is hanging on "exec sh" infinitely.
>It seems something has changed! We didn't do anything
>special before and now while installing cygwin.
>
>Any ideas and suggestions are greatly appreciated!
>I tried to give concise description so please let me
>know if I need to provide more info!
>
>Best regards!
>Gancho.

Upgrade to the just released Cygwin 1.5.7, and it should be fine.

-- 
Rafael

--
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: verilator on cygwin - unexplained errors

[Rafael Kitover]

I went into perl -MCPAN -e shell, typed "install SystemC::Parser" and it
installed fine for me...

-- 
Rafael

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Pinhas Krengel
>Sent: Friday, January 30, 2004 11:10 AM
>To: [EMAIL PROTECTED]
>Subject: Re: verilator on cygwin - unexplained errors
>
>I use the cygwin the perl that came with the cygwin package.
>Attached is the cugwin check -svr
>
>"Igor Pechtchanski" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> On Fri, 30 Jan 2004, Pinhas Krengel wrote:
>>
>> > While tring to build one of its packeage (from CPAN) I got stange
>> > message in response to the make.
>> >
>> > the package is //www.veripool.com/systemperl.html
>> >
>> > Message is. Can somebody tell me if I am missing something in my cygwin?
>> >
>> > make[1]: Entering directory
>`/cygdrive/c/pini_prog/verilator/SystemPerl-1.147/Parser'
>> >
>gcc -c -I. -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DUSEIMPORTLIB -O2 -D
>VERSION=\"1.147\" -DXS_VERSION=\"1.147\"
>"-I/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE" Parser.c
>> > Running Mkbootstrap for SystemC::Parser ()
>> > chmod 644 Parser.bs
>> > rm -f ../blib/arch/auto/SystemC/Parser/Parser.dll
>> > LD_RUN_PATH="" ld2 -s -L/usr/local/lib Parser.o -o
>../blib/arch/auto/SystemC/Parser/Parser.dll sclex.o scgrammer.o
>/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE/libperl.dll.a
>> > gcc -shared -o
>Parser.dll -Wl,--out-implib=libParser.dll.a -Wl,--export-all-symbols -Wl,--e
>nable-auto-import -Wl,--stack,8388608 \
>> > -s -L/usr/local/lib Parser.o sclex.o scgrammer.o
>/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE/libperl.dll.a
>> > Creating library file: libParser.dll.a
>> > sclex.o(.text+0x2f2b):sclex.c: undefined reference to `__imp___iob'
>> > sclex.o(.text+0x2f3e):sclex.c: undefined reference to `__imp___iob'
>> > sclex.o(.text+0x389b):sclex.c: undefined reference to `__assert'
>> > sclex.o(.text+0x43bb):sclex.c: undefined reference to `__imp___iob'
>> > sclex.o(.text+0x444e):sclex.c: undefined reference to `__isctype'
>> > sclex.o(.text+0x4476):sclex.c: undefined reference to `__isctype'
>> > sclex.o(.text+0x44bd):sclex.c: undefined reference to `__isctype'
>> > sclex.o(.text+0x44e9):sclex.c: undefined reference to `__isctype'
>> > sclex.o(.text+0x4538):sclex.c: undefined reference to `__imp___pctype'
>> > sclex.o(.text+0x4551):sclex.c: undefined reference to `__imp___pctype'
>> > sclex.o(.text+0x4569):sclex.c: undefined reference to `__imp___pctype'
>> > sclex.o(.text+0x4581):sclex.c: undefined reference to `__imp___pctype'
>> > scgrammer.o(.text+0x16d6):scgrammer.c: undefined reference to
>`__imp___iob'
>> > scgrammer.o(.text+0x16fa):scgrammer.c: undefined reference to
>`__imp___iob'
>> > scgrammer.o(.text+0x1724):scgrammer.c: undefined reference to
>`__imp___iob'
>> > scgrammer.o(.text+0x179b):scgrammer.c: undefined reference to
>`__imp___iob'
>> > scgrammer.o(.text+0x17de):scgrammer.c: undefined reference to
>`__imp___iob'
>> > scgrammer.o(.text+0x180f):scgrammer.c: more undefined references to
>`__imp___iob' follow
>> > collect2: ld returned 1 exit status
>> > perlld: *** system() failed to execute
>>   ^^
>> > gcc -shared -o
>Parser.dll -Wl,--out-implib=libParser.dll.a -Wl,--export-all-symbols -Wl,--e
>nable-auto-import -Wl,--stack,8388608 \
>> > -s -L/usr/local/lib Parser.o sclex.o scgrammer.o
>/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE/libperl.dll.a
>> > make[1]: *** [../blib/arch/auto/SystemC/Parser/Parser.dll] Error 1
>> > make[1]: Leaving directory
>`/cygdrive/c/pini_prog/verilator/SystemPerl-1.147/Parser'
>> > make: *** [subdirs] Error 2
>>
>> Please accompany all Cygwin problem reports with the output of "cygcheck
>> -svr", preferably run from the environment/context in which you get the
>> error.  The output should be attached, as an uncompressed text
>> *attachment*, rather than included inline, as per
>> .
>>
>> The first question that comes to mind after seeing the underlined line
>> above, though, is whether you're using Cygwin's perl or if there's another
>> perl in the PATH that overrides it.
>> 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!
>>
>> "I have since come to realize that being between your mentor and his route
>> to the bathroom is a major career booster."  -- Patrick Naughton
>>
>


--
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: C COM objects?

[Rafael Kitover]

Hi Michael, I remembered your sig from a Slashdot article :)

If COM and OLE are similar beasties, I think you mean -fvtable-thunks. GCC 2.95
required -fvtable-thunks to build OLE stuff, like the Win32::OLE module in the
perl-libwin32 package, but since GCC 3.x it works fine as it is, and that
option no longer exists.

It seems most of the OLE/COM stuff should work more or less fine in Cygwin with
a bit of tweaking.

Now, if only we could get a Cygwin version of tchar.h... I guess I could write
one :)

-- 
Rafael

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Michael D. Crawford
>Sent: Thursday, January 29, 2004 5:29 PM
>To: [EMAIL PROTECTED]
>Subject: Re: C COM objects?
>
>I tried a couple of times to get ZooLib (http://www.zoolib.org/) to build with
>Cygwin.  ZooLib is a cross-platform application framework, and on Windows uses
>COM to handle the clipboard and drag and drop.
>
>I believe that actually you CAN get COM to work with gcc, even from C++, but
>you're going to need to build gcc and its libraries a different way than the
>way
>it's normally built by the Cygwin developers.  I'm afraid I don't remember
>what
>is needed, but it has something to do with vtable thunking.  You need to set
>whatever option deals with that differently than the way it's built normally
>by
>the cygwin folks.
>
>I'm sorry I can't be more specific, but it's been a while.  Maybe if you
>search
>for my email address or the word "zoolib" in the list archives you can find
>where I asked about this before.
>
>It's actually not very hard at all to do COM programming in C.  A COM
>interface
>is little more than a structure full of pointers to functions.  I have some
>sample code from when I gave a talk on writing Mac OS X user clients at
>MacHack
>last year.  Yes, Apple's Mac OS X actually uses COM!  Who would have thought.
>I've been meaning for months to post the source on my website but I got to fix
>it up before I do.  I'll go have a look and maybe I can post some snippets as
>a
>reply to this thread.
>
>Mike
>--
>Michael D. Crawford
>GoingWare Inc. - Expert Software Development and Consulting
>http://www.goingware.com
>[EMAIL PROTECTED]
>
>   Tilting at Windmills for a Better Tomorrow.
>
> "I give you this one rule of conduct. Do what you will, but speak
>  out always. Be shunned, be hated, be ridiculed, be scared,
>  be in doubt, but don't be gagged."
>  -- John J. Chapman, "Make a Bonfire of Your Reputations"
> http://www.goingware.com/reputation/




--
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, Cygwin and ACL support

[Rafael Kitover]

It seems there's no posix acl support in Cygwin, as far as I could see.

The libraries are here if anyone wants to try porting them to Win32 acls:

ftp://oss.sgi.com/projects/xfs/latest/cmd_tars/acl-2.2.15.src.tar.gz 
ftp://oss.sgi.com/projects/xfs/latest/cmd_tars/attr-2.4.8.src.tar.gz 

-- 
Rafael

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>[EMAIL PROTECTED]
>Sent: Thursday, January 29, 2004 8:12 AM
>To: [EMAIL PROTECTED]
>Subject: Rsync, Cygwin and ACL support
>
>
>
>
>
>My life would be much easier if I could use Rsync on Cygwin, to go from
>windows to linux, and preserve POSIX acls along the way.  Rsync does not
>support this, without a patch.  This patch works fine in linux, and applies
>correctly in Cygwin, but I am unable to get Cygwin past the ./configure
>stage.
>
>I have applied the patch to the rsync source, and run ./configure
>--with-acl-support=yes.
>There is a failure during configure that is killing acl support  --->
>
>Checking whether to support ACLS... checking for acl_get_file in -lacl...
>no
>checking for ACL support... no
>
>I suppose my question for the list is, is the POSIX acl support in Cygwin
>complete enough that this should work, or am I wasting my time?  If anyone
>knows a way around this, I would be most appreciative.
>
>Alex Laslavic
>Havertys Tech Services


--
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: Insecure Dependency in Net::DNS with Cygwin (WAS: Cygwin, win98, SA, Perl IO::Socket (Insecure dependency))

[Rafael Kitover]

Chris Reinhardt fixed the problem, which turned out to be something related to
the configuration parser in Net/DNS/Resolver/Cygwin.pm, and it works now!

If you were having problems with SpamAssassin+Cygwin before, or other strange
Net::DNS problems, please try this snapshot:

http://www.net-dns.org/snaps/2004/01/Net-DNS-2004-01-29.tar.gz 

-- 
Rafael

--
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: What is wrong with my bison

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Pinhas Krengel
>Sent: Wednesday, January 28, 2004 8:21 AM
>To: [EMAIL PROTECTED]
>Subject: What is wrong with my bison
>
>While tring to build some CPAN module it yells:
>Do I need to update mycygwin installation with something?
>
>bison  --debug --verbose -d -k scgrammer.y -pscgrammer -o scgrammer.c
>bison: /usr/share/bison.simple: No such file or directory
>make[1]: *** [scgrammer.h] Error 2
>

Which CPAN module are you trying to install?

-- 
Rafael

--
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: Installation on Windows 2K server

[Rafael Kitover]

>Question, is there a way to get the latest version on
>a CD or a way to download packages to another machine
>so that I can copy them to a cd to install.  I'm
>interested in all of the packages.

Run http://www.cygwin.com/setup.exe and choose "download download from
internet" on the first screen.

Choose a directory you want to use, select all the packages you want and
download.

Burn the directory you used to download the packages to onto a CD.

Put a copy of "setup.exe" on the cd as well.

Run setup.exe on the computer you want to install Cygwin to, choose "Install
from local directory", put in the cd, choose "e:\" or whatever your cd
corresponds to.

HTH

-- 
Rafael

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

Insecure Dependency in Net::DNS with Cygwin (WAS: Cygwin, win98, SA, Perl IO::Socket (Insecure dependency))

[Rafael Kitover]

Here's some information about a bug with Net::DNS when running under taint
mode, previously reported here:

http://www.cygwin.com/ml/cygwin/2004-01/msg01062.html 


#!/usr/bin/perl -T

use strict;
use warnings;
use Net::DNS;
use Carp;

$SIG{__DIE__} = sub { confess @_ };

my $res = Net::DNS::Resolver->new(debug => 1);
my  @mx = mx($res, "customoffers.com");


The $SIG{__DIE__} generates a backtrace, the debug output and backtrace are
attached to this message.

I've tried the above script both with the CPAN version of Net::DNS and this CVS
snapshot:
http://www.net-dns.org/snaps/2004/01/Net-DNS-2004-01-28.tar.gz 

It seems like Net::DNS is failing to get a packet it likes back from a UDP
query (although the packet looks ok?) and then tries to send a TCP query using
some data coming from the failed UDP query, or something along those lines... 

Sending a report through the form on http://www.net-dns.org/ as well.

-- 
Rafael
;; query(customoffers.com, MX, IN)
;; send_udp(192.168.1.243:53)
;; send_udp(192.168.1.1:53)
;; answer from 192.168.1.1:53 : 507 bytes
;; HEADER SECTION
;; id = 4853
;; qr = 1opcode = QUERYaa = 0tc = 1rd = 1
;; ra = 1ad = 0cd = 0rcode  = NOERROR
;; qdcount = 1  ancount = 23  nscount = 0  arcount = 0

;; QUESTION SECTION (1 record)
;; customoffers.com.IN  MX

;; ANSWER SECTION (23 records)
customoffers.com.   38288   IN  MX  110 om7.customoffers.com.
customoffers.com.   38288   IN  MX  120 om8.customoffers.com.
customoffers.com.   38288   IN  MX  130 om9.customoffers.com.
customoffers.com.   38288   IN  MX  140 om10.customoffers.com.
customoffers.com.   38288   IN  MX  150 om11.customoffers.com.
customoffers.com.   38288   IN  MX  160 om12.customoffers.com.
customoffers.com.   38288   IN  MX  170 om13.customoffers.com.
customoffers.com.   38288   IN  MX  180 om14.customoffers.com.
customoffers.com.   38288   IN  MX  190 om15.customoffers.com.
customoffers.com.   38288   IN  MX  200 om16.customoffers.com.
customoffers.com.   38288   IN  MX  210 om17.customoffers.com.
customoffers.com.   38288   IN  MX  10 mail.customoffers.com.
customoffers.com.   38288   IN  MX  11 contact.customoffers.com.
customoffers.com.   38288   IN  MX  20 oc1.customoffers.com.
customoffers.com.   38288   IN  MX  30 oc2.customoffers.com.
customoffers.com.   38288   IN  MX  40 oc3.customoffers.com.
customoffers.com.   38288   IN  MX  45 oc4.customoffers.com.
customoffers.com.   38288   IN  MX  46 oc5.customoffers.com.
customoffers.com.   38288   IN  MX  50 om1.customoffers.com.
customoffers.com.   38288   IN  MX  60 om2.customoffers.com.
customoffers.com.   38288   IN  MX  70 om3.customoffers.com.
customoffers.com.   38288   IN  MX  80 om4.customoffers.com.
customoffers.com.   38288   IN  MX  90 om5.customoffers.com.

;; AUTHORITY SECTION (0 records)

;; ADDITIONAL SECTION (0 records)
;;
;; packet truncated: retrying using TCP
;; send_tcp(192.168.1.243:53) (src port = 0)
Insecure dependency in connect while running with -T switch at 
/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/IO/Socket.pm line 114.
main::__ANON__('Insecure dependency in connect while running with -T switch 
a...') called at /usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/IO/Socket.pm line 114

IO::Socket::connect('IO::Socket::INET=GLOB(0xa2b2be8)','\x{2}\x{0}\x{0}5\x{c0}\x{a8}\x{1}\x{f3}\x{0}\x{0}\x{0}\x{0}\x{0}\x{0}\x{0}\x{0}')
 called at /usr/lib/perl5/5.8.2/IO/Socket/INET.pm line 224

IO::Socket::INET::connect('IO::Socket::INET=GLOB(0xa2b2be8)','\x{2}\x{0}\x{0}5\x{c0}\x{a8}\x{1}\x{f3}\x{0}\x{0}\x{0}\x{0}\x{0}\x{0}\x{0}\x{0}')
 called at /usr/lib/perl5/5.8.2/IO/Socket/INET.pm line 199

IO::Socket::INET::configure('IO::Socket::INET=GLOB(0xa2b2be8)','HASH(0xa27699c)') 
called at /usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/IO/Socket.pm line 48

IO::Socket::new('IO::Socket::INET','PeerAddr',192.168.1.243,'PeerPort',53,'LocalAddr',0.0.0.0,'LocalPort','undef',...)
 called at /usr/lib/perl5/5.8.2/IO/Socket/INET.pm line 32

IO::Socket::INET::new('IO::Socket::INET','PeerAddr',192.168.1.243,'PeerPort',53,'LocalAddr',0.0.0.0,'LocalPort','undef',...)
 called at 
/usr/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int/Net/DNS/Resolver/Base.pm line 
492

Net::DNS::Resolver::Base::send_tcp('Net::DNS::Resolver=HASH(0xa29f268)','Net::DNS::Packet=HASH(0xa1af28c)','\x{12}\x{f5}\x{1}\x{0}\x{0}\x{1}\x{0}\x{0}\x{0}\x{0}\x{0}\x{0}\x{c}customoffers\x{3}com\x{0}\x{0}\x{f}\x{0}\x{1}')
 called at 
/usr/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int/Net/DNS/Resolver/Base.pm line 
445

Net::DNS::Resolver::Base::send('Net::DNS::Resolver=HASH(0xa29f268

RE: perlcc does not work on my cygwin-please help

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Pinhas Krengel
>Sent: Tuesday, January 27, 2004 9:09 AM
>To: [EMAIL PROTECTED]
>Subject: perlcc does not work on my cygwin-please help
>
>perlcc does not work on my cygwin (win XP). I have tried to re-install
>cygwin, read the assorted documents but can not figure out what is wrong.
>It seems to be a very basic problem as it reports error of not finding some
>file that are installed in my perl package. For example perl.h is not found.
>The file is on my system at
>/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE/perl.h. A place where cygwin
>selected to install it.
>I use mingw as the gcc compiler. It was recommended to install it not under

The normal Cygwin perlcc works just fine.

perlcc creates a binary that is linked to the Perl DLL. The Perl DLL is linked
to Cygwin. What you are trying to do, that is making a non-cygwin binary that
links to a Cygwin dll, makes no sense. And of course, the mingw gcc will not
understand Cygwin paths.

Also, when you have Cygwin installed there's no real need to install mingw, you
can use gcc -mno-cygwin instead with the w32api package, which is pretty much
the same thing.

If you want to use perlcc to create binaries that don't depend on Cygwin, you
will have to compile a copy of Perl with mingw then use its perlcc.

You might be able to get away with using ExtUtils::FakeConfig with activeperl
and mingw if you don't want to use ActivePerl's perlcc which requires visual
studio.

This is all completely offtopic by the way.

-- 
Rafael

--
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, dircolors, setsid and a stackdump

[Rafael Kitover]

I just compiled the cygwin dll from latest CVS, and the problem reported in
this thread, ie the script:

--
#!/bin/bash
echo foo
sleep 10
--

When run with "setsid bash script.sh" no longer produces a stackdump and works
correctly.

-- 
Rafael

--
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, dircolors, setsid and a stackdump

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>David Rothenberger
>Sent: Thursday, January 22, 2004 10:32 AM
>To: [EMAIL PROTECTED]
>Subject: bash, dircolors, setsid and a stackdump
>
>I've just encountered a very strange problem involving setsid, rxvt,
>bash and dircolors.  I'm using CVS from Thu Jan 22 07:18:16 PST
>2004.
>
>I have a simple script script.sh:
>
>---begin script---
>#!/bin/sh
>echo foo
>sleep 10
>---end script---
>
>I have uncommented the dircolors line in the default /etc/profile
>and am using the default /etc/DIR_COLORS.
>
>I start an rxvt window with "rxvt -e bash --login -i".  From that
>window, I execute "setsid bash script.sh" and get a stackdump from
>sleep.exe.
>
>---begin stackdump---
>Exception: STATUS_ACCESS_VIOLATION at eip=6100256C
>eax=616727A4 ebx= ecx=6167 edx=435F534C esi=0EC8 edi=00BE
>ebp=0022DA88 esp=0022DA70 program=C:\cygwin\bin\sleep.exe
>cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
>Stack trace:
>Frame Function  Args
>0022DA88  6100256C  (6167, 0002, 0022DAA8, )
>/netrel/src/cygwin-20040122/winsup/cygwin/cygheap.cc:180
[SNIP]

I also see this, with rxvt and zsh.

I would dearly love to know how you get those lovely line numbers in the
stackdump :)

Also I tried setting CYGWIN_DEBUG=sleep, but that never got to attach gdb
before the process died.

-- 
Rafael

--
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: grep doesn't work w/ latest cygwin

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>stillwater269
>Sent: Wednesday, January 21, 2004 8:08 PM
>To: [EMAIL PROTECTED]
>Subject: grep doesn't work w/ latest cygwin
>
>I've downloaded the latest cygwin for the first time
>yesterday (1/20/04).  Downloaded from cygwin.com, got
>the setup.exe, and ran it.  My aim was to use
>postgres. initdb calls grep, and it fails missing the
>dll "cygpcre.dll".  initdb additionally fails missing
>the dll "cygcrypt-0.dll".
>

Although packages should theoretically depend on all the other packages they
need, if this does happen you can search for files using setup package search
here:

http://cygwin.com/packages/ 

Then install the packages you find using the Full view in setup.exe

HTH

-- 
Rafael

--
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] New Package Available: perl-libwin32-0.191-1

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Edward S. Peschko
>Sent: Wednesday, January 21, 2004 4:58 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [ANNOUNCEMENT] New Package Available: perl-libwin32-0.191-1
>
>exceedingly cool...
>
>Just curious, but are the code patches to do this merged into the standard
>distributions (ie: the standard libwin32 api (which I think is with perl
>itself)?
>And does this work in mingw mode (ie: with -mno-cygwin)?

Absolutely, if you have a Perl built with MinGW. The libwin32 source builds
cleanly with MinGW and Borland C/C++ 5.5.
Building a Perl with MinGW is described in man perlwin32, except that you don't
have to install the (non-cygwin) MinGW distribution, but simply use
CC="gcc -mno-cygwin".

There is apparently a way to build modules for ActivePerl with MinGW, described
here, note the patch referenced on that page is not used in my package:

http://perso.club-internet.fr/rocherl/HowTo/howto-mingw.html 

And here: 

http://tinyurl.com/33qny (search.cpan.org)

I haven't tried this myself, but I will in the future.

>(ps - also, do you know the difference perchance between Win32::GUI and
>Win32::GUITest? Can you do mouse events, supply keys to applications, etc?

http://search.cpan.org/ is a good place to look for modules and find out what
they do. You can install Win32::GuiTest on Cygwin with
perl -MCPAN -e shell
force install Win32::GuiTest
The tests aren't quite Cygwin friendly, but they all pass. Not sure if it works
or not, and it spews out a whole bunch of gcc warnings, which is normal with
code written for VC++.

>
>(
>pps - as for the other Win32:: modules, do you know their status
>(Win32::AdminMisc, etc)? I'd very much like to be able to do pretty much
>everything I can do with ActiveState under cygwin (and possibly mingw)
>perl, and that means setting up services, setting environment variables,
>testing
>GUIs via sending keystrokes and mouse-events, modifying registry varbs, etc.
>libwin32 does some of this stuff, but not all...

You can probably install many Win32:: modules using the CPAN shell, some you
might need to tweak a bit to install cleanly (see your ~/.cpan/build). In such
cases I'd encourage you to send patches to the authors. If you run into
problems building something, and you've read all the relevant documentation,
this list may be able to help.

I've seen many references to Win32::AdminMisc, but it wasn't easy to find as
CPAN doesn't think that module exists... here's the homepage:
http://www.roth.net/perl/adminmisc/ 

Also it doesn't use MakeMaker, but comes with a visual studio .dsp file... I'll
see if I can get it properly Cygwin-ized.

-- 
Rafael

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

[ANNOUNCEMENT] New Package Available: perl-libwin32-0.191-1

[Rafael Kitover]

Description
=

The libwin32 Perl library that provides access to the Win32 API, and is
installed by default with ActivePerl, is now available as a Cygwin package.

The CORE Win32 methods in ActivePerl such as Win32::GetLastError() (see man
Win32 or perldoc Win32) are also available as an extension.

Also included is version 0.0.670 of the actively developed Win32::GUI library,
providing access the Win32 graphical APIs.

A lot of this functionality is already available through the /proc interface
and various utilities bundled with Cygwin, but this allows greater
compatibility with CPAN modules and various scripts written for ActivePerl on
Cygwin.

Quickstart
=

Browse through /usr/share/doc/perl-libwin32-0.191/. Examples and tests for
various modules and extra documentation is located there. Manual pages are
installed as well, eg. "man Win32API::File".

Differences from ActivePerl
=

* The core Win32 methods are statically linked into ActivePerl, they are NOT
when using this library.

So while:

/cygdrive/c/Perl/bin/perl -le 'print Win32::FormatMessage(5)'

works, in Cygwin you would have to do:

perl -MWin32 -le 'print Win32::FormatMessage(5)'

Generally, when porting a windows Perl script, a "use Win32;" statement will be
required. To get just the CORE method, "use Win32CORE;".

* $^E is the equivalent of Win32::FormatMessage(Win32::GetLastError()) on
ActivePerl, while it is the SAME as $! on Cygwin Perl. Therefore:

> perl -MWin32 -le 'open F,"xyzzy"; print $^E'
No such file or directory
> /cygdrive/c/Perl/bin/perl -MWin32 -le 'open F,"xyzzy"; print $^E'
The system cannot find the file specified

To get the equivalent:

> perl -MWin32 -le 'open F,"xyzzy"; print Win32::FormatMessage(
Win32::GetLastError)'
The system cannot find the file specified.

This may be fixed in the future.

* Win32API::File::OsFHandleOpen is not really implemented, since there is no
open_osfhandle() in Cygwin. At present it just ties a simple and not fully
functional interface to other Win32API::File calls to a Perl file handle. It
needs a lot more work to be transparent.

* Overlapped IO may not really work, but it hasn't really been implemented
fully in the library in the first place.

Have fun!
=

-- 
Rafael



--
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 regarding perl and perl-libwin32 using the latest cygwin ... and an anomaly

[Rafael Kitover]

Hi Alan,

My apologies for not sending out an announcement about this package, was
waiting for the 1.5.7 stuff to die down a bit first, but I will shortly.

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Alan Miles
>Sent: Tuesday, January 20, 2004 9:26 PM
>To: [EMAIL PROTECTED]
>Subject: Question regarding perl and perl-libwin32 using the latest cygwin ...
>and an anomaly
>
>All,
>
>Is there a solution to the problem of having to use
>
>perl -I /usr/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int/
>
>when executing any examples, or use the facilities in perl-libwin32. See an
>example below:
>
>[EMAIL PROTECTED] /usr/share/doc/perl-libwin32-0.191/Sound$ ./test.pl
>use: not found
[SNIP]

test.pl is not a bash script, and that tries to execute it as one since there's
no #!/usr/bin/perl line at the top. My fault for not using the appropriate
ExtUtils function for installing these, but this is a fairly minor bug so I
will fix it on next package revision, as "perl test.pl" should work
fine...unless of course it doesn't and the problem you're describing below can
be reproduced.

>
>[EMAIL PROTECTED] /usr/share/doc/perl-libwin32-0.191/Sound$ perl -I
>/usr/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int/ test.pl
>
[SNIP]
>
>Now it doesn't (and the sound played fine).
>
>This is true of all the other examples under
>/usr/share/doc/perl-libwin32-0.191. This tells me that I must either use the
>perl -I... syntax to use the new library routines, or put this in the magic
>line (haven't tried this, so I don't know if it will work - I would assume
>it would).

Have you tried just running "perl test.pl"? Works here, this is on a fresh
Cygwin install. I can't seem to reproduce this.

Some questions for you:

Do you have the latest perl package?

When you run "perl -V", is
"/usr/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int" at the bottom of the
output, in the @INC array? Is archname set to
"archname=cygwin-thread-multi-64int"?

Does "which perl" give you /bin/perl ?

Does perl -MWin32::OLE -le 'print $Win32::OLE::VERSION' print "0.1502" or does
it give you an error?

>
>[EMAIL PROTECTED] /usr/share/doc/perl-libwin32-0.191/Win32CORE/tests$
>$ perl -I /usr/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int/
>win32core.pl
>1..1
># Running under perl version 5.008002 for cygwin
># Current time local: Tue Jan 20 18:30:33 2004
># Current time GMT:   Tue Jan 20 18:30:33 2004
># Using Test.pm version 1.24
>ok 1
>
>[EMAIL PROTECTED] /usr/share/doc/perl-libwin32-0.191/Win32CORE/tests$ date
>Tue Jan 20 12:31:01 CST 2004
>
>[EMAIL PROTECTED] /usr/share/doc/perl-libwin32-0.191/Win32CORE/tests$
>
>The date/time stamp reported by win32core.pl doesn't make any sense - the
>GMT does, NOT the local - I am on Central US time (as reported by date).
>

It seems that there's something wrong with "localtime" in Perl. I can reproduce
this:

$ echo $TZ
PST8PDT7,M4.1.0/2,M10.5.0/2
$ date
Tue Jan 20 23:10:12 PST 2004
$ perl -MPOSIX=strftime -le 'print strftime("%x %X",gmtime)'
Wed Jan 21 2004 07:10:21
$ perl -MPOSIX=strftime -le 'print strftime("%x %X",localtime)'
Wed Jan 21 2004 07:10:26

However, when I try the newlib "localtime" function, it works fine:

$ cat localtime.c
#include 
#include 

int main(int argc, char** argv)
{
char buf[1024];
time_t cur_time = time(NULL);
strftime(buf, sizeof(buf), "%x %X\n", localtime(&cur_time));
printf(buf);
return 0;
}
$ gcc localtime.c -o try.exe && ./try.exe
Tue Jan 20 2004 23:19:23
$

>_
>Alan Miles
>ICQ#: 171006836
>More ways to contact me: http://wwp.icq.com/171006836
>_

-- 
Rafael

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

some notes on debugging screen (long) (was: cygwin-1.5.6-1 Vim now broken)

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor
>Sent: Tuesday, January 20, 2004 9:11 AM
>To: [EMAIL PROTECTED]
>Subject: Re: cygwin-1.5.6-1 Vim now broken
>
[SNIP]
>>I guess it'd be a show stopper if screen were part of Cygwin.  Still, I
>>think it's more important than Vim, as there are a dozen editors but no
>>screen alternatives.
>
>That's truly amazing logic.
>
>1) Vim is probably the most popular editor in cygwin.
>
>2) It's a SEGV from cygwin.  It would be folly to ignore those.
>
>3) As you note, screen doesn't even ship with cygwin.
>
>>Anyway, I did what I could, reporting it before 1.5.6 -
>>http://www.cygwin.com/ml/cygwin/2003-12/msg00557.html .  I'm not
>>complaining.  I also reported it to the screen mailing-list today as
>>there are a few Cygwin users and one may be able to help you with it.
>
>"Help me with it".  Yeah.  That's one way to look at it.
>
>Why don't you help *us* with it by debugging the problem?  I don't
>really care about screen but if it's important to you then some
>hours with gdb might be in order.  That's what I do with problems
>that I care about.
>
>cgf

Agreed Chris :)

To anyone who wants to take up a gdb process in this noble cause, as I won't be able 
to work on it in the next few days at least,
following are some of my observations.

The problem:

In cygwin1.dlls post 1.5.5 screen windows are set at 80x25, first line of stty -a 
output:

speed 38400 baud; rows 25; columns 80; line = 0;

The problem of reattaching screens not working correctly is less urgent, but will be 
mentioned.

while screen believes the window size to be correct, which you can verify by looking 
CTRL+a+i

If you try to do something like:

stty rows 58 columns 133

You will get:

stty: standard input: Invalid argument

What this means is that TIOCSWINSZ (change win size) commands to the terminal result 
in an EINVAL (invalid argument).

FWIF, the code sending the EINVAL is around line 1105 in winsup/cygwin/fhandler_tty.cc:

case TIOCSWINSZ:
  if (get_ttyp ()->winsize.ws_row != ((struct winsize *) arg)->ws_row
  || get_ttyp ()->winsize.ws_col != ((struct winsize *) arg)->ws_col)
{
  if (!ioctl_request_event)
get_ttyp ()->ioctl_retval = -EINVAL;
  else
{
  get_ttyp ()->arg.winsize = *(struct winsize *) arg;
  SetEvent (ioctl_request_event);
  get_ttyp ()->winsize = *(struct winsize *) arg;
  killsys (-get_ttyp ()->getpgid (), SIGWINCH);
  if (ioctl_done_event)
WaitForSingleObject (ioctl_done_event, INFINITE);
}
}
  break;

Commenting out the second if/else allows you to send TIOCSWINSZ commands to the 
terminal, making the screens the correct number of
lines and columns. After this you can see that screen works correctly. THIS IS NOT the 
problem though, just something I noticed.
Screens still start with the wrong size.

What you need:

Get and compile winsup from cvs. See the FAQ for instructions. You may also want to 
install a copy of "insight".

Get screen-4.0.2 from a GNU mirror, apply the tiny attached patch to build. You should 
be on an NT+ system with CYGWIN=ntsec.

If you want to look at the reattach bug, you may want to use my hacked up screen from 
here:
http://www.io.com/~rkitover/screen-3.9.13.tar.gz . This version, IIRC, doesn't require 
ntsec.

You will not be able to use gdb on a screen binary directly, as you will get a "must 
be connected to terminal" error, use something
like:


#!/bin/sh
echo gdb --pid=$$ --directory=/path-to-screen-source/screen-3.9.13/ \
  --se=/path-to-unstripped-screen-binary/screen.exe
read akey
/path-to-unstripped-screen-binary/screen.exe


then run the gdb command this script prints out in another terminal

You can also try using insight, the GUI version of GDB.

Make sure you "set follow-fork-mode child" in gdb, or parent, depending on which part 
of screen you're trying to follow.

Using symbol-file /install/bin/cygwin1.dll should let you step into the Cygwin dll. 
(cd to the appropriate source directory).

If you want to try debugging the reattach problem, see:
http://sources.redhat.com/ml/cygwin-patches/2003-q2/msg00203.html 

Although this was a dead end, it may help you find the appropriate direction.

Good luck!

-- 
Rafael


screen-4.0.2-cygwin.patch
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/

RE: HEADSUP: Apache maintainer wanted!

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Corinna Vinschen
>Sent: Tuesday, January 20, 2004 5:54 AM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: HEADSUP: Apache maintainer wanted!
>
>Hi,
>
>The apache package is without maintainer for two weeks now.  The former
>maintainer wasn't able to update the apache package and its related
>mod_FOO packages since October, when the last call for update of packages
>were made, which still haven't updated to using OpenSSL 0.9.7 instead
>of 0.9.6.
>
>So, what we need are one or more people who are willing to take over
>maintainership of apache and the mod_FOO packages
>
>WITHIN THE NEXT TWO WEEKS.
>
>If nobody takes over, the apache and subsequent packages will be
>removed from the Cygwin distribution on 2004-02-03.
>
>Corinna

Hi Corinna,

just out of curiosity, in cases of emergency like this, would it be acceptable
if some one or more people volunteered to update, test and upload a package
(and take care of resulting fallout/question) but not to sign up as the
regular maintainer, would that work?

-- 
Rafael

--
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.6-1 Vim now broken

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor
>Sent: Monday, January 19, 2004 8:37 PM
>To: [EMAIL PROTECTED]
>Subject: Re: cygwin-1.5.6-1 Vim now broken
>
>And, no, screen becoming screwed up in an rxvt session is not a show
>stopper.

I'll take this one. I spent an embarrassingly long time last year rewriting the whole 
disgusting autoconf/#ifdef system in screen
and trying to debug it. This time I'll actually get it to work and detach/reattach 
properly and packaged or die trying :)

-- 
Rafael

--
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: package conffiles (was: man 1.5k-2 is broken)

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alejandro 
>Lopez-Valencia
>Sent: Monday, January 19, 2004 11:08 AM
>To: Cygwin List
>Subject: Re: man 1.5k-2 is broken
>
>On Sunday, January 18, 2004 8:44 PM [GMT-5],
>Larry Hall wrote:
>
>> At 11:03 AM 1/18/2004, Alejandro Lopez-Valencia you wrote:
>>> The file /usr/share/misc/man.conf specifies less flags as "-is".
>>> This must be set to "-isrR" to work with groff's default tty
>output
>>> using SGR codes.
>>
>>
>> If you had a /usr/share/misc/man.conf file before the install, you
>> won't get an updated version from the install.  Either make the
>> change manually or remove usr/share/misc/man.conf and reinstall.
>> There is nothing wrong with the man tarball.
>
>Hmmm... You are obliquely correct, of course, but your answer
>presumes too much. I am reporting a package configuration bug, not
>weeping for help on a "small little thing anybody should know how to
>do"(tm).[1] Are you the packager maintainer? (No I am *not*
>volunteering, thank you).
>
>IMAO, the maintainer should have fixed the obvious bug (and
>documented blunder!) of not using "-isrR" in man-1.5m2-1 by
>modifying the postinstall script to backup the old man.conf file if
>present and installing a new one with the bug fix.
>
>[1] A registered trademark of the BOFH, or it should be.

There's no policy for conffiles, or a way to handle them like in
debian. Not that debian handles them perfectly either. Hence there's
absolutely nothing wrong with the package, but you nonetheless bring
up a good point. Some of these problems aren't easily solvable, but
the situation could certainly be improved. Don't know if this
discussion should be here on cygwin-apps, if so feel free to LART me :)

This is approximately what debian does:

http://lists.debian.org/debian-devel/1999/debian-devel-199905/msg02133.html 

Here's my proposal for what Cygwin could start doing, based on that idea.

To handle a situation like this, suppose we have a Cygwin user ("Jane") who
hasn't updated her Cygwin installation in a few weeks, and the "boffo"
package is a few versions behind, at boffo-1.1-1. After an update from
setup.exe, package boffo-1.2-3 is getting installed. One of the principal
changes in the new package fixes a bug by modifying the configuration file
/etc/boffo.conf.

When the old package, boffo-1.1-1 was being installed, the conf file was
installed as /etc/boffo.conf.new. Then, when /etc/postinstall/boffo.sh was
being run, it invoked something like install_conffile /etc/boffo.conf.

install_conffile sees that /etc/boffo.conf does not exist, therefore it
copies /etc/boffo.conf.new to /etc/boffo.conf.dist and to /etc/boffo.conf.

Jane, in the use of "boffo", changed a line in /etc/boffo.conf
from: foo="" to foo="bar".

Now the new package, boffo-1.2-3 is getting installed. It installs the new
version of the conffile again as /etc/boffo.conf.new.

Now /etc/postinstall/boffo.sh runs again and calls install_conffile /etc/boffo.conf

There are now three boffo files in /etc,

/etc/boffo.conf.new version 1.2-3 standard conffile
/etc/boffo.conf.distversion 1.1-1 standard conffile
/etc/boffo.conf version 1.1-1 user modified conffile

install_conffile does a "diff -u boffo.conf.dist boffo.conf.new > boffo.conf.patch"
to create the changes in standard conffiles between versions 1.1-1 and 1.2-3.

Let's assume that the line foo="" didn't change between those versions, but in 1.1-1
there was a line like DEFAULT_OPTIONS="-a -b" that became DEFAULT_OPTIONS="-a -b -c",
and this change fixes a catastrophic failure of the "boffo" package to prevent nuclear
meltdowns.

So the patch looks like:

-DEFAULT_OPTIONS="-a -b"
+DEFAULT_OPTIONS="-a -b -c"

install_conffile then patches the boffo.conf file, and overwrites boffo.conf.dist with
boffo.conf.new, and everything is fine and dandy. Jane gets to keep her custom
conffile changes, and the important changes got propagated as well.

Of course, patch is not a very intelligent program, and until we have a heuristics 
based
patch that can recognize various things that are obvious to us, this procedure will
often fail.

Suppose Jane changed DEFAULT_OPTIONS to "-a -b -d", the conffile patch would no longer
apply, even if the -d option may have no bearing on the situation. install_conffile 
would
then need to notice this, it could leave the .rej files in /etc/, or it could put a 
more
user-friendly notice in /etc/setup.log like "could not change FOO to BAR in 
/etc/boffo.conf"
or whatever.

Some false-negatives could be further reduced by ignoring whitespace, changing fuzz 
offsets,
etc...

What do you guys think?

-- 
Rafael 



--
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/DBD::ODBC issue

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerrit P. Haase
>Sent: Saturday, January 17, 2004 9:17 AM
>To: Rafael Kitover
>Cc: [EMAIL PROTECTED]
>Subject: Re: Cygwin/DBD::ODBC issue
>
>Hallo Rafael,
>
>Am Freitag, 16. Januar 2004 um 23:56 schriebst du:
>
>> Hi Tommie,
>
>> DBD::ODBC seems like a very useful module to have available for
>> Cygwin. Could you post the patch you ended up having? I'll try to
>> get it to the maintainer(s).
>
>> Also, what ODBC driver manager did you use? What is your ODBCHOME
>> environment variable set to?
>
>Builds ok using libiodbc-3.51.1 ( http://www.iodbc.org/ ) besides
>this:
>
>$ make
>Makefile:300: *** missing separator.  Stop.
>
>[...]
>
>$ make test
>/bin/perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 
>'blib/arch')" t/*.t
>t/01base.ok
>t/02simple...skipped
>all skipped: DBI_DSN is undefined
[SNIP]
>
>
>Hmmm, need a database to run more useful tests...
>
>There is nameclash, postgresql-7.4.1-3 includes the file
>/usr/include/sqltypes.h and libiodbc-3.51.1 includes a file with the
>same name, additional there is a file with the same name included in
>the w32api-2.4-1 package, though this is in the /usr/include/w32api
>directory and is picked up at last from gcc.

Yup, the postgres maintainer Jason Tishler resolved this issue,
so upgrading postgres removes its version from /usr/include.

Installing libiodbc into /usr/local would probably allow playing with, with
the right -I flags, but would have to be fixed at some point and sent
upstream anyway. W32api has a sqltypes.h that is part of the MS platform SDK,
so that's all good.

As an aside, I'm preparing an ITP of GNU Stow,
http://www.gnu.org/software/stow/stow.html
with some Cygwin specific utility scripts to make it easier for people
to make and distribute unofficial Cygwin binaries and to maintain local
packages.

>
>I can send you patches to build libiodbc and MyODBC with shared
>libraries, however, I was not able to figure out how connect my local
>MySQL server via DBD::ODBC.

Please do! I'll happily play with it :)

Another thought, I saw that you built a Cygwin version of MySQL, but you
have some outstanding issues with it. It would be very cool to have a
mysql-client package in Cygwin, that would work with the native,
Cygwin and UNIX (over the network) versions of MySQL, and should probably
build without too many problems.

>
>The MyODBC driver works as expected (it is linked against libiodbc as
>is DBD::ODBC) but DBD::ODBC fails for some reason.

I'll take a crack at it, and see if I can persuade it to talk ODBC
directly to Access, Excel, SQL Server and such. Having dbi work with
those would be quite cool :)

Other crazy projects I'm working on right now ... figuring out why screen
reverted to 80x25 term sizes within screens with current snapshots and CVS,
writing a Cygwin kernel for pidentd, which may end up forcing me to implement
/proc/net/tcp, still trying to figure out how to map NT users to processes
without resorting to the DDK api, patching setrlimit to not complain when
it is used with stub values (SOMETHING_INFINITY iirc) for unsupported limits.

And now figuring out why every shell script on my system is starting to produce
stackdumps with STATUS_ACCESS_VIOLATION... time to reinstall Cygwin looks like.

Cheers,

>
>
>Gerrit
>--
>=^..^=

-- 
Rafael

--
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: deleting a file ending with a dot

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor
>Sent: Friday, January 16, 2004 1:58 PM
>To: [EMAIL PROTECTED]
>Subject: Re: deleting a file ending with a dot
>
>On Fri, Jan 16, 2004 at 12:37:01PM -0800, Andrew DeFaria wrote:
>>(It'd be nice if fuser worked under Cygwin but I realize that might be a
>>significant challenge to implement).
>
>sysinternals has something like this so it is feasible.  Don't they even
>release source for some packages?  Could be an interesting project.

Yup, I've looked through a bunch of it, interesting stuff.

http://www.sysinternals.com/ntw2k/source.shtml 

I got the "netstatp" package from here: 
http://www.sysinternals.com/ntw2k/source/tcpview.shtml 

To compile with Cygwin, not exactly fuser, but still interesting, patch attached.


netstatp-cygwin.patch
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/

RE: Cygwin/DBD::ODBC issue

[Rafael Kitover]

Hi Tommie,

DBD::ODBC seems like a very useful module to have available for Cygwin.
Could you post the patch you ended up having? I'll try to get it to the maintainer(s).

Also, what ODBC driver manager did you use? What is your ODBCHOME environment variable 
set to?

Thanks!

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jones, Tommie
>Sent: Friday, January 16, 2004 12:47 AM
>To: Jeff Urlwin; David Claughton; [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: RE: Cygwin/DBD::ODBC issue
>
>Hello all.
>Just to conclude this issue. Not only was there a problem with where sqltypes.h file 
>was located. I
>also had an issue with 4 or 5 types missing. I had to add a few typedefs like UWORD 
>and PTR to
>sqltypes.h
>I'm using the most recent version of cygwin 5.0 (I updated it yesterday. Sorry I dont 
>know much about
>cygwin, don't know how to identify the version.)
>So I found three issues listed in the order of discovery.
>1. spaces prefixing the NOOP in the makefile
>2. wrong version of sqltypes
>3. missing types needed by sqltypes.


--
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: deleting a file ending with a dot

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew DeFaria
>Sent: Friday, January 16, 2004 12:39 PM
>To: [EMAIL PROTECTED]
>Subject: Re: deleting a file ending with a dot

>(It'd be nice if fuser worked under Cygwin but I realize that might be a
>significant challenge to implement).

Ahh, but this sort of insanity is usually the most fun. I'll take a look after I get 
screen and pidentd working :)

-- 
Rafael

--
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: bug in cygwin build of Make

[Rafael Kitover]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Pearce
>Sent: Thursday, January 15, 2004 1:25 PM
>To: [EMAIL PROTECTED]
>Subject: Re: bug in cygwin build of Make
>
[SNIP]
>
>
>CVSVIEW= $(shell if [ -e CVS/Repository ]; then echo ${CURDIR} | sed
>-e "s|`cat CVS/Repository | sed -e "s|^[^/]*||"`||"; else echo
>$$CVSVIEW; fi)
>
>bus_pack-pkg.vhd : ${CVSVIEW}/doc/mem_map.csv ${CVSVIEW}/etc/bus_pack.pl
>perl ${CVSVIEW}/etc/bus_pack.pl -v ${CVSVIEW}/doc/mem_map.csv
>bus_pack-pkg.vhd
>
>
>Even though it now working, is there a better way of doing this?
>

Certainly, see this paper on non-recursive make, entitled "Recursive Make Considered 
Harmful":

http://aegis.sourceforge.net/auug97.pdf

I read it a few years ago and it completely changed my perspective on build systems. 
Using that technique, instead of executing
copies of make in subdirs, you include pieces of makefiles from subdirs and end up 
with only one dependency tree. This gives you
cleaner, more accurate builds with less spam. It's harder to convert a build system to 
that format than it is to use it when making
one from scratch :)

-- 
Rafael

--
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: Python 2.3 Cygwin and SIP and PyQT

[Rafael Kitover]

Those files would be in the Python library, see if you have a file such as:

/lib/python2.3/config/libpython2.3.dll.a

Then add something like the following to the link command in your Makefile:

-L/lib/python2.3/config/ -lpython2.3.dll

Also check ./configure --help, there might an option like --with-python-lib=whatever,
Running ./configure LDFLAGS="-L/lib/python2.3/config/ -lpython2.3.dll" might also do 
it.

Btw, to search for undefined references to symbols, you can do stuff like:

nm -A /lib/python2.3/config/libpython2.3.dll.a | grep PyInt_FromLong

Sometimes even nm -A /lib/* | grep -i foo can help when trying to get something to 
build.

HTH

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hardy Jonck
>Sent: Thursday, January 15, 2004 2:34 AM
>To: '[EMAIL PROTECTED]'
>Subject: RE: Python 2.3 Cygwin and SIP and PyQT
>
>Hi All,
>
>I am still on my sip compile spree, and need some help with the following
>when running 'make':
>
>siplib.o(.text+0x3b8e):siplib.c: undefined reference to `_PyInt_FromLong'
>siplib.o(.text+0x3be5):siplib.c: undefined reference to `_PyInt_AsLong'
>Info: resolving _qApp by linking to __imp__qApp (auto-import)
>collect2: ld returned 1 exit status
>make: *** [/usr/local/lib/python2.3/site-packages/cygsip-10.dll] Error 1
>
>
>
>
>
>Can someone please point me in the right direction as to what I might be
>missing.
>
>Sincerely
>Hardy Jonck
>


--
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: Tool to decrease a size of jpg file

[Rafael Kitover]

Sorry for failing to RTFM, but apparently there is an ImageMagick
package in Cygwin already:

http://cygwin.com/cgi-bin2/package-cat.cgi?file=ImageMagick/ImageMagick-
5.5.7-1&grep=image

So you don't need to compile anything.

Once you have ImageMagick installed, to reduce the size of a jpg file, a
good trick is:

convert -quality 64 foo.jpg foo.jpg

see man convert for other options, to shrink dimensions use -resize.

HTH

-- 
Rafael

--
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: Tool to decrease a size of jpg file

[Rafael Kitover]

You should be able to compile imagemagick without much problem, get the
unix source from:

http://www.imagemagick.org/www/archives.html?

You could also just install the windows binaries and put them in your
Cygwin PATH.

-- 
Rafael

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

[ANNOUNCEMENT] Win32::GUI Perl module available for Cygwin and MinGW

[Rafael Kitover]

I've added the Win32::GUI module to libwin32, which allows you to
do...Win32 GUI stuff in Perl.

Download it here:

http://sourceforge.net/projects/libwin32-exp/

-- 
Rafael

--
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: is there a screen for cygwin?

[Rafael Kitover]

Try my extremely modified version here:

http://www.io.com/~rkitover/screen-3.9.13.tar.gz

I haven't worked on it in quite a while, detach is still broken and it's
a few versions behind now, but you will have working screen sessions.

-- 
Rafael

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

Question about default base address and offset for rebasing DLLs

[Rafael Kitover]

I noticed that the /bin/rebaseall script assumes the following:

DefaultBaseAddress=0x7000
DefaultOffset=0x1

Is this going to be the standard base and offset for DLLs in Cygwin?

Is this then a reasonable thing to include in the Cygwin hints file for
my Perl project:

package MY;
sub MY::dynamic_lib {
   my $target = shift->SUPER::dynamic_lib(@_);
   if (defined $target && $target && -e '/bin/rebase') {
$target .= <<'EOF';
rebase -v -d -b 0x7000 -o 0x1 $@
EOF
   }
   $target;
}

This appends the rebase command to the Makefile target that builds the
dll.

I've had some mapping problems when building Perl extensions without
this in the hints file. Will binutils eventually rebase things to some
sort of standard as well?

-- 
Rafael

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

rebaseall breaks zsh?

[Rafael Kitover]

I noticed that the rebaseall scripts rebases /usr/bin/libzsh-4.0.4.dll
and the modules in /usr/lib/zsh/4.1.1/zsh/*.dll, and that this breaks
zsh. Rebasing libzsh stops zsh from starting, and rebasing the modules
stops them from loading.

If this is the case, and not just something messed up on my system,
adding:

-e '/\/libzsh-.*\.dll$/d' -e '/\/lib\/zsh/d'

To the sed filter on the script should fix it. Or perhaps making an
/etc/rebase.conf with exclusion filters. Want me to make a patch?

-- 
Rafael

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