headers
Brian Kasper | 1 Dec 2006 01:07

Re: "Connection closed by [host]" when ssh to Cygwin sshd

Thanks, the lack of the sshd_server user was the problem -- it's 
possible I deleted it accidentally after running ssh-host-config, though 
  I *thought* I deleted that user and then ran the script, but I was 
never asked if I wanted to create the user.  Hmm ....

Anyway, thanks for the help.  Much obliged.

-B

burning shadow wrote:
> Uninstall sshd service using `cygrunsrvd -R sshd` then install it
> using ssh-host-config and allow script to create sshd_server user when
> it will ask for it. It will help.
> 
[snip]
Permalink | Reply | 0 comments |
headers
Bob Rossi | 1 Dec 2006 01:16
Picon

Re: autoconf

On Thu, Nov 30, 2006 at 05:04:08PM -0500, Bob Rossi wrote:
> Hi,
> 
> I'm using autoconf. I notice when I use things like
> AC_CHECK_SIZEOF (int)
> that the ac_cv_sizeof_int has the value of "4\r".

I narrowed it down further. It's AC_CHECKS_SIZEOF that does
  acgeneral.m4:  fprintf(f, "%d\n", sizeof($1));
which because I'm passing -mno-cygwin, get's a "4\r\n" in a file. (if
the size is 4)
Then it does
  AC_CV_NAME=`cat conftestval`, ...
That cat is the cygwin cat, so it puts out "4\r", which is incorrect.

Do I have to get a cat that's been built with mingw? When I try to
modify /usr/local/share/autoconf/acgeneral.m4 to do
  AC_CV_NAME=`dos2unix conftestval; cat conftestval`, ...
and then run autoconf, autoconf doesn't pick up the changes.

Is this possible to make autoconf do?

Thanks,
Bob Rossi
Permalink | Reply | 0 comments |
headers
Bob Rossi | 1 Dec 2006 01:25
Picon

Re: autoconf

On Thu, Nov 30, 2006 at 06:45:10PM -0500, Larry Hall (Cygwin) wrote:
> Bob Rossi wrote:
> >Hi,
> >
> >I'm using autoconf. I notice when I use things like
> >AC_CHECK_SIZEOF (int)
> >that the ac_cv_sizeof_int has the value of "4\r".
> >
> >There is an extra carriage return in there. I start my configure
> >script with
> >  ./configure --build=mingw32
> >could that be the problem?
> >
> >Is there any solution to having these macro's work correctly on cygwin?
> >or did I break it by using the --build option? BTW, I can't test it
> >without the --build option because the configure script doesn't even get
> >that far otherwise, since this is a mingw package (sort of).
> 
> 
> Sounds to me like the file you're feeding to autoconf has DOS line endings 
> in
> it.

Yes, this is correct. The AC_CHECK_SIZEOF macro does not work with
-mno-cygwin unless there is a cygwin version of 'cat' on the path.

Is there a standard way to resolve this problem?

Thanks,
Bob Rossi
(Continue reading)

Permalink | Reply | 7 comments |
headers
kramer27 | 1 Dec 2006 03:10
Picon
Favicon

Rsync error


Hi.  I'm running cygwin on a win XP laptop and would like to back up my files
on my Linux box.  So naturally I did this:
$ rsync --rsh=ssh --update --recursive --verbose .
root <at> 192.168.2.4::/mnt/5/foo
ERROR: The remote path must start with a module name
rsync error: error starting client-server protocol (code 5) at
/home/lapo/packag
ing/tmp/rsync-2.6.6/main.c(1171)

kramer <at> QuantIQ /cygdrive/c/Documents and Settings/kramer/My Documents/My
Music/i
Tunes/foo
$ root <at> 192.168.2.4's password:
Permission denied, please try again.
root <at> 192.168.2.4's password:
Permission denied, please try again.
root <at> 192.168.2.4's password:
Permission denied (publickey,password,keyboard-interactive).

Then I realized that I need to specify a module.  I've looked through the
rsync man page and can't figure out what the heck a 'module' is supposed to
mean.  I did find that 

$rsync hostname:: 

is supposed to list all of the modules on that server, but I ran that
command and it gave nothing.

I do have an rsync daemon started on my Linux box just in case you were
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Korn | 1 Dec 2006 03:31
Favicon

RE: Accessing ram drive as raw disk volume fails?

On 30 November 2006 19:56, Igor Peshansky wrote:

> On Thu, 30 Nov 2006, Dave Korn wrote:
> 
>>     Hi all,
>> 
>>   I'm trying to use dd to dump stuff to a usb flash drive (i.e. mass
>> storage device).  However something tricks it into thinking the device
>> is full (/dev/sdb is the pendrive):
>> 
>> dk <at> CHILLI ~
>> $ dd if=/tmp/msd-test-data.cXoEqa2332 of=/dev/sdb bs=100 count=1
>> dd: writing `/dev/sdb': No space left on device
>> 1+0 records in
>> 0+0 records out
>> 
>> dk <at> CHILLI ~
>> $

> strace or gdb should be helpful in identifying the Windows error code that
> is mapped by Cygwin to ENOSPC.  From a quick look at the code, this could
> be a general write error, but I haven't spent all that much time looking
> at it.

  It was.  The strace showed:

   91   15071 [main] dd 3468 fhandler_base::read: returning 100, binary mode
   29   15100 [main] dd 3468 readv: 100 = readv (0, 0x22EE30, 1), errno 0
   31   15131 [main] dd 3468 writev: writev (1, 0x22EE20, 1)
   29   15160 [main] dd 3468 fhandler_base::write: binary write
(Continue reading)

Permalink | Reply | 1 comment |
headers
djh | 1 Dec 2006 03:32
Picon

Re: GPGME 1.0.3 Build Problem


Thanks for your repsonse Marcus.

> From: Marcus Brinkmann (GPGME member)

> From: Henman: I have run into a build problem on cygwin system.
> > 
> > 
> > I am not an expert in the utilities used to build gpgme.  But, wonder why a library seems to be missing.  Could
this be a command line argument ordering problem??
> 
> It seems libtool doesn't support your target architecture well enough
> for GPGME to build.

libtool has been cygwin aware for several years and I've had no problems with it building many shared
libraries.  (Except for example, GMP in which they assumed possibly too much in libtool and was forced to
explicity use CPPFLAGS="-DDLL_EXPORT"

I can envision where something like that can be cause of non-portability in the gpgme building code.

#
# GPGME Make problem (November 30, 2006):  (see below)
#
(cd .libs && rm -f libgpgme.la && ln -s ../libgpgme.la libgpgme.la)
if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..      -g -O2 -Wall
-Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF ".deps/ath-pthread.Tpo"
-c -o ath-pthread.lo ath-pthread.c; \
        then mv -f ".deps/ath-pthread.Tpo" ".deps/ath-pthread.Plo"; else rm -f ".deps/ath-pthread.Tpo";
exit 1; fi
 gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larry Hall (Cygwin | 1 Dec 2006 03:45
Favicon

Re: autoconf

Bob Rossi wrote:
> On Thu, Nov 30, 2006 at 06:45:10PM -0500, Larry Hall (Cygwin) wrote:
>> Bob Rossi wrote:
>>> Hi,
>>>
>>> I'm using autoconf. I notice when I use things like
>>> AC_CHECK_SIZEOF (int)
>>> that the ac_cv_sizeof_int has the value of "4\r".
>>>
>>> There is an extra carriage return in there. I start my configure
>>> script with
>>>  ./configure --build=mingw32
>>> could that be the problem?
>>>
>>> Is there any solution to having these macro's work correctly on cygwin?
>>> or did I break it by using the --build option? BTW, I can't test it
>>> without the --build option because the configure script doesn't even get
>>> that far otherwise, since this is a mingw package (sort of).
>>
>> Sounds to me like the file you're feeding to autoconf has DOS line endings 
>> in
>> it.
> 
> Yes, this is correct. The AC_CHECK_SIZEOF macro does not work with
> -mno-cygwin unless there is a cygwin version of 'cat' on the path.
> 
> Is there a standard way to resolve this problem?

I'm not sure.  I'm assuming not using '-mno-cygwin' is not an option?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bob Rossi | 1 Dec 2006 04:03
Picon

Re: autoconf

On Thu, Nov 30, 2006 at 09:45:21PM -0500, Larry Hall (Cygwin) wrote:
> Bob Rossi wrote:
> >On Thu, Nov 30, 2006 at 06:45:10PM -0500, Larry Hall (Cygwin) wrote:
> >>Bob Rossi wrote:
> >>>Hi,
> >>>
> >>>I'm using autoconf. I notice when I use things like
> >>>AC_CHECK_SIZEOF (int)
> >>>that the ac_cv_sizeof_int has the value of "4\r".
> >>>
> >>>There is an extra carriage return in there. I start my configure
> >>>script with
> >>> ./configure --build=mingw32
> >>>could that be the problem?
> >>>
> >>>Is there any solution to having these macro's work correctly on cygwin?
> >>>or did I break it by using the --build option? BTW, I can't test it
> >>>without the --build option because the configure script doesn't even get
> >>>that far otherwise, since this is a mingw package (sort of).
> >>
> >>Sounds to me like the file you're feeding to autoconf has DOS line 
> >>endings in
> >>it.
> >
> >Yes, this is correct. The AC_CHECK_SIZEOF macro does not work with
> >-mno-cygwin unless there is a cygwin version of 'cat' on the path.
> >
> >Is there a standard way to resolve this problem?
> 
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Larry Hall (Cygwin | 1 Dec 2006 04:11
Favicon

Re: autoconf

Bob Rossi wrote:
> On Thu, Nov 30, 2006 at 09:45:21PM -0500, Larry Hall (Cygwin) wrote:
>> Bob Rossi wrote:
>>> On Thu, Nov 30, 2006 at 06:45:10PM -0500, Larry Hall (Cygwin) wrote:
>>>> Bob Rossi wrote:
>>>>> Hi,
>>>>>
>>>>> I'm using autoconf. I notice when I use things like
>>>>> AC_CHECK_SIZEOF (int)
>>>>> that the ac_cv_sizeof_int has the value of "4\r".
>>>>>
>>>>> There is an extra carriage return in there. I start my configure
>>>>> script with
>>>>> ./configure --build=mingw32
>>>>> could that be the problem?
>>>>>
>>>>> Is there any solution to having these macro's work correctly on cygwin?
>>>>> or did I break it by using the --build option? BTW, I can't test it
>>>>> without the --build option because the configure script doesn't even get
>>>>> that far otherwise, since this is a mingw package (sort of).
>>>> Sounds to me like the file you're feeding to autoconf has DOS line 
>>>> endings in
>>>> it.
>>> Yes, this is correct. The AC_CHECK_SIZEOF macro does not work with
>>> -mno-cygwin unless there is a cygwin version of 'cat' on the path.
>>>
>>> Is there a standard way to resolve this problem?
>>
>> I'm not sure.  I'm assuming not using '-mno-cygwin' is not an option?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 1 Dec 2006 04:24
Picon
Favicon

Re: GPGME 1.0.3 Build Problem

At Fri, 01 Dec 2006 11:32:35 +0900,
"djh" <henman <at> it.to-be.co.jp> wrote:
> 
> libtool has been cygwin aware for several years and I've had no problems with it building many shared
libraries.  (Except for example, GMP in which they assumed possibly too much in libtool and was forced to
explicity use CPPFLAGS="-DDLL_EXPORT"

Shared library support various dramatically across platforms.  Libtool
tries its best to patch it up and give a consistent picture, but it
can not always provide.

GPGME does some funny things with libraries to support multiple thread
libraries.  Read on.

> I can envision where something like that can be cause of
> non-portability in the gpgme building code.

I gave it another look, and it seems to me that the problem could be
the following: GPGME tries to build versions of GPGME linking against
pthread and pth.  These versions are built from a version of the
library without any thread support (libgpgme-real.la), which is not
installed.  This non-installed library has undefined symbols, btw, but
it seems that libtool does not hickup over those (possibly because
it's not installed), or you didn't give us the warning message for
that case.

Then, GPGME builds the final library from the thread module, adding
the non-installed libgpgme-real.la to the bundle via LIBADD.

Ok, that's not really clean.  The problem is that now the order is
(Continue reading)

Permalink | Reply | 0 comments |

Gmane