Re: [1.7] cygcheck totally broken

[Albrecht Schlosser]

Andrew Schulman wrote:


$ cygcheck --version
cygcheck version 1.104
System Checker for Cygwin
Copyright (C) 1998 - 2008 Red Hat, Inc.
Compiled on Sep 11 2008

$ cygcheck -svr

Cygwin Configuration Diagnostics
Current System Time: Thu Sep 11 21:18:35 2008


Cygwin Configuration Diagnostics
Current System Time: Thu Sep 11 21:18:35 2008


Cygwin Configuration Diagnostics
Current System Time: Thu Sep 11 21:18:35 2008


Cygwin Configuration Diagnostics
Current System Time: Thu Sep 11 21:18:35 2008


Cygwin Configuration Diagnostics
Current System Time: Thu Sep 11 21:18:35 2008


Cygwin Configuration Diagnostics
Current System Time: Thu Sep 11 21:18:35 2008


Is it exactly 6 times? This looks like the cygwin's default
process retry count of 5 times, if a process doesn't start
correctly or is killed somehow. I know, this doesn't help
to find the real problem, but anyway ...

Albrecht


--
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 experimental package: gcc4-4.3.0-1

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dave Korn wrote:
>   :)  If so, I will submit upstream.  Actually I think I can probably do it
> all with the hooks and overrides, but I haven't got up-to-date with the
> prep_gnu_info changes yet ...

In that case, you know where to find me. :-)

>   That's all I get from a default build, I'm not sure if --disable-libjava is
> the upstream default right now but knowing the somewhat sorry state of libjava
> on cygwin I wouldn't be surprised.  (I'll give it a go and if anything manages
> to compile, I'll ship it.)

Perhaps when you have the next release with a standard cygport,

>   Because I didn't use libtool to do it.  I think Aaron's patch to build
> libgcc shared from upstream does it properly, so I'll be adopting it if I can,
> otherwise I'll just crudely bodge it in.

Since the name of the libgcc dll is manually specified in
gcc/config/i386/{cygwin.h,t-cygwin}, isn't it just a matter of changing
those to cyggcc_s-1.dll?  Or am I missing something?

>   Didn't look at fortran and objc.

Presuming that F95 and ObjC/ObjC++ don't have the problem with overrides
that C++ has, it should be as simple as adding the -no-undefined flag.

>   The problem with making shared libstdc - it can be done - is that it shows
> regressions, because win32 doesn't currently fully support the semantics of
> weak symbols like ELF does.  Specifically, since a DLL has to be
> fully-resolved when it is linked, any references to e.g. operators new/delete
> get statically resolved as internal calls within the DLL, and then when you
> attempt to define a custom operator new/delete override within your
> executable, it doesn't get interposed between the already-resolved calls and
> their destinations within the DLL.
> 
>   This would make the C++ compiler non-compliant, so as it all works OK with a
> static library, I'm shipping it that way for now.
> 
>   I plan to work on improving weak symbol support in binutils to resolve this
> problem in the long run; I think we can make it work with a little bit of
> thunk stubbery[*].

I think I get the picture; helping to figure that out is beyond me.

>   ? dunno.  That's a whole nother story, isn't it?

I suppose so.  Definitely not urgent, just curious.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkjKH4EACgkQpiWmPGlmQSMuugCeOFPWFs0INxU540XaPYFgnFt0
gEQAoPckVVyAYmNM+rCP30qzfrmUOvOt
=xgq0
-END PGP SIGNATURE-

--
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 experimental package: gcc4-4.3.0-1

[Brian Dessent]

Dave Korn wrote:

> > Why bother?
> 
>   Hence the "may".  I don't plan to bother for myself, but it depends if I

Please don't.  gcc isn't special in this regard, it shouldn't receive
any special treatment.  bash fails without cygintl-8.dll and I don't
think anyone is proposing to statically link libintl into bash just
because some people seem to find ways to screw up their installations by
not installing libintl8.  If there's a problem we need to fix the root
cause, not paper it over.

Besides, in 1.7 there is a sensible error message when a DLL isn't
found.

>   That's all I get from a default build, I'm not sure if --disable-libjava is
> the upstream default right now but knowing the somewhat sorry state of libjava
> on cygwin I wouldn't be surprised.  (I'll give it a go and if anything manages
> to compile, I'll ship it.)

You do need --enable-libjava on Cygwin, it's not enabled by default. 
Aaron posted a patch to build is as a DLL and with that it should be
usable again, at least with DW2 (not SJLJ.)  The bulk of the issues as I
understand it were with the fact that statically linking java just
doesn't work very well.

>   The problem with making shared libstdc - it can be done - is that it shows
> regressions, because win32 doesn't currently fully support the semantics of
> weak symbols like ELF does.  Specifically, since a DLL has to be
> fully-resolved when it is linked, any references to e.g. operators new/delete
> get statically resolved as internal calls within the DLL, and then when you
> attempt to define a custom operator new/delete override within your
> executable, it doesn't get interposed between the already-resolved calls and
> their destinations within the DLL.
> 
>   This would make the C++ compiler non-compliant, so as it all works OK with a
> static library, I'm shipping it that way for now.

IMHO, despite the above we should still ship shared libstdc++ even if
it's not the default -- though I would even argue that we should go one
step farther and make it the default and say that if you need to
override operator new you select the static libstdc++.  Otherwise, we
just get ourselves into ABI compatibility hell because every C++ library
gets a copy of libstdc++ linked into it, which means they are tied to
the compiler version.  As it is now we are going to have to rebuild all
libstdc++-using code in the distro with the new compiler because up
until now we had no choice but static libstdc++, but by not stopping
this insanity now we only prolong it.

>   I plan to work on improving weak symbol support in binutils to resolve this
> problem in the long run; I think we can make it work with a little bit of
> thunk stubbery[*].

PE does have weakref, where you supply a backup symbol name along with
the reference.  If the symbol is defined elsewhere then that definition
is used, otherwise the backup one supplied with the weakref is used --
but in either case it does not go undefined.  But I'm not sure how this
would be useful in the case outlined above.

> > Also, is OpenMP available?  Is it being worked on?
> 
>   ? dunno.  That's a whole nother story, isn't it?

Should work fine.  Requires explicit --enable-libgomp though (not
enabled by default.)

Brian

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

Re: [ANNOUNCEMENT] New experimental package: gcc4-4.3.0-1

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Brian Dessent wrote:
> Please don't.  gcc isn't special in this regard, it shouldn't receive
> any special treatment.  bash fails without cygintl-8.dll and I don't
> think anyone is proposing to statically link libintl into bash just
> because some people seem to find ways to screw up their installations by
> not installing libintl8.  If there's a problem we need to fix the root
> cause, not paper it over.

Agreed.  BTW, I noticed that gcc builds with static libintl/libiconv
(the standard config.rpath flaw); low priority, but I really don't like
static linking unless absolutely necessary.

> IMHO, despite the above we should still ship shared libstdc++ even if
> it's not the default -- though I would even argue that we should go one
> step farther and make it the default and say that if you need to
> override operator new you select the static libstdc++. 

I admit to know very little about C++; how often would this happen?

> Otherwise, we just get ourselves into ABI compatibility 
> hell because every C++ library gets a copy of libstdc++ linked 
> into it, which means they are tied to the compiler version. 
> As it is now we are going to have to rebuild all
> libstdc++-using code in the distro with the new compiler because up
> until now we had no choice but static libstdc++, but by not stopping
> this insanity now we only prolong it.

Which is the current situation.  YA reason I think that gcc-4.3 should
be limited to release-2, and that everything should be rebuilt with it
for 1.7.

> Should work fine.  Requires explicit --enable-libgomp though (not
> enabled by default.)

I've seen a *small* number of packages using it so far, so it would be
nice to try.  But we'll need autoconf-2.62 as well.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkjKOCYACgkQpiWmPGlmQSNC1gCgymaPY6yNcOjoy5yxzTEGRBuO
aM8An1idh88XN7NuLHmlvVwtM4UiExKY
=aUiR
-END PGP SIGNATURE-

--
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: Help on dos2unix

[Heude Pascal (LTS)]

The command 'type dos2unix' gives the following result : dos2unix is 
/usr/bin/dos2unix
There is also a dos2unix in /bin.
It seems that there are identical (at least same name and same size).

Thanks for your help.

-Message d'origine-
De : Eric Blake [mailto:[EMAIL PROTECTED] 
Envoyé : jeudi 11 septembre 2008 03:03
À : cygwin@cygwin.com; Heude Pascal (LTS)
Objet : Re: Help on dos2unix

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please don't top-post: http://cygwin.com/acronyms/#TOFU

> -Message d'origine-
> De : cygwin-owner AT cygwin.com
   

And please don't feed the spammers: http://cygwin.com/acronyms/#PCYMTNQREAIYR

According to Heude Pascal (LTS) on 9/10/2008 7:39 AM:
> Yes, it is the cygwin version of dos2unix. And I also use the cygwin version 
> of make. But I am not running a bash but a pdksh.
> The command I launch is : "dos2unix l82023aa.x"
> If I look to the return code using the command "echo $?", I got 128.

128 is generally for application not found.  In other words, dos2unix was
probably not found in your current PATH settings.  What does 'which
dos2unix' or 'type dos2unix' say?  How about 'ls /bin/dos2unix'?

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjIbk4ACgkQ84KuGfSFAYA2iACcC5Us0brvehaM773Qc5uTKuDo
kjcAoJjjbSJcnjnMnCzAZoHJ81LAy3ax
=jJLq
-END PGP SIGNATURE-

--
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 experimental package: gcc4-4.3.0-1

[Dave Korn]

Yaakov (Cygwin Ports) wrote on 12 September 2008 08:51:

>>   Because I didn't use libtool to do it.  I think Aaron's patch to build
>> libgcc shared from upstream does it properly, so I'll be adopting it if
>> I can, otherwise I'll just crudely bodge it in.
> 
> Since the name of the libgcc dll is manually specified in
> gcc/config/i386/{cygwin.h,t-cygwin}, isn't it just a matter of changing
> those to cyggcc_s-1.dll?  Or am I missing something?

  I just don't know whether or not the version is embedded in the generated
DLL anywhere other than the name, so far.

>>   Didn't look at fortran and objc.
> 
> Presuming that F95 and ObjC/ObjC++ don't have the problem with overrides
> that C++ has, it should be as simple as adding the -no-undefined flag.

  I would anticipate so.


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


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

Re: Help on dos2unix

[Mark J. Reed]

You top posted again, and you left the email addresses in again.
Both of those are in violation of the list policy.

On Fri, Sep 12, 2008 at 6:19 AM, Heude Pascal (LTS) wrote:
> The command 'type dos2unix' gives the following result : dos2unix is 
> /usr/bin/dos2unix
> There is also a dos2unix in /bin.
> It seems that there are identical (at least same name and same size).

I believe that /usr/bin and /bin in Cygwin refer to the same directory.

Does the make command work, despite the exit code?  Are the carriage
returns gone from the file?

-- 
Mark J. Reed <[EMAIL PROTECTED]>

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

Re: Help on dos2unix

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Mark J. Reed on 9/12/2008 4:51 AM:
> You top posted again, and you left the email addresses in again.
> Both of those are in violation of the list policy.
> 
> On Fri, Sep 12, 2008 at 6:19 AM, Heude Pascal (LTS) wrote:
>> The command 'type dos2unix' gives the following result : dos2unix is 
>> /usr/bin/dos2unix
>> There is also a dos2unix in /bin.
>> It seems that there are identical (at least same name and same size).
> 
> I believe that /usr/bin and /bin in Cygwin refer to the same directory.

Yes, in the default installation, they are mounted to the same location.

> 
> Does the make command work, despite the exit code?  Are the carriage
> returns gone from the file?

One other thing to check is whether make is picking up a different shell
and/or path than what you are using on the command line, and thus using
non-cygwin tools in the process.  In other words, what does 'make all' say
on this file (remember to use tab)?

all:
@echo $$PATH, $$SHELL
@which dos2unix
@dos2unix --version

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjKWlwACgkQ84KuGfSFAYBB9wCgx0l3Abm9UyNiucmU2FoLi+Ny
HbUAmwRGC68sGjITzgZ5u5z45ZdNTeJf
=xEaS
-END PGP SIGNATURE-

--
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 experimental package: gcc4-4.3.0-1

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Yaakov (Cygwin Ports) on 9/12/2008 3:36 AM:
> I've seen a *small* number of packages using it so far, so it would be
> nice to try.  But we'll need autoconf-2.62 as well.

Or even the just-released autoconf-2.63.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjKWxoACgkQ84KuGfSFAYDOyACguSpFrJRzKtLHzdp2QYDwzKE7
3UgAn1DBJ9YHixLYFkb+FpdsRN/VEt0m
=r9RN
-END PGP SIGNATURE-

--
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: upgrading to perl-5.8.8-4

[Reini Urban]

Rob schrieb:
Yes, as I mentioned we use an internal packaging tool to install stuff and not 
CPAN, so I will just need to create this dir manually and add it to @INC.


On a related note, while searching for (an easy) way to do this, I found an 
awesome but ill-documented feature to do so: Luckily, perl was compiled with 
the USE_SITECUSTOMIZE option, so all I have to do is create a file called 
sitecustomize.pl and stick it in one of the existing @INC dirs. The file is a 
perl script that will push a dir to the @INC array as follows:

#!/usr/bin/perl
BEGIN { 
push @INC, "/usr/lib/perl5/site_perl";

}


This will not work with the current perl-5.10 anymore, because I removed 
USE_SITECUSTOMIZE.


You'll have to use env PERL5LIB=/usr/lib/perl5/site_perl
or better fix your tools which install into this wrong dir.
--
Reini Urban
http://phpwiki.org/  http://murbreak.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: Feature Request: bzr package only works within cygwin

[Jason Tishler]

On Thu, Sep 11, 2008 at 10:53:33AM -0400, Christopher Faylor wrote:
> On Thu, Sep 11, 2008 at 03:14:31PM +0100, Phillip Lord wrote:
> >Yes you do. Cygwin.bat. startxwin.bat, several in python.
> 
> [snip]
> 
> Other packages may already include .bat files which are already part
> of the distribution or the maintainer may have misguidedly felt that
> it was a good idea to include a .bat file.

Just to be clear, the .bat files in the Cygwin Python package are part
of the standard distribution and were not added by me.

On Cygwin, we have the following:

$ cygcheck -l python | fgrep .bat
/usr/lib/python2.5/ctypes/macholib/fetch_macholib.bat
/usr/lib/python2.5/idlelib/idle.bat

In a random Linux package, we have the following:

$ (wget -O - 
ftp://fr.rpmfind.net/linux/fedora/development/i386/os/Packages/python-2.5.1-30.fc10.i386.rpm
 | rpm2cpio | cpio -it) 2>/dev/null | fgrep .bat
./usr/lib/python2.5/ctypes/macholib/fetch_macholib.bat
./usr/lib/python2.5/idlelib/idle.bat

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
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 experimental package: gcc4-4.3.0-1

[Dave Korn]

Brian Dessent wrote on 12 September 2008 08:58:

> Dave Korn wrote:
> 
>>> Why bother?
>> 
>>   Hence the "may".  I don't plan to bother for myself, but it depends if
>> I 
> 
> Please don't.

  OK.  Suits me.

>>   That's all I get from a default build, I'm not sure if
>> --disable-libjava is the upstream default right now but knowing the
>> somewhat sorry state of libjava on cygwin I wouldn't be surprised. 
>> (I'll give it a go and if anything manages to compile, I'll ship it.)
> 
> You do need --enable-libjava on Cygwin, it's not enabled by default.
> Aaron posted a patch to build is as a DLL and with that it should be
> usable again, at least with DW2 (not SJLJ.)  The bulk of the issues as I
> understand it were with the fact that statically linking java just
> doesn't work very well.

  OK, will be in the next update but one (have a minor refresh coming
imminently.)

>>   This would make the C++ compiler non-compliant, so as it all works OK
>> with a static library, I'm shipping it that way for now.
> 
> IMHO, despite the above we should still ship shared libstdc++ even if
> it's not the default 

  I'd go that far.

> -- though I would even argue that we should go one
> step farther and make it the default 

  I won't ship a compiler that's non-compliant by default, if I can possibly
avoid it.  I don't mind making non-compliant behaviour available through a
command-line option, just not the default.

> and say that if you need to
> override operator new you select the static libstdc++.  

  How exactly would a package maintainer know if, somewhere deep down in an
included library package, there's something that critically depends on weak
linking against libstdc++?  They wouldn't, AFAICS, and the outcome would be a
very hard-to-find bug.

> Otherwise, we
> just get ourselves into ABI compatibility hell because every C++ library
> gets a copy of libstdc++ linked into it, which means they are tied to
> the compiler version.  As it is now we are going to have to rebuild all
> libstdc++-using code in the distro with the new compiler because up
> until now we had no choice but static libstdc++, but by not stopping
> this insanity now we only prolong it.
> 
>>   I plan to work on improving weak symbol support in binutils to resolve
>> this problem in the long run; I think we can make it work with a little
>> bit of thunk stubbery[*].
> 
> PE does have weakref, where you supply a backup symbol name along with
> the reference. 

  That's what binutils' existing pe weak symbol support is based on, yes.

> If the symbol is defined elsewhere then that definition
> is used, otherwise the backup one supplied with the weakref is used --
> but in either case it does not go undefined.  But I'm not sure how this
> would be useful in the case outlined above.

  The problem is the major difference between ELF DSOs and PE DLLS: DLLs have
to be fully resolved at link-time, not load-time.  So, when you're building
libstdc++ all those internal references to operator new have to be resolved
somewhere, and as the weakref is the only definition available that's where
they get linked to.  Permanently and forever.

  If they were instead resolved to some kind of thunk that could do a lookup
at runtime for non-weak versions of the same symbol, we'd be golden.  Well,
we'd need to make sure the non-weak versions were all declspecced dllexport
somehow, but that would do it for us.

>>> Also, is OpenMP available?  Is it being worked on?
>> 
>>   ? dunno.  That's a whole nother story, isn't it?
> 
> Should work fine.  Requires explicit --enable-libgomp though (not
> enabled by default.)

  Will give it a go.

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


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

Re: [1.7] cygcheck totally broken

[Andrew Schulman]

> Is it exactly 6 times? 

Yes, just as I posted it.


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

RE: 1.5.25(0.156/4/2): Problem compiling OpenLDAP 2.3.39 due to Win XP SP3 or Cygwin?

[Allan Schrum]

Hi Mary,

Sorry, but what you think I said is not true. My reference with Visual Studio 
2005 and Cygwin was in reference to the BLODA that was causing problems with 
Cygwin (my original post). My last follow-up was to indicate that the BLODA was 
much worse and far reaching in that it also affected a Visual Studio 2005 
solution that I had (a pure M$ product). This VS2005 solution is completely 
separate from Cygwin and does not use any libraries created by Cygwin. I do not 
have a method to take libraries compiled under Cygwin and to use them within 
VS2005.

I apologize for the confusion.

Regards,

-Allan

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mary
Sent: Thursday, September 11, 2008 3:22 PM
To: cygwin@cygwin.com
Subject: Re: 1.5.25(0.156/4/2): Problem compiling OpenLDAP 2.3.39 due to Win XP 
SP3 or Cygwin?

Thank you very much, Allan, I'm so glad you posted this! So it is
possible to compile
something through cygwin (gcc - make) and then to use it as a lib with
visual studio!
I was worried it would not work, because of an email from active perl
support I
received (I'm pasting it below your text).

If anyone knows of a link which explains how to do this, could you
please post it?
And by the way, has anyone here ever tried using HTK on windows (with
cygwin
I'm sure, because it compiles under Linux but visual studio won't have
anything to
do with it).

Mary

PS for Yaakov: Thank you for your patch, I'll post about this later
otherwise I'm
afraid this discussion might get confusing.


Allan Schrum wrote:
> BTW, this affected applications outside of Cygwin. A Visual Studio 2005
> solution that included several projects reported warnings about missing
> DLLs that were freshly compiled. When you looked at the file mentioned
> by the warning VS2005 could suddenly "find" the file and the warning
> would disappear.
>
ActiveState Support wrote:
> The first complication here is Cygwin. If you wish to use ActivePerl on
> Cygwin, you need to use native Win32 modules since ActivePerl is a Windows
> native program. Modules that will only run on a Unix version do exist, and
> they will not run with Win32 ActivePerl even with Cygwin. (In fact Cygwin can
> make the situation much, much worse. Cygwin "prefers" to use Cgywin Perl. If
> you compile with the Cygwin compiler, you are going to get a Linux module
> instead of a Win32 one.)
>
> We do not have any Windows compatible versions of Audio::Data, and The
> University of Winnipeg PPM search tool is unable to find any Win32 versions of
> this module in any known PPM repositories:
> http://cpan.uwinnipeg.ca/dist/Audio/
>
> Checking in at CPAN, I can see that Audio::Data has not been updated since
> 2004, and the author's account has been placed under a "custodial" status. The
> module seems to build well on Solaris and FreeBSD, but OS X, Win32, and even
> Linux report more failures that successes. The README claims it works on Win32
> (in 1998), but it's hard to be optimistic, especially since the man page lists
> a lack of support for .wav format as a known limitation.
>
> Overall, you probably need an alternative.
>
> Best regards,
>
> Graham Stuart
> Technical Support Engineer
> ActiveState - Dynamic Tools for Dynamic Languages
> http://www.ActiveState.com



Vinsamlega athugið að upplýsingar í tölvupósti þessum og viðhengi eru eingöngu 
ætlaðar þeim sem póstinum er beint til og gætu innihaldið upplýsingar sem eru 
trúnaðarmál. Sjá nánar: http://www.ru.is/trunadur

Please note that this e-mail and attachments are intended for the named 
addresses only and may contain information that is confidential and privileged. 
Further information:
http://www.ru.is/trunadur

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

Cygwin Design

Dear Sir/Medam;
I am deeply interested in implementing a simple 
command interpreter in Windows XP platform as a part of my summer 
project, so will you please give me some hint on implementing it.


Thanking You
Tazirul

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

Compiling dll libraries which can be used by visual studio?

[Mary]

Hi all,

Does anyone know of a way to use libraries compiled by gcc/make with
visual studio, please?
I'll do the tutorial example of
http://www.cygwin.com/cygwin-ug-net/dll.html but this only says
how to use gcc-compiled libs with gcc. Any link, hint or clue very welcome.

Mary



Vinsamlega athugið að upplýsingar í tölvupósti þessum og viðhengi eru eingöngu 
ætlaðar þeim sem póstinum er beint til og gætu innihaldið upplýsingar sem eru 
trúnaðarmál. Sjá nánar: http://www.ru.is/trunadur

Please note that this e-mail and attachments are intended for the named 
addresses only and may contain information that is confidential and privileged. 
Further information:
http://www.ru.is/trunadur

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

undefined reference to '_cfmakeraw'

[Andrew Bouchard]

I am trying to run cygwin and install a program called Moast, which  
requires the Linux-style environment that cygwin provides to run. At  
least that what it says - I'm a mechanical engineer by training, so I  
have to admit a fair amount of cluelessness here. The error that I get  
just before the installer gets out of all the directories is:


undefined reference to '_cfmakeraw'

I've tried to Google the problem and searched the mailing lists, but I  
keep coming up with diff files that show code. I get the impression  
from various places that these are fixes of some kind, but I don't  
know what they do, where they should go, or how to implement them.  
Could someone give a poor graduate student a little direction? Thanks  
very much.


Andrew

--
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: undefined reference to '_cfmakeraw'

[[EMAIL PROTECTED]]

On Fri, Sep 12, 2008 at 5:49 PM, Andrew Bouchard
<[EMAIL PROTECTED]> wrote:
> I am trying to run cygwin and install a program called Moast, which requires
> the Linux-style environment that cygwin provides to run. At least that what
> it says - I'm a mechanical engineer by training, so I have to admit a fair
> amount of cluelessness here. The error that I get just before the installer
> gets out of all the directories is:
>
> undefined reference to '_cfmakeraw'
>
> I've tried to Google the problem and searched the mailing lists, but I keep
> coming up with diff files that show code. I get the impression from various
> places that these are fixes of some kind, but I don't know what they do,
> where they should go, or how to implement them. Could someone give a poor
> graduate student a little direction? Thanks very much.

Some ideas:

(1) make sure that you chose to install all the cygwin packages
(optional subcomponents) which the program needs
(2) did you run configure?  some source tarballs are packaged with one
version of the makefiles produced by configure, which won't
necessarily work on other systems and almost certainly not on
cygwin/Windows
(3) some context for the error message
(4) results of grepping the source code for "cfmakeraw" so we know
whether it's defined or declared by that application (google reveals
it's actually a BSD function for setting terminal settings, and
missing from a lot of OSes such as Solaris, so it should already be
handled by the project's configure script if it has one)
(5) you should also try the moast-devel mailing list hosted on
sourceforge which google turns up very quickly

Applying a diff is a very straightforward fix.  The MOAST project
appears to be about developing autonomous robots.  What graduate
program are you in?  Programming skills would seem to be a
prerequisite for this sort of work, and if you're
unfamiliar/uncomfortable with something as basic and self-explanatory
as a diff file you should seriously make sure you are in the right
research area.


Ben Voigt
EE PhD Student

>
> Andrew
>
> --
> 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: Compiling dll libraries which can be used by visual studio?

[[EMAIL PROTECTED]]

On Fri, Sep 12, 2008 at 5:25 PM, Mary <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Does anyone know of a way to use libraries compiled by gcc/make with
> visual studio, please?

I googled for "Visual C++ create import lib" and found
http://qualapps.blogspot.com/2007/08/how-to-create-32-bit-import-libraries.html

This is of course applicable to DLLs only, not static libraries.  I do
not know any way to mix static libraries in different formats.

> I'll do the tutorial example of
> http://www.cygwin.com/cygwin-ug-net/dll.html but this only says
> how to use gcc-compiled libs with gcc. Any link, hint or clue very welcome.
>
> Mary
>
>
>
> Vinsamlega athugið að upplýsingar í tölvupósti þessum og viðhengi eru
> eingöngu ætlaðar þeim sem póstinum er beint til og gætu innihaldið
> upplýsingar sem eru trúnaðarmál. Sjá nánar: http://www.ru.is/trunadur
>
> Please note that this e-mail and attachments are intended for the named
> addresses only and may contain information that is confidential and
> privileged. Further information:
> http://www.ru.is/trunadur
>
> --
> 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/

[ANNOUNCEMENT] Updated experimental package: gcc4-4.3.2-1

[Dave Korn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



  I have just uploaded an updated GCC-4 package to cygwin.com.  It will be
arriving at your favourite mirror next time it synchronizes itself with the
official Cygwin repository.

  The main purpose of this update is to resolve the packaging conflict between
the original native Cygwin gcc-3.4.4 and this new package, which it does by
appending a version suffix.  "gcc.exe" is now "gcc-4.exe", "g++.exe" becomes
"g++-4.exe", and so on.

  In addition I have updated the upstream sources to version 4.3.2, which
should get us a few bug fixes for free.

  Finally, I have removed the controversial "-mno-cygwin" flag.  Cause of much
debate on the Cygwin mailing list, it is nevertheless the case that this flag
has never worked entirely correctly - some cygwin headers are still visible in
MinGW mode, which can lead to compilation errors.  For the moment, the
original gcc-3.4.4 package can be used to compile MinGW applications, but in
the near future I will make available a mingw-targeted gcc-4.3.2
cross-compiler.

  The to-do list for the first fully stable release currently stands at:

- - versioned cyggcc_s.dll
- - dlltool exe suffix (may be obsoleted by solution to above)
- - libjava
- - libgomp
- - cygport deforkification
- - shared fortran and objc libraries

  If there's anything else you think is important, please contact the Cygwin
mailing list with your suggestion.


gcc4-4.3.2-1
- --
This is a rapid refresh of the experimental GCC 4 package for Cygwin.

It can now fully co-exist with a pre-existing Cygwin gcc-3.4.4 installation.

If you installed the earlier package, please uninstall it and reinstall the
older gcc.

The same caveats apply as did to the earlier release:

"  Please be aware that this is highly experimental; anything
built with it is not guaranteed to be forwardly-compatible with the 
eventual full release.  ABI details may change; compiler packaging may
change.  "

In particular, it is likely that libgcc will be a versioned DLL in the
first stable release.

As this is highly experimental, please watch out for bugs.  Anything
abnormal should be reported, in the first instance, to the Cygwin
mailing list.


- --

Runtime requirements:
  cygwin-1.5.18 or newer.  (Probably works with older versions too).
  libgmp3, libmpfr1 - These may become statically linked in a future version.
  bash - Used for postinstall script.
  w32api - System headers and import libs.

Build requirements:
  cygwin-1.5.18 or newer.  (Again, probably works with older versions).
  gcc-3.4.4-1 or newer
  binutils-20050610-1 or newer
  Recent autotools, tar, make, awk, grep, perl, makeinfo, tetex, and
  probably some others, depending whether you modify the sources.
  Recent coreutils, findutils, diffutils.

Canonical homepage:
  http://gcc.gnu.org/

Canonical download:
  http://ftp.gnu.org/gnu/gcc/gcc-4.3.2/gcc-4.3.2.tar.bz2

License:
  GPL

Language:
  C (for the most part), various Perl, shell, etc. scripts during build.

- 

Build instructions:
  tar -xfvj gcc4-4.3.2-1-src.tar.bz2
  if you use setup to install this src package, it will be
 unpacked under /usr/src automatically

  cd /usr/src (if needed)
  or you can build in another directory if you unpacked there.

  ./gcc4-4.3.2-1-cygport.local gcc4-4.3.2-1 all
  unfortunately I've used a forked cygport script while
 testing this.  the stable release will rely only
 on the official cygport release.

This will create:
  ./gcc4-4.3.2-1.tar.bz2
  ./gcc4-runtime-4.3.2-1.tar.bz2
  ./gcc4-core-4.3.2-1.tar.bz2
  ./gcc4-g++-4.3.2-1.tar.bz2
  ./gcc4-java-4.3.2-1.tar.bz2
  ./gcc4-fortran-4.3.2-1.tar.bz2
  ./gcc4-objc-4.3.2-1.tar.bz2
  ./gcc4-ada-4.3.2-1.tar.bz2
  ./gcc4-4.3.2-1-src.tar.bz2

Or use '/gcc4-4.3.2-1-cygport.local gcc4-4.3.2-1 prep' to get a patched source
directory

To find out the files included in the binary distribution, you can
use "cygcheck -l gcc4", or browse the listing for the appropriate version
at .

- --

Port Notes:

- --  gcc4-4.3.2-1 -- 20080909 ---

Upstream sources updated to version 4.3.2.

"-mno-cygwin" option deleted.

Program-suffix set to "-4" for isolation from series 3 compiler.


- --  gcc4-4.3.0-1 -- 20080909 ---

Initial release.  Major new platform features:

 - Shared libgcc 
  (selectable by --shared-libgcc/--static-libgcc flag)
 - Dwarf-2 EH
  (no SjLj at all; if using EH and DLLs, --shared-libgcc is mandatory)

Plus all the GCC enhancements since series 3.

For more information about this package, see the upstream documentation in
/usr/share/doc/gcc4-4.3.0.

Cygwin port maintained by: Dave Korn
<[EMAIL PROTECTED]>
Please address all questions to the Cygwin mailing list at 

This is the key used for signing Cygwin GCC releases:

pub   1024D/6A388C3E 2008-05-

Re: undefined reference to '_cfmakeraw'

[Andrew Bouchard]

(1) Just to be sure, I went back and installed al of the cygwin  
packages available through the setup.exe file. It's still installing,  
and it looks like it will be for some time, but I already went through  
the list that I was able to find and made sure I had them all.


(2) I did run a './configure' before doing a make in the folder. I  
didn't see any errors, but I can't pretend that I know everything that  
it's doing during the configuration.


(3) Will send out all the output from the make when cygwin is done  
updating and I can try again.


(4) Sorry, you lost me on this one. I've heard of the grep command but  
never really used it, and there is a file that is just called  
configure (no extension) - is that what you are looking for?


(5) The Moast mailing list was the first place that I looked, but it  
seems that it hasn't been used since May 2007. I will try anyway, but  
I was thinking this was something with cygwin, which would make this  
the list most knowledgeable on how to fix it.


As for the question of programming skills, it's certainly a valid one.  
I can program competently in a few languages, but only within realms  
where I have needed to do so before. Basically, I know the things that  
I've needed to know and not the things I haven't. I've used SVN before  
so I understand what a diff file is and how it is used. However, it  
was all automated for me before, so I don't know how to apply one.  
Fortunately, programming logic, simple AIs, and behaviors all do fall  
under the realms of programming I am familiar with, so though I often  
ask for more install support than others, once I can get rolling I'm  
fine. I would also like to point out that things which may seem  
obvious and self-explanatory to an EE PhD student may not seem so  
clear to a humble Master's student with a stronger background in ME  
trying to grasp the system-level understanding of the interaction  
between mechanical, electrical, and software systems.


Thanks for the help, and I will provide more information as soon as I  
have it.


Andrew Bouchard

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

[1.7] bzr no work

[Andrew Schulman]

In Cygwin 1.7:

$ bzr whoami
Traceback (most recent call last):
  File "/usr/bin/bzr", line 64, in 
import bzrlib
  File "__init__.py", line 25, in 
  File "osutils.py", line 319, in 
  File "lazy_import.py", line 106, in __getattribute__
  File "lazy_import.py", line 89, in _replace
  File "lazy_import.py", line 193, in _import
  File "win32utils.py", line 56, in 
  File "/tmp/python.6884/usr/lib/python2.5/ctypes/__init__.py", line 431, in 
  File "/tmp/python.6884/usr/lib/python2.5/ctypes/__init__.py", line 340, in __i
nit__
OSError: No such file or directory


--
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: undefined reference to '_cfmakeraw'

[Christopher Faylor]

On Fri, Sep 12, 2008 at 12:49:47PM -0500, Andrew Bouchard wrote:
> undefined reference to '_cfmakeraw'

A google search implies that you probably need to install the
libncurses-devel package.

--
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: undefined reference to '_cfmakeraw'

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andrew Bouchard wrote:
> undefined reference to '_cfmakeraw'

cfmakeraw, while available on Linux glibc, is not available on Cygwin.
But the glibc manual tells us exactly what it does:

http://www.gnu.org/software/libc/manual/html_node/Noncanonical-Input.html

So just substitute the cfmakeraw call for the code shown there.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkjK1IcACgkQpiWmPGlmQSMlEACdGwuaoNMVIALmuJSryQTlHKYt
GlUAoKjHekrslNbgRWyGNPa6tlMaC1P8
=ySuV
-END PGP SIGNATURE-

--
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 experimental package: gcc4-4.3.0-1

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dave Korn wrote:
>   OK.  Suits me.

While you're at it, I would override LIBINTL and LIBICONV with their
dynamic counterparts.

>   The problem is the major difference between ELF DSOs and PE DLLS: DLLs have
> to be fully resolved at link-time, not load-time.  So, when you're building
> libstdc++ all those internal references to operator new have to be resolved
> somewhere, and as the weakref is the only definition available that's where
> they get linked to.  Permanently and forever.
> 
>   If they were instead resolved to some kind of thunk that could do a lookup
> at runtime for non-weak versions of the same symbol, we'd be golden.  Well,
> we'd need to make sure the non-weak versions were all declspecced dllexport
> somehow, but that would do it for us.

FWIW, this doesn't just affect C++; linking XWin against a dynamic
libXfont has the same problem, causing the former not to work, and hence
requires a static link.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkjK3FQACgkQpiWmPGlmQSM+KwCgutTD0WG53ZeGxT+AN8YPXtsm
tOwAnixQMnvtOpauNiFuFe7F6YrMQ38p
=tSNx
-END PGP SIGNATURE-

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

[Jason Pyeron]

 
> Dear Sir/Medam;
>  I am deeply interested in 
> implementing a simple command interpreter in Windows XP 
> platform as a part of my summer project, so will you please 
> give me some hint on implementing it.

Isn't summer over?

You might find it well suited to ask your computer science department for a
tutor to help you in your class work.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.


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

inetutils 1.5-4, ftp + inline password immediately quits

[Robinson, Paul T (NonStop)]

I have a pile of bash scripts with variations on this theme:

ftp -n ${HOST} < SYST
215 Nonstop H-series Server : H06.15.
Remote system type is Nonstop.
user 
---> USER 
331 Password required for .
Password:
---> PASS 
230 User  logged in.  GUARDIAN API enabled
---> QUIT
221 Goodbye.

So, it successfully logged in, but then immediately QUIT.
If I put ${PASSWORD} up on the 'user' command line, it continues
on to the 'cd' and 'get' with no problem.

Thanks,
--paulr



Cygwin Configuration Diagnostics
Current System Time: Fri Sep 12 14:31:14 2008

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Running in Terminal Service session

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\Perl\bin\
c:\mksnt\bin
c:\mksnt\bin\X11
c:\mksnt\mksnt
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\ActivCard\ActivCard Gold\resources
c:\Program Files\Java\jre1.6.0_06\bin
c:\Rational\ClearCase\bin
c:\Rational\common
.
c:\DWF\bin
c:\YoDev\Path

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 87996(ptr)   GID: 10545(mkgroup-l-d)
0(root)   544(Administrators)   555(Remote Desktop Users)
545(Users)10545(mkgroup-l-d)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 87996(ptr)   GID: 10545(mkgroup-l-d)
0(root)   544(Administrators)   555(Remote Desktop Users)
545(Users)10545(mkgroup-l-d)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

PWD = '/var/log'
HOME = '/cygdrive/c/Documents and Settings/PaulRobinson'
MAKE_MODE = 'unix'

MAN_TXT_INDEX = 
'C:/mksnt/etc/tkutil.idx;C:/mksnt/etc/tkapi.idx;C:/mksnt/etc/tcltk.idx;C:/mksnt/etc/tkcurses.idx'
HOMEPATH = '\Documents and Settings\PaulRobinson'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man:'
APPDATA = 'C:\Documents and Settings\PaulRobinson\Application Data'
HOSTNAME = 'PAULROBINSON-EV'
VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 
2003\Common7\Tools\'
ENVSDK_REGKEY = '7.0;7.1'
TERM = 'nutc'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 1 Stepping 2, GenuineIntel'
MAN_CHM_INDEX = 
'C:/mksnt/etc/chm/tkutil.idx;C:/mksnt/etc/chm/tkapi.idx;C:/mksnt/etc/chm/tcltk.idx;C:/mksnt/etc/chm/tkcurses.idx'
HPSIGNPROJ = 'PaulTRobinson'
WINDIR = 'C:\WINDOWS'
TMPDIR = '/cygdrive/c/DOCUME~1/PAULRO~1/LOCALS~1/Temp'
OLDPWD = '/var'
USERDOMAIN = 'AMERICAS'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
MSVCVER = '6.00'
TEMP = '/cygdrive/c/DOCUME~1/PAULRO~1/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
ROOTDIR = 'C:/mksnt'
TERMCAP = 'C:\mksnt\etc\termcap'
USERNAME = 'ptr'
PROCESSOR_LEVEL = '15'
MAN_HTM_PATHS = 
'C:/mksnt/etc/htm/perl;C:/mksnt/etc/htm/perl/pod;C:/mksnt/etc/htm/perl/ext;C:/mksnt/etc/htm/perl/lib'
NUTCROOT = 'C:\mksnt'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
USERPROFILE = 'C:\Documents and Settings\PaulRobinson'
CLIENTNAME = 'Console'
AGENTMONSERVICE = '5402'
PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\G6W0024'
HPSIGNDIR = 'C:\Program Files\Hewlett-Packard\HPCSS\HPCSS\HPSignClient1.1'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\cygwin\bin'
SHLVL = '1'
TERMINFO = 'C:\mksnt\usr\lib\terminfo'
PATHEXT = 
'.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.sh;.ksh;.csh;.sed;.awk;.pl'
HOMEDRIVE = 'C:'
PROMPT = '$P$G'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/cygdrive/c/DOCUME~1/PAULRO~1/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
PRINTER = 'Microsoft Office Document Image Writer'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '0102'
TDMROOTDIR = 'C:\DWF'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
DISPLAY = ':0.0'
NUMBER_OF_PROCESSORS = '1'
SESSIONNAME = 'RDP-Tcp#1'
TDMUSERFILE = 'c:\dwf\users\.netrc'
COMPUTERNAME = 'PAULROBINSON-EV'
SONICCENTRAL = 'C:\Program Files\Common Files\Sonic Shared\Sonic Central\'
_ = '/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x0020
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x0020
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'C:\cygwin'
  flags = 0x0008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 'C:\cygwin/bin'
  flags = 0x0008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = 'C:\cygwin/lib'
  flags = 0x0008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  

Re: undefined reference to '_cfmakeraw'

[Christopher Faylor]

On Fri, Sep 12, 2008 at 04:37:19PM -0400, Christopher Faylor wrote:
>On Fri, Sep 12, 2008 at 12:49:47PM -0500, Andrew Bouchard wrote:
>> undefined reference to '_cfmakeraw'
>
>A google search implies that you probably need to install the
>libncurses-devel package.

Actually, I should have known much better than that.  As Yaakov
correctly points out, this has nothing to do with ncurses.  It just
isn't implemented in Cygwin.  I'll add it to Cygwin 1.7 but I wouldn't
suggest that you try a cutting-edge version of Cygwin just for this.
The code in the first hit off of google should provide what you need to
add this to the code that needs it.

cgf

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

DBD::Pg-2.10.3 make error under cygwin

[mouse]

  I am looking for assistance or tips with a make error from DBD::PG

  Running Windows XPSP3 with the latest cygwin install base

  I've added the cygwin packages;
Postgresql 8.2.9-1
postgresql-client 8.2.9-1
postgresql-devel 8.2.9-1
libpq5 8.2.9-1

  I've compiled
DBI-1.607

$ perl Makefile.PL
Configuring DBD::Pg 2.10.3
PostgreSQL version: 80209 (default port: 5432)
POSTGRES_HOME: (not set)
POSTGRES_INCLUDE: /usr/include
POSTGRES_LIB: /lib
OS: cygwin
Checking if your kit is complete...
Looks good
Using DBI 1.607 (for perl 5.01 on cygwin-thread-multi-64int) installed in /u
sr/lib/perl5/site_perl/5.10/i686-cygwin/auto/DBI/
Writing Makefile for DBD::Pg

$ make
cp lib/Bundle/DBD/Pg.pm blib/lib/Bundle/DBD/Pg.pm
cp Pg.pm blib/lib/DBD/Pg.pm
/usr/bin/perl.exe -p -e "s/~DRIVER~/Pg/g; s/^do\(/dontdo\(/" /usr/lib/perl5/site
_perl/5.10/i686-cygwin/auto/DBI/Driver.xst > Pg.xsi
/usr/bin/perl.exe /usr/lib/perl5/5.10/ExtUtils/xsubpp  -typemap /usr/lib/perl5/5
.10/ExtUtils/typemap  Pg.xs > Pg.xsc && mv Pg.xsc Pg.c
gcc -c  -I/usr/include -I/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/DBI -DPE
RL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -I/usr/local/inc
lude -DPGLIBVERSION=80209 -DPGDEFPORT=5432 -DUSEIMPORTLIB -O3   -DVERSION=\"2.10
.3\" -DXS_VERSION=\"2.10.3\"  "-I/usr/lib/perl5/5.10/i686-cygwin/CORE"   Pg.c
gcc -c  -I/usr/include -I/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/DBI -DPE
RL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -I/usr/local/inc
lude -DPGLIBVERSION=80209 -DPGDEFPORT=5432 -DUSEIMPORTLIB -O3   -DVERSION=\"2.10
.3\" -DXS_VERSION=\"2.10.3\"  "-I/usr/lib/perl5/5.10/i686-cygwin/CORE"   dbdimp.
c
gcc -c  -I/usr/include -I/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/DBI -DPE
RL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -I/usr/local/inc
lude -DPGLIBVERSION=80209 -DPGDEFPORT=5432 -DUSEIMPORTLIB -O3   -DVERSION=\"2.10
.3\" -DXS_VERSION=\"2.10.3\"  "-I/usr/lib/perl5/5.10/i686-cygwin/CORE"   quote.c

gcc -c  -I/usr/include -I/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/DBI -DPE
RL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -I/usr/local/inc
lude -DPGLIBVERSION=80209 -DPGDEFPORT=5432 -DUSEIMPORTLIB -O3   -DVERSION=\"2.10
.3\" -DXS_VERSION=\"2.10.3\"  "-I/usr/lib/perl5/5.10/i686-cygwin/CORE"   types.c

rm -f blib/arch/auto/DBD/Pg/Pg.dll
g++  --shared  -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,838
8608 -Wl,--enable-auto-image-base -L/usr/local/lib Pg.o dbdimp.o quote.o types.o
  -o blib/arch/auto/DBD/Pg/Pg.dll   \
  /usr/lib/perl5/5.10/i686-cygwin/CORE/libperl.dll.a -L/lib -lpq  \

chmod 755 blib/arch/auto/DBD/Pg/Pg.dll
test -s Pg.bs && cp Pg.bs blib/arch/auto/DBD/Pg/Pg.bs && \
  chmod 644 blib/arch/auto/DBD/Pg/Pg.bs
make: [blib/arch/auto/DBD/Pg/Pg.dll] Error 1 (ignored)





--
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 experimental package: gcc4-4.3.0-1

[Brian Dessent]

Dave Korn wrote:

>   If they were instead resolved to some kind of thunk that could do a lookup
> at runtime for non-weak versions of the same symbol, we'd be golden.  Well,
> we'd need to make sure the non-weak versions were all declspecced dllexport
> somehow, but that would do it for us.

Well we already have this problem with the Cygwin DLL and standard
malloc().  It's solved in
lib/_cygwin_crt0_common.cc:_cygwin_crt0_common().  This code gets
statically linked into every executable, which means when it takes the
address of malloc and free that address will bind to the user's
overrided function if present, otherwise it will import it from the
DLL.  I think we can extend this for operator new and delete.

The only issue is the addresses are stored in an internal Cygwin data
structure (struct per_process) which will not be accessible from within
libstdc++.  You could add helper functions that retrieve them, but that
seems like additional overhead.  You could also just store them in
variables that are exported by the DLL.  Then you'd just need something
in libstdc++ that wraps all calls to new/delete through the addresses
imported from those variables.  Or, how about this: you could just have
the Cygwin DLL export the wrapper functions as themselves, i.e. with the
proper mangled names.  Then building libstdc++ as a DLL would always
bind new/delete to those wrappers with no extra modification to the
libstdc++ sources.

Brian

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

RE: inetutils 1.5-4, ftp + inline password immediately quits

[Gary R. Van Sickle]

> From: Robinson, Paul T (NonStop)
> 
> I have a pile of bash scripts with variations on this theme:
> 
> ftp -n ${HOST} <  user ${USER}
>  ${PASSWORD}
>  cd ${MYDIR}
>  get ${MYFILE}
>  bye
> FTP_EOF
> 

Helpful hint: to reduce your overall hassle level, use ncftp of wget for
doing this sort of thing, and don't look back.  That will allow you to put
all of those params on the command line.  Both programs work great on
Cygwin.

-- 
Gary R. Van Sickle


--
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: inetutils 1.5-4, ftp + inline password immediately quits

[Andrew DeFaria]

Gary R. Van Sickle wrote:

From: Robinson, Paul T (NonStop)

I have a pile of bash scripts with variations on this theme:

ftp -n ${HOST} 
If there is a god, he will understand why I don't believe in him.


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