From: UnixOS2 Archive
To: "UnixOS2 Archive" <UnixOS2_Archive at unixos2.com>
Date: Tue, 7 Oct 2003 14:13:44 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
Subject: [UnixOS2_Archive] No. 208

**************************************************
Monday 06 October 2003
 Number  208
**************************************************

Subjects for today
 
1   FIND and redirection : John Poltorak <jp at warpix.org>
2  Re:  FIND and redirection : DoC <slaughter at malaconet.org>
3  Re:  FIND and redirection : John Poltorak <jp at warpix.org>
4  Re:  Innotek LIBC and glinks : Dave and Natalie" <dave_yeo at mindlink.bc.ca>

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

Date:  Tue, 7 Oct 2003 10:02:43 +0100
From:  John Poltorak <jp at warpix.org>
Subject:   FIND and redirection

Is there any trick to using redirection with Unix FIND when invoking 
'-exec' ?

I would like to run bogofilter on some specific files, and the normal 
command line would be:-

bogofilter <spammsg

but I can't get this to work using;-


find . -name spammsg -exec bogofilter <{} ;


Any suggestions?



-- 
John



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

Date:  Tue, 07 Oct 2003 11:48:43 -0300
From:  DoC <slaughter at malaconet.org>
Subject:  Re:  FIND and redirection

John Poltorak escreveu:

>Is there any trick to using redirection with Unix FIND when invoking 
>'-exec' ?
>
>I would like to run bogofilter on some specific files, and the normal 
>command line would be:-
>
>bogofilter <spammsg
>
>but I can't get this to work using;-
>
>
>find . -name spammsg -exec bogofilter <{} ;
>
>
>Any suggestions?
>
>
>
>  
>
Perhaps it's interpreting the "<" sign incorrectly?

Did you try:
find . -name spammsg -exec "bogofilter < {}" \;

-- Erico



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

Date:  Tue, 7 Oct 2003 16:23:09 +0100
From:  John Poltorak <jp at warpix.org>
Subject:  Re:  FIND and redirection

On Tue, Oct 07, 2003 at 11:48:43AM -0300, DoC wrote:
> John Poltorak escreveu:
> 
> >Is there any trick to using redirection with Unix FIND when invoking 
> >'-exec' ?
> >
> >I would like to run bogofilter on some specific files, and the normal 
> >command line would be:-
> >
> >bogofilter <spammsg
> >
> >but I can't get this to work using;-
> >
> >
> >find . -name spammsg -exec bogofilter <{} ;
> >
> >
> >Any suggestions?
> >
> >
> >
> >  
> >
> Perhaps it's interpreting the "<" sign incorrectly?
> 
> Did you try:
> find . -name spammsg -exec "bogofilter < {}" \;

AFAIU the '<' is command operator but it does not apply when using '-exec'.

I have managed to get it working like this:-

find  . -name spammsg -exec sh -c "bogofilter -v < $1 " {}  {} ; -exec rm {} ;


but don't ask me to explain it :-)...
 
> -- Erico
> 
> 


-- 
John


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

Date:  Tue, 07 Oct 2003 19:24:25 -0800
From:  "Dave and Natalie" <dave_yeo at mindlink.bc.ca>
Subject:  Re:  Innotek LIBC and glinks

Sorry for taking so long to reply but I've been working a lot and had a shortage of time for playing with this.

On Wed, 24 Sep 2003 02:38:39 +0200, Knut St. Osmundsen wrote:

>Dave and Natalie wrote:
>> On Fri, 19 Sep 2003 16:05:23 +0100, Knut St. Osmundsen wrote:
>> 
>> 
>>> Now, have anyone actually tried GCC/LIBC beta2 by now? Any
>>> suggestions, problems, ideas, contributions?
>> 
>> 
>> Running configure on glinks (Text and graphic web browser includes
>> support for pmshell) 
>> (http://artax.karlin.mff.cuni.cz/~mikulas/vyplody/links/) I get these
>>  errors etc. Finds EMX, don't know if this is good or bad <gr> Get
>> this error In file included from configure:4236: 
>> g:/usr/include/netinet/ip.h:79: field `ip_src' has incomplete type 
>> g:/usr/include/netinet/ip.h:79: field `ip_dst' has incomplete type 
>> g:/usr/include/netinet/ip.h:165: parse error before "n_long" 
>> g:/usr/include/netinet/ip.h:167: field `ipt_addr' has incomplete type
>>  g:/usr/include/netinet/ip.h:168: parse error before "n_long" 
>> g:/usr/include/netinet/ip.h:170: parse error before '}' token 
>> g:/usr/include/netinet/ip.h:171: parse error before '}' token

Using autoconf 2.13 this error disappears. I guess configure was right
when it said to report to the maintainers as a bug. I just figured
since GCC is a beta....

>> 
>> Building works OK until the final linking when I get this 09-20-2003
>> 07:45:31  SYS3171  PID 4b5e  TID 0001  Slot 00b3 G:\USR\BIN\LD.EXE 
>> c0000005 000156cf 
> > P1=00000002  P2=fffc09bc  P3=XXXXXXXX  P4=XXXXXXXX
>> EAX=0021aa40  EBX=00182c90  ECX=00000002  EDX=0012fa18 ESI=00000005
>> EDI=0021aa40 DS=0053  DSACC=f0f3  DSLIM=ffffffff ES=0053  ESACC=f0f3
>> ESLIM=ffffffff FS=150b  FSACC=00f3  FSLIM=00000030 GS=0000
>> GSACC=****  GSLIM=******** CS:EIP=005b:000156cf  CSACC=f0df
>> CSLIM=ffffffff SS:ESP=0053:fffc09c0  SSACC=f0f3  SSLIM=ffffffff 
>> EBP=0012f718  FLG=00012202
>> 
>> LD.EXE 0001:000056cf
>Wow! That stack address doesn't look too good....
>Now the phun stuff here is that I just downloaded and built the latest
>stable links without any _build_ trouble. I cannot see the ip.h problem
>in the log either. Which version did you try build?
>However, it strikes me that MouOpen isn't detected. I'll look at that.

Links-2.1pre11 with the included configure using this command
F:\usr\src\links-2.1pre11 > sh configure --prefix=/usr
--enable-javascript --enable-graphics --with-x --with-pmshell
XFree86 also wasn't detected but I think that maybe a configuration
problem here. 

links-.2.1pre11 builds and runs fine with gcc3.21 just needing #define
PATH_MAX MAXPATHLEN in https.c (which was in previous tarballs)

Rebuilding libpng ( with gcc 2.81) gets rid of the SYS3171 in LD.EXE so
something was weird in my png.a. 


>
>
>> Disabling the pmshell graphic driver allows the build to finish but 
>> links dies with this error X:\usr\src\links-2.1pre11>links.exe 
>> INTERNAL ERROR at select.c:208: set_handlers: handle 4306 >=
>> FD_SETSIZE 2048
>> 
>> Forcing core dump
>> 
>> Process terminated by SIGSEGV
>
>This shouldn't be surprising to anyone which read the release notes and
>have followed some of the mails here. LIBC is at the moment using OS/2
>socket handles untranslated. So, since there is like 32k sockets in the
>BSD 4.4 based stack, you might get somewhat higher socket handles than
>what BSD select would normally work with.
>And even if you were lucky and got a few low socket numbers it still
>wouldn't work since select() is called. LIBC select is at the moment not
>doing much. bsdselect() and os2_select() might be tried instead.

What is the best way to call os2_select() instead of select. I tried defining select as os2_select and got the same errors.

>
>> Setting up enviroment for -Zomf (link386) and running configure I get
>>  lots of
>> 
>> 09-20-2003  19:45:53  SYS3175  PID 7bb1  TID 0001  Slot 00d8 
>> E:\OS2\LINK386.EXE c0000005 107bb7d9 P1=00000001  P2=ffffae9a
>> P3=XXXXXXXX  P4=XXXXXXXX EAX=0008ae8a  EBX=00000000  ECX=00000005
>> EDX=00000053 ESI=00000c00  EDI=00000a07 DS=0047  DSACC=00f3
>> DSLIM=0000b0cf ES=006f  ESACC=00f3  ESLIM=00005fff FS=150b
>> FSACC=00f3  FSLIM=00000030 GS=0000  GSACC=****  GSLIM=******** 
>> CS:EIP=005b:107bb7d9  CSACC=f0df  CSLIM=ffffffff SS:ESP=0053:0008ae8a
>> SSACC=f0f3  SSLIM=ffffffff EBP=ffffae92  FLG=00012216
>> 
>> INNIDM.DLL 0001:0000b7d9
>You've got unresolved symbols and my demangler crashes when link386 asks 
>it to demangle the symbol names. I didn't manage to test that code, 
>link386 didn't want do demangle anything when I wrote it. So, I really 
>hope I can reproduce this and fix it.

This happened when configure was testing for things that aren't here so
yes unresolved symbols.

>
>> and configure eventually dies with problems with png.lib (handles 
>> jpeg.lib z.lib etc fine) Running makeomflibs on png.a fixes the
>> problem and configure finishes fine. Had to also run makeomflibs on
>> ssl.a for weakld. Links gave same error INTERNAL ERROR at
>> select.c:208: set_handlers: handle 5909 >= FD_SETSIZE 2048
>png.a and ssl.a is external libraries built with other GCC version?

I think built with pgcc2.95.3. 
>
>A few workds about old libs. Because of an ABI change which was imposed 
>on the 3.2.2 release (underscores in OMF mode + _System and _Optlink), 
>there is a slight incompatability between libraries built with previous 
>versions GCC.

>
>If it's an import library you can usally just regenerate the OMF one 
>from the .a one. If you have a .def file you'll have to prefix all the 
>functions with '_' in most cases.

Yes, I rebuilt libpng and libz by adding the underscores and gcc322 was happy but still had problems with some EMX libs. I ran out of time for experimenting (recreating libs from a.out or rebuilding with changed def files) 
I guess EMX will have to be rebuilt for the new gcc to use functions from it or better yet we will move totally away from EMX, though that may mean needing thedevelopers toolkit.

>
>As for static libraries you're playing a risky game of two reasons, LIBC 
>and _System. OS/2 APIs are of type _System, meaning no underscore either 
>in aout form or OMF. LIBC have changes will cause incompatability 
>(constants may have been changed for instance). If the library 
>references an OS/2 API neither of the linkers will find it.

Yes that explains the problems with the EMX functions.
>
>
>Kind Regards,
>  knut

What symbol will refer to the new libc? eg #ifdef __EMX__ for emx
Dave
ps built a few other ports and haven't had any problems. At that gcc 3.2.2 seems to generate many fewer warnings then gcc 3.2.1