From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 8 Mar 2003 05:00:12 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 66 ************************************************** Friday 07 March 2003 Number 66 ************************************************** Subjects for today 1 GCC 3.2.1 is on Netlabs FTP : xyzyx" 2 Re: perl question : Dave Saville" 3 Re: SpamAssassin : Dave and Natalie" 4 Re: exec family : Andreas Buening 5 Re: Libtool Status : Andreas Buening **= Email 1 ==========================** Date: Sat, 08 Mar 2003 14:24:08 -0600 (CST) From: "xyzyx" Subject: GCC 3.2.1 is on Netlabs FTP Hi, In case you havn't seen it, Andy Z's GCC 3.2.1 port is at Netlabs incoming dir... Regards, Paul **= Email 2 ==========================** Date: Sat, 08 Mar 2003 14:58:55 +0000 (GMT) From: "Dave Saville" Subject: Re: perl question On Fri, 07 Mar 2003 16:20:48 -0500, Henry Sobotka wrote: >Dave Saville wrote: >> >> It certainly does not try and run /usr/local/bin/perl as it does not >> exist. Should it be processing the shebang line at all for options? > >"...the #! line is always examined for switches as the line is being >parsed" - Programming Perl, p. 329. In this case it doesn't have to try >to run /usr/local/bin/perl because perl is already running; though >obviously the script would fail if invoked in a shell that relied on the >line to call the interpreter. > Thanks - I had not realised that perl has complete shebang processing logic. >Incidentally, here the "Too late" croak (from perl.c) goes away and a >taint warning is displayed when a script with -T in the shebang line is >invoked directly at a sh prompt, e.g.: I would expect that. -- Regards Dave Saville **= Email 3 ==========================** Date: Sat, 08 Mar 2003 16:20:49 -0800 From: "Dave and Natalie" Subject: Re: SpamAssassin On Fri, 28 Feb 2003 20:08:33 +0000, John Poltorak wrote: > >Anyone heard of SpamAssassin? > >It appears to be written in Perl, so I guess it ought to run on OS/2... > >Anyone tried running it? I'm running SpamAssassin here, works great. I'm using it with pop3proxy which is a popproxy written with win32 in mind. Unluckily I didn't have much luck getting spamc (the daemon version of SpamAssassin working) Dave **= Email 4 ==========================** Date: Sat, 08 Mar 2003 16:52:40 +0100 From: Andreas Buening Subject: Re: exec family John Poltorak wrote: > > On Thu, Mar 06, 2003 at 06:24:48PM +0000, Dave Saville wrote: > > > I know that execl* is for fixed number of args, execv* for variable > > and *e passes an environment. But what is the difference between > > execv & execp - the parameter list are the same? > > I guess that's a typo and you mean execv & execvp... > > According to my Kelley/Pohl 'Book on C':- > > Members of the family with 'p' in their name use the path specified in the > environment to determine which directories to search for the program. > > Presumably execv uses either the current directory or a fully qualified > pathname... If I remember correctly I had a look at the emx sources for the same question long time ago, and emx ignores the "p", i.e. it uses PATH in any case. Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 5 ==========================** Date: Sat, 08 Mar 2003 16:53:02 +0100 From: Andreas Buening Subject: Re: Libtool Status Stefan Neis wrote: > > On Wed, 5 Mar 2003, Andreas Buening wrote: > > > Solaris supports LD_LIBRARY_PATH unlike other Unixes. > > Sorry? Which Unixes don't? I know for sure that at least Solaris, HP/UX, > Linux and all BSD derivates do support LD_LIBRARY_PATH (though for MacOS X > it has a slightly different name, IIRC it's DY_LIBRARY_PATH or something > similar) AIX. At least I haven't been able to find a way to do this. > > The library paths > > can be hardcoded (though I've never understood the rpath thing) or > > you need some weird flags to create a shared library. > > Sorry, but the hardcoded library paths have _nothing_ to do with library > creation. When you're compiling an application you can be using a hard > coded location for the libraries on your system via rpath but that needs > some additional (mysterious) flags and is complete nonsense anyway (it > makes the whole thing unusable on anything but your own box and has no > visible benefit). The default behaviour is just fine. Are you sure? Last time I tried this -lfoo caused the program/library to use the hardcoded libfoo.so.x.y.z unless I had a symbolic link libfoo.so in the current directory though I don't remember which system (Linux or Solaris, I guess) and which gcc version. > > Imagine you link > > ~/src/foo-1.2/src/footest with the absolute path of > > ~/src/foo-1.2/lib/libfoo.so.1.2.0 in your build directory. Then you > > improve your dllar for each platform and finally you end up with > > a libtool clone. ;-) > > I don't think so ... But I admit that supporting anything but gcc which > nicely maps "-shared" to whatever flags the native linker requires > complicates things _very_ much. That's something I keep forgetting about > all the time ... I really doubt. If you look e.g. at the libtool.m4 file there is a lot of obscure sh code to deal with different systems and that's not just due to cygwin or os2. Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie.