Date: Mon, 8 Nov 2004 00:04:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
Subject: [UnixOS2_Archive] No. 441

**************************************************
Sunday 07 November 2004
 Number  441
**************************************************

Subjects for today
 
1   cygpath : John Poltorak <jp at warpix.org>
2  Re:  cygpath : Michael.Holzapfel at t-online.de (Michael.Holzapfel at t-online.de)
3  Re:  cygpath : Andreas Buening <andreas.buening at nexgo.de>
4  Re:  cygpath : John Poltorak <jp at warpix.org>
5  Re:  emx select() with new handles : Stefan.Neis at t-online.de
6  Re:  emx select() with new handles : Sebastian Wittmeier" <Sebastian.Wittmeier at ginko.de>
7  Re:  IMAPD : Nicholas Sheppard <nps at zeta.org.au>
8  Re:  IMAPD : John Poltorak <jp at warpix.org>


**= Email   1 ==========================**

Date:  Sat, 6 Nov 2004 19:09:01 +0000
From:  John Poltorak <jp at warpix.org>
Subject:   cygpath


For some reason I am getting the inclusion of 'cygpath' in a Makefile for 
diffutils v2.8.1. It's in the lib directory which has this section in the 
Makefile:-


..c.o:
    source='$<' object='$ at ' libtool=no \
    depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \
    $(CCDEPMODE) $(depcomp) \
    $(COMPILE) -c `test -f $< || echo '$(srcdir)/'`$<

..c.obj:
    source='$<' object='$ at ' libtool=no \
    depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \
    $(CCDEPMODE) $(depcomp) \
    $(COMPILE) -c `cygpath -w $<`
CCDEPMODE = depmode=gcc
uninstall-info-am:


Since I don't have a cygpath, Make fails at this point. Any suggestion as 
to what I can do about it? cygpath appears in Makefile.in, so I guess I 
should try and run automake before running configure. Does that sound 
reasonable?

-- 
John



**= Email   2 ==========================**

Date:  Sat, 06 Nov 2004 21:22:51 +0100
From:  Michael.Holzapfel at t-online.de (Michael.Holzapfel at t-online.de)
Subject:  Re:  cygpath

John Poltorak schrieb:

>For some reason I am getting the inclusion of 'cygpath' in a Makefile for 
>diffutils v2.8.1. It's in the lib directory which has this section in the 
>Makefile:-
>
>
>.c.o:
>    source='$<' object='$ at ' libtool=no \
>    depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \
>    $(CCDEPMODE) $(depcomp) \
>    $(COMPILE) -c `test -f $< || echo '$(srcdir)/'`$<
>
>.c.obj:
>    source='$<' object='$ at ' libtool=no \
>    depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \
>    $(CCDEPMODE) $(depcomp) \
>    $(COMPILE) -c `cygpath -w $<`
>CCDEPMODE = depmode=gcc
>uninstall-info-am:
>
>
>Since I don't have a cygpath, Make fails at this point. Any suggestion as 
>to what I can do about it? cygpath appears in Makefile.in, so I guess I 
>should try and run automake before running configure. Does that sound 
>reasonable?
>
>  
>
....hm obviously autoconf has detected an cygnus-win32 environment.

Michael


**= Email   3 ==========================**

Date:  Sat, 06 Nov 2004 22:52:27 +0100
From:  Andreas Buening <andreas.buening at nexgo.de>
Subject:  Re:  cygpath

John Poltorak wrote:

> Since I don't have a cygpath, Make fails at this point. Any suggestion as
> to what I can do about it? cygpath appears in Makefile.in, so I guess I
> should try and run automake before running configure. Does that sound
> reasonable?

Yes. cygpath is used by an old automake version.


Bye,
Andreas


**= Email   4 ==========================**

Date:  Sat, 6 Nov 2004 21:28:47 +0000
From:  John Poltorak <jp at warpix.org>
Subject:  Re:  cygpath

On Sat, Nov 06, 2004 at 10:52:27PM +0100, Andreas Buening wrote:
> John Poltorak wrote:
> 
> > Since I don't have a cygpath, Make fails at this point. Any suggestion as
> > to what I can do about it? cygpath appears in Makefile.in, so I guess I
> > should try and run automake before running configure. Does that sound
> > reasonable?
> 
> Yes. cygpath is used by an old automake version.

The only reference I can find to cygpath is in depcomp at it looks to be 
still in place in automake 1.8.

To recreate the Makefile.in's I ran these commands:-

aclocal
automake --add-missing --force-missing
autoconf
autoheader

Is this correct?

Among the msgs were:-


u:/ux2bs/workdir/diffutils-2.8.1
diffutils-2.8.1
aclocal: configure.ac: 64: macro `AM_GNU_GETTEXT' not found in library
configure.ac:27: version mismatch.  This is Automake 1.8.4,
configure.ac:27: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:27: comes from Automake 1.6.  You should recreate
configure.ac:27: aclocal.m4 with aclocal and run automake again.
/usr/local/share/automake-1.8/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
/usr/local/share/automake-1.8/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
../configure --prefix=${UXRT}/usr



**= Email   5 ==========================**

Date:  Sat, 6 Nov 2004 23:55:49 +0100
From:  Stefan.Neis at t-online.de
Subject:  Re:  emx select() with new handles

Addressed to: os2-unix at mail.warpix.org
              "xfreeos2 at xfreeos2.dyndns.org" <xfreeos2 at xfreeos2.dyndns.org>

        Hi,

> Has anybody compiled XFree86/2 with Innotek GCC yet? And Encountered
> the same incompatibilities?

Actually, I tried compiling XFree86 4.4.0 and the build process crashed
right in it's first call to the freshly compiled xmkmf, same as sombody
reported for the other branch of X developpment.
Since there's no working gdb for Innotek's compiler, that's where
I have to stop all efforts... :-(

        Regards,
	        Stefan	





**= Email   6 ==========================**

Date:  Sun, 07 Nov 2004 01:39:05 +0100 (CET)
From:  "Sebastian Wittmeier" <Sebastian.Wittmeier at ginko.de>
Subject:  Re:  emx select() with new handles

On Sat, 6 Nov 2004 20:26:11 +1100 (EST), Andrew MacIntyre wrote:

>ISTM the EMX _imphandle() and _impsockhandle() routines are intended for
>dealing with these sorts of issues.

Thank you! That will help ...
So I will use emx AND libc at the same time. Are there any problems to
expect?
I would create another support DLL that imports EMX _imphandle() and
calls it with the handle returned by Innotek open().

Sebastian




**= Email   7 ==========================**

Date:  Sun, 7 Nov 2004 19:51:01 +0000 (GMT)
From:  Nicholas Sheppard <nps at zeta.org.au>
Subject:  Re:  IMAPD

I tested this with the port of BSD inetd and I think the problem is that
BSD inetd cannot launch scripts directly. My initial inetd.cnf had:

   imap    stream tcp nowait root   d:\programs\imapd\imapd.cmd %s

But when I did `telnet localhost 143', it hung. I changed the above
line to

   imap    stream tcp nowait root   cmd /c d:\programs\imapd\imapd.cmd %s

(i.e. added "cmd /c") and it then ran fine.

On my machine I am mostly using the inetd shipped with OS/2, which seems
to be able to launch scripts by itself. For this inetd I just have

   imap2 tcp d:\programs\imapd\imapd.cmd

and that seems to work okay.

CRAM-MD5 authentication doesn't seem to be working in my current 
configuration but I'm sure I've had it working before. Plain 
authentication is working fine. I will look more deeply into it.

 	Nicholas S.


**= Email   8 ==========================**

Date:  Sun, 7 Nov 2004 12:33:09 +0000
From:  John Poltorak <jp at warpix.org>
Subject:  Re:  IMAPD

On Sun, Nov 07, 2004 at 07:51:01PM +0000, Nicholas Sheppard wrote:
> I tested this with the port of BSD inetd and I think the problem is that
> BSD inetd cannot launch scripts directly. My initial inetd.cnf had:
> 
>    imap    stream tcp nowait root   d:\programs\imapd\imapd.cmd %s
> 
> But when I did `telnet localhost 143', it hung. I changed the above
> line to
> 
>    imap    stream tcp nowait root   cmd /c d:\programs\imapd\imapd.cmd %s
> 
> (i.e. added "cmd /c") and it then ran fine.

I have this:-

imap    stream tcp nowait root   cmd /c c:\usr\proclib\imapd.cmd %s

which is more or less identical. It does launch imapd.exe but it does take 
around a minute to come up for some reason. I don't know why. The same 
happens with ipop3d.exe. By way of contrast a different port of a 
different codebase comes up instantly, although the socket handle is 
passed directly rather than via the environment, 
 
> On my machine I am mostly using the inetd shipped with OS/2, which seems
> to be able to launch scripts by itself. For this inetd I just have
> 
>    imap2 tcp d:\programs\imapd\imapd.cmd
> 
> and that seems to work okay.
> 
> CRAM-MD5 authentication doesn't seem to be working in my current 
> configuration but I'm sure I've had it working before. Plain 
> authentication is working fine. I will look more deeply into it.

Currently I can't get any sort of authentication working which is a big 
stumbling block. I'tested userids and password local and they are fine but 
they seem to get messed up when being used through telnet. Maybe 
encryption is messing things up. Can I use a userid with no password just 
for testing?


 
>  	Nicholas S.


-- 
John