From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 26 Mar 2002 04:20:32 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 175 ************************************************** Monday 25 March 2002 Number 175 ************************************************** Subjects for today 1 Re: Boost. Blah. : Henry Sobotka 2 Re: New binary package for GNU Bash 2.05a and GNU Texinfo 4.1 : Jun Sawataishi 3 Re: Re: Building Perl.exe as a test of manhood ;-) : Stephen Amadei 4 Re: Announcing fixpdf.cmd : Dave and Natalie" 5 Where is UnixOS2 ? : mikus at bga.com (Mikus Grinbergs) 6 Re: Boost. Blah. : James Cannon 7 Re: Re: Building Perl.exe as a test of manhood ;-) : John Poltorak 8 Re: Re: Building Perl.exe as a test of manhood ;-) : Henry Sobotka 9 Re: hostname.exe : Henry Sobotka 10 Re: Re: Building Perl.exe as a test of manhood ;-) : John Poltorak 11 Re: Using SLANG : John Poltorak 12 Re: Re: Building Perl.exe as a test of manhood ;-) : Edwin Guenthner 13 Re: Re: Running ./configure : John Poltorak 14 Re: Re: Building Perl.exe as a test of manhood ;-) : Henry Sobotka 15 Re: Re: Building Perl.exe as a test of manhood ;-) : Edwin Guenthner 16 Re: Re: Building Perl.exe as a test of manhood ;-) : csaba.raduly at sophos.com 17 hostname.exe : John Poltorak 18 Re: Where is UnixOS2 ? : John Poltorak 19 Amending $PATH via called script : John Poltorak 20 Re: Ogg Vorbis for Stream Audio : Dave and Natalie" 21 Re: Need some help builing GETTEXT : Dave and Natalie" 22 Re: Re: Building Perl.exe as a test of manhood ;-) : John Poltorak 23 Re: hostname.exe : John Poltorak 24 Re: Re: Building Perl.exe as a test of manhood ;-) : Edwin =?iso-8859-1?Q?G=FCnthner?= 25 Re: Re: Building Perl.exe as a test of manhood ;-) : Edwin =?iso-8859-1?Q?G=FCnthner?= 26 Re: Re: Building Perl.exe as a test of manhood ;-) : James Cannon 27 Re: PERL required to build NCURSES? : Thomas Dickey 28 Re: Amending $PATH via called script : John Poltorak 29 PERL required to build NCURSES? : John Poltorak 30 New BitchX : John Poltorak 31 Ogg Vorbis for Stream Audio : John Poltorak 32 Re: Re: Running ./configure : Andreas Buening 33 Re: Boost. Blah. : Andreas Buening 34 Re: Ogg Vorbis for Stream Audio : Mikkel C. Simonsen" 35 Linux API support layer driver (Freeware) : Stepan Kazakov 36 Re: Boost. Battle II. : Stephen Amadei **= Email 1 ==========================** Date: Tue, 26 Mar 2002 00:07:32 -0500 From: Henry Sobotka Subject: Re: Boost. Blah. Stephen Amadei wrote: > > The only pgcc I see is 1.1.1, which on the webpage link is gcc 2.95.3. > Where can I find a gcc 3.x for OS/2? Thanx in advance. ftp://ftp.netlabs.org/pub/gcc/ You'll need the gettext from there and probably the binutils as well. If you're building with -Zomf, be sure to follow the instructions for weaksyms.omf. Also, if you hit a vargs-related can't-convert-x-to-y compilation error, the fix is to move emx\lib\gcc-lib\i386-pc-os2_emx\3.0.2\include\stdarg.h out of the way so that the one in emx\include gets used instead. h~ **= Email 2 ==========================** Date: Tue, 26 Mar 2002 02:19:14 +0900 From: Jun Sawataishi Subject: Re: New binary package for GNU Bash 2.05a and GNU Texinfo 4.1 At Mon, 25 Mar 2002 16:55:53 +0000, John Poltorak wrote: > > On Mon, Mar 25, 2002 at 10:31:44AM -0500, Thomas E. Dickey wrote: > > On Mon, 25 Mar 2002, John Poltorak wrote: > > > > > Is this the same program as the one included in LESS? :- Yes. > > > http://www.greenwoodsoftware.com/less/less-374.tar.gz > > preferably not. (it would make ncurses unusable in a number of cases). > What's the problem with SCRSIZE? It's a program included with LESS so many > people are likely to have it already. scrsize.exe requires X11.dll, because it is linked with X11.a, not X11_s.a. So, scrsize.exe fails if X11.dll is not available. # OS/2 is not a question, it's a solution. # SAWATAISHI Jun # http://www2s.biglobe.ne.jp/~vtgf3mpr/ **= Email 3 ==========================** Date: Tue, 26 Mar 2002 05:42:30 -0500 (EST) From: Stephen Amadei Subject: Re: Re: Building Perl.exe as a test of manhood ;-) On Tue, 26 Mar 2002, Edwin Guenthner wrote: > >Try this shell script and see how far it gets:- > > Just wondering: is your perl build able to fork()? Also wondering... will this version allow mod_perl to compile? Thanks for the script... I'll give it a try. ----Steve Stephen Amadei Dandy.NET! CTO Atlantic City, NJ **= Email 4 ==========================** Date: Tue, 26 Mar 2002 08:27:07 -0800 From: "Dave and Natalie" Subject: Re: Announcing fixpdf.cmd On Mon, 25 Mar 2002 09:25:24 -0500, HTRAVIS wrote: > http://jt-mj.net > >fixpdf.cmd works here on numerous files, permitting Acrobat 3 to be >used as the somewhat faste-than-Ghostview/Script viewer it is. >Thank-you, indeed, Julian for a native solution. Rather fast, too. I think this depends upon the video driver. Acrobat runs like a glacier here. Dave **= Email 5 ==========================** Date: Tue, 26 Mar 2002 08:40:55 -0600 From: mikus at bga.com (Mikus Grinbergs) Subject: Where is UnixOS2 ? For a long long time now, I've been accessing the unixos2 depository via ftp at unixos2.com For the last couple days, my ftp access has been rejected with something like "all server ports are busy". Has the depository "server-name" changed ? mikus **= Email 6 ==========================** Date: Tue, 26 Mar 2002 09:17:43 -0800 (PST) From: James Cannon Subject: Re: Boost. Blah. You need to pull in the C++ libs. It's a command line switch. That was one of my obstacles in compiling C++. :) --- Stephen Amadei wrote: > > O.K... my fighting with ./configure has taken a back > seat, as the laterest > error is... "Boost not found. Install Boost > libraries. www.boost.org" > > Well, I have downloaded this thing, and it's got > some kind of "portible" > make system called Jam. Well, I managed to get Jam > to compile in EMX, > and it appears to work pretty well. > > Out of 712 targets needed for creation/compilation > 688 worked. about 24 > die because g++ is being called. I have always > compiled c++ with gcc... > what exact is the difference between gcc and g++. I > made a copy of gcc > into g++, but it won't compile... something about > "sorry not implemented: > namespace". > > Is there a way around this? I guess I'll look on > Hobbes for a g++. > > ----Steve > Stephen Amadei > Dandy.NET! CTO > Atlantic City, NJ > > ===== Sincerely, James Cannon Using OS/2 Warp in the beautiful Wine Country of Northern California! __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ **= Email 7 ==========================** Date: Tue, 26 Mar 2002 09:34:01 +0000 From: John Poltorak Subject: Re: Re: Building Perl.exe as a test of manhood ;-) On Mon, Mar 25, 2002 at 06:38:49PM -0500, Stephen Amadei wrote: > On Sun, 24 Mar 2002, John Poltorak wrote: > > > So I'd urge anyone who hasn't already done so to build a package on OS/2. > > Maybe try building Perl - it's a very useful exercise, and quite > > satisfying when you come up with a final runnable PERL.EXE. > > IMHO, building Perl is a twisted intro to building packages on OS/2. > > It's been three years, and I am _still_ unable to get past DynaLoader in > the Perl build (so I could get mod_perl to run). > > Of course, since the Perl build is not only C, it is my weakness. > Normally, when building a package, if I loose my way, I just start > compiling things one at a time. Last year, I found that building Perl really wasn't that difficult... Try this shell script and see how far it gets:- # !sh AWK=c:/usr/bin/awk.exe export AWK C_INCLUDE_PATH=c:/emx/include CPLUS_INCLUDE_PATH=c:/emx/include/cpp';'c:/emx/include LIBRARY_PATH=c:/emx/lib export C_INCLUDE_PATH export CPLUS_INCLUDE_PATH export LIBRARY_PATH PATH=c:/usr/bin';'c:/emx/bin';'c:/os2 export PATH test -f stable.tar.gz || wget -c http://www.cpan.org/src/stable.tar.gz c:\usr\bin\mkdir -p /tmp/perl cd /tmp/perl tar zxf $CWD/stable.tar.gz cd perl-5.6.1 patch -p0 < os2\diff.configure Configure -des -D prefix=c:/usr/lib/perl 2>&1 | tee configure.log make 2>&1 | tee make.log make test 2>&1 | tee test.log make install What seems to be crucial is having the correct utils in the path. It appears that having the wrong version of TR can trip you up. You probably also need to have PDKSH's sh.exe in \usr\bin or \bin. I have it in both just to be sure. > ----Steve > Stephen Amadei -- John **= Email 8 ==========================** Date: Tue, 26 Mar 2002 09:51:24 -0500 From: Henry Sobotka Subject: Re: Re: Building Perl.exe as a test of manhood ;-) Edwin Guenthner wrote: > > fork() or die "why baby why? $!\n"; Because I screwed up. > But Now I see that the old 5.05 is failing as > well, thus I guess there might be something wrong with > my emx or so ... although I am using the neweset version ... The problem's not with your environment, but the build process, which appears to have crossed wires. Here "make" produces an OMF perl.exe, and "make perl_" does an aout build. This is consistent with the build instructions in perlos2, but contradictory to the section on fork() that Csaba quoted. h~ **= Email 9 ==========================** Date: Tue, 26 Mar 2002 10:05:19 -0500 From: Henry Sobotka Subject: Re: hostname.exe John Poltorak wrote: > > MPTS includes hostname.exe as does the GNU Shell Utils. > > What difference is there? > > Which one should take precedence? Here I've also got a third version with the old bash distribution. They all output the same name, so for all practical purposes it makes no difference which one takes precedence. h~ **= Email 10 ==========================** Date: Tue, 26 Mar 2002 10:28:10 +0000 From: John Poltorak Subject: Re: Re: Building Perl.exe as a test of manhood ;-) On Tue, Mar 26, 2002 at 11:02:48AM +0100, Edwin Guenthner wrote: > 26.03.2002 10:34:01, John Poltorak wrote: > > > >Try this shell script and see how far it gets:- > > Just wondering: is your perl build able to fork()? How can I tell? I have a problem with one of the Perl tests which uses fork on a system where I have been trying to build Perl in a clean environment, but normally the tests work fine. -- John **= Email 11 ==========================** Date: Tue, 26 Mar 2002 10:38:46 +0000 From: John Poltorak Subject: Re: Using SLANG On Fri, Mar 22, 2002 at 03:50:34PM +0000, csaba.raduly at sophos.com wrote: > > On 22/03/2002 12:06:45 owner-os2-unix wrote: > > [snip] > > > >Incidentally, is it possible to add the equivalent of -lvideo to the > >command line for make without amending the makefile? > > > Yes, but it's not going to do what I think you think it'll do :-) > I think you'll need to modify the makefile. Even modifying the Makefile doesn't help getting rid of errors like these:- rain.c:23 (C:\TMP\ccc59597): Undefined symbol _SLcurses_initscr referenced from text segment rain.c:24 (C:\TMP\ccc59597): Undefined symbol _SLcurses_nil referenced from text segment rain.c:25 (C:\TMP\ccc59597): Undefined symbol _SLcurses_nil referenced from text segment rain.c:36 (C:\TMP\ccc59597): Undefined symbol _SLcurses_Stdscr referenced from text segment rain.c:36 (C:\TMP\ccc59597): Undefined symbol _SLcurses_wmove referenced from text segment rain.c:36 (C:\TMP\ccc59597): Undefined symbol _SLcurses_Stdscr referenced from text segment rain.c:36 (C:\TMP\ccc59597): Undefined symbol _SLcurses_waddch referenced from text segment There's still something else missing. -- John **= Email 12 ==========================** Date: Tue, 26 Mar 2002 11:02:48 +0100 From: Edwin Guenthner Subject: Re: Re: Building Perl.exe as a test of manhood ;-) 26.03.2002 10:34:01, John Poltorak wrote: >Try this shell script and see how far it gets:- Just wondering: is your perl build able to fork()? **= Email 13 ==========================** Date: Tue, 26 Mar 2002 11:07:13 +0000 From: John Poltorak Subject: Re: Re: Running ./configure On Mon, Mar 25, 2002 at 07:30:22AM -0800, James Cannon wrote: > Hi John, > > I'ld to volunteer to test out your Perl package. > Hopefully, I can document my experiences with it and > put on the 'ezine. Please let me know the steps > required ... Firstly you need to have a working EMX/GCC development environment along with the common GNU utils. Precisely which ones and which versions is a matter which really needs to be determined since it appears that odd results occur with certain versions of specific utils, or maybe even it is because of the loaction of those utils. You also need sh.exe from PDKSH, then run the script which I posted a short while ago, after adjusting the paths for your local environment. This _ought_ to provide a working Perl although not one as highly tuned as the one HS puts together. Actually there is one gotcha I've overlooked... 'Make install' doesn't work with v5.6.1 because of the existance of the file called INSTALL, so that will need to be renamed prior to running 'Make install'. Apparently this problem will not arise in subsequent versions of Perl. > > --- John Poltorak wrote: > > So I'd urge anyone who hasn't already done so to > > build a package on OS/2. > > Maybe try building Perl - it's a very useful > > exercise, and quite > > satisfying when you come up with a final runnable > > PERL.EXE. > > > > -- > > John > > > > > > > ===== > Sincerely, > James Cannon -- John **= Email 14 ==========================** Date: Tue, 26 Mar 2002 11:07:25 -0500 From: Henry Sobotka Subject: Re: Re: Building Perl.exe as a test of manhood ;-) Edwin Günthner wrote: > > Uups. And perl_ isn't part of your package if I remember that correctly. > Any plans / time to build a new package and drop it at Hobbes? Yes. I should get a chance to tackle it over the upcoming long weekend. h~ **= Email 15 ==========================** Date: Tue, 26 Mar 2002 12:44:46 +0100 From: Edwin Guenthner Subject: Re: Re: Building Perl.exe as a test of manhood ;-) 26.03.2002 11:28:10, John Poltorak wrote: >On Tue, Mar 26, 2002 at 11:02:48AM +0100, Edwin Guenthner wrote: >> 26.03.2002 10:34:01, John Poltorak wrote: >> >> >> >Try this shell script and see how far it gets:- >> >> Just wondering: is your perl build able to fork()? > >How can I tell? Well, at the moment on my machine even a simple fork() or die "why baby why? $!\n"; fails. But Now I see that the old 5.05 is failing as well, thus I guess there might be something wrong with my emx or so ... although I am using the neweset version ... **= Email 16 ==========================** Date: Tue, 26 Mar 2002 14:03:32 +0000 From: csaba.raduly at sophos.com Subject: Re: Re: Building Perl.exe as a test of manhood ;-) On 26/03/2002 11:44:46 Edwin Guenthner wrote: [snip] > >Well, at the moment on my machine even a simple >fork() or die "why baby why? $!\n"; > >fails. But Now I see that the old 5.05 is failing as >well, thus I guess there might be something wrong with >my EMX or so ... although I am using the newest version ... > fork Does a fork(2) system call to create a new process running the same program at the same point. It returns the child pid to the parent process, "0" to the child process, or "undef" if the fork is unsuccessful. Note that 0 is still considered a failure by if, so it'll *always* fail in the child process. What you (seem to) want is defined fork() or die "Error: $!"; According to perlos2, Perl compiled with EMX is capable of fork. (at least "perl.exe" which is in a.out format. perl___.exe and perl__.exe cannot fork, as they are compiled in OMF) HTH, -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 17 ==========================** Date: Tue, 26 Mar 2002 14:12:34 +0000 From: John Poltorak Subject: hostname.exe MPTS includes hostname.exe as does the GNU Shell Utils. What difference is there? Which one should take precedence? -- John **= Email 18 ==========================** Date: Tue, 26 Mar 2002 15:16:40 +0000 From: John Poltorak Subject: Re: Where is UnixOS2 ? On Tue, Mar 26, 2002 at 08:40:55AM -0600, Mikus Grinbergs wrote: > For a long long time now, I've been accessing the unixos2 > depository via ftp at unixos2.com > > For the last couple days, my ftp access has been rejected > with something like "all server ports are busy". > > Has the depository "server-name" changed ? No, it's just busy. I don't know how many concurrent users are allowed. > mikus -- John **= Email 19 ==========================** Date: Tue, 26 Mar 2002 15:42:53 +0000 From: John Poltorak Subject: Amending $PATH via called script Is there any way to amend the path via a called script? I have a path /abc;/def; in script P. I want to be able to amend that path to /pqr;/abc;/def; by calling an external script R. Is there any way to do this? I can amend it within R but can't find any way to change the original environment. I've tried 'export PATH' but that didn't work. -- John **= Email 20 ==========================** Date: Tue, 26 Mar 2002 15:43:22 -0800 From: "Dave and Natalie" Subject: Re: Ogg Vorbis for Stream Audio On Tue, 26 Mar 2002 20:57:17 +0000, John Poltorak wrote: > >For once the BBC is not going wholeheartedly after a Windows solution and >is looking at using Ogg Vorbis for streaming audio. See:- > >http://support.bbc.co.uk/ogg/ > >Does anyone know how I can listen to any of these broadcasts? Goto http://www.math.berkeley.edu/~roconnor/ for an OS/2 solution. Dave **= Email 21 ==========================** Date: Tue, 26 Mar 2002 15:44:33 -0800 From: "Dave and Natalie" Subject: Re: Need some help builing GETTEXT On Mon, 25 Mar 2002 14:12:41 +0000, John Poltorak wrote: > >If anyone has managed to build this:- > >ftp://ftp.gnu.org/pub/gnu/gettext/gettext-0.11.1.tar.gz > >I'd appreciate a few tips.... I figured I'd give a try. Note I'm not a C programmer. First I used pgcc 2.95.3. After screwing around all day this is the best I've found so far. First I ran sh configure (using a slightly modified version of config.site from Mr Sawataishi unixos2 package) then make. Then I got this error In file included from ../intl/osdep.c:20: ../intl/os2compat.c: In function `os2_initialize': ../intl/os2compat.c:97: conflicting types for `_nl_default_dirname__' ../intl/os2compat.c:42: previous declaration of `_nl_default_dirname__' ../intl/os2compat.c:99: warning: passing arg 1 of `strcpy' discards qualifiers from pointer target type make: *** [out/release/intl/osdep.o] Error 1 I fixed this by commenting out line 97 in os2compat.c. Can someone look at this? Not sure if this is the best solution Eventually the compile got into a loop in libtool. I killed it. At that the loop was so bad here that I needed the big red button to kill it, partly due to my poor ancient machine being overstressed, swap file was upto 130 Mbs on this 32 Mb machine. Then cd into os2 and ran make. First time get make: *** No rule to make target `out/release/intl.a', needed by `all'. Stop. rerun make Then I got this ../src/read-tcl.c: In function `msgdomain_read_tcl': ../src/read-tcl.c:71: `GETTEXTDATADIR' undeclared (first use in this function) ../src/read-tcl.c:71: (Each undeclared identifier is reported only once ../src/read-tcl.c:71: for each function it appears in.) I added a backslash to the end of line 54 in os2/makefile and added -DGETTEXTDATADIR=\"$(pkgdatadir)\" after line 54 in the defs section. Then I got this ../src/x-python.c:41: uniname.h: No such file or directory ../src/x-python.c:185: `UNINAME_MAX' undeclared here (not in a function) ../src/x-python.c:185: size of array `phase1_pushback' has non-integer type ../src/x-python.c: In function `phase7_getuc': ../src/x-python.c:615: `UNINAME_MAX' undeclared (first use in this function) ../src/x-python.c:615: (Each undeclared identifier is reported only once ../src/x-python.c:615: for each function it appears in.) ../src/x-python.c:615: size of array `buf' has non-integer type ../src/x-python.c:638: warning: implicit declaration of function `unicode_name_character' ../src/x-python.c:639: `UNINAME_INVALID' undeclared (first use in this function) So cd into libuniname and make to build libuniname. This only works if you do the configure and make at the beginning Add -luniname to line 60, the libs line and copy (temporary?) libuniname.a to a lib directory such as /emx/lib Edit src\x-python.c to change #include "uniname.h" to #include "../libuniname/uniname.h" or copy uniname.h to an include directory, eg /emx/include. Maybe the best solution is to manually install uniname somewhere, eg /emx/lib and /emx/include. Do make again. Most of the files end up in os2/out/release though some are in /os2/emx. Most likely make install will finish it off but now is the time for testing and I don't have enough time this morning Dave **= Email 22 ==========================** Date: Tue, 26 Mar 2002 15:54:00 +0000 From: John Poltorak Subject: Re: Re: Building Perl.exe as a test of manhood ;-) On Tue, Mar 26, 2002 at 04:15:16PM +0100, Edwin Günthner wrote: > > > csaba.raduly at sophos.com wrote: > > > defined fork() or die "Error: $!"; > > You are right. Thats the think that I love > about perl: for open it is "open or die" > and for fork it is like above ... > > Anyway, this one runs with the old perl, > but it still fails with the newer builds 561 > and 572. What is it you are running? I have a homespun Perl v5.6.1 and would like to see what it produces. > ;-( -- John **= Email 23 ==========================** Date: Tue, 26 Mar 2002 16:09:07 +0000 From: John Poltorak Subject: Re: hostname.exe On Tue, Mar 26, 2002 at 10:05:19AM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > MPTS includes hostname.exe as does the GNU Shell Utils. > > > > What difference is there? > > > > Which one should take precedence? > > Here I've also got a third version with the old bash distribution. Some BASH distributions come bundled with a copy of GNU Shell Utils just to make things even more confusing. If you run hostname --version it may well say:- hostname - GNU sh-utils 1.12 > They > all output the same name, so for all practical purposes it makes no > difference which one takes precedence. As far as hostname.exe is concerned, I've never really been sure where it actually gets the name of the local host from, is it environment, DNS or hosts file and which sequence is used? Do all these hostname programes use the same method? > > h~ -- John **= Email 24 ==========================** Date: Tue, 26 Mar 2002 16:15:16 +0100 From: Edwin =?iso-8859-1?Q?G=FCnthner?= Subject: Re: Re: Building Perl.exe as a test of manhood ;-) csaba.raduly at sophos.com wrote: > defined fork() or die "Error: $!"; You are right. Thats the think that I love about perl: for open it is "open or die" and for fork it is like above ... Anyway, this one runs with the old perl, but it still fails with the newer builds 561 and 572. ;-( **= Email 25 ==========================** Date: Tue, 26 Mar 2002 16:30:20 +0100 From: Edwin =?iso-8859-1?Q?G=FCnthner?= Subject: Re: Re: Building Perl.exe as a test of manhood ;-) Henry Sobotka wrote: > The problem's not with your environment, but the build process, which > appears to have crossed wires. Here "make" produces an OMF perl.exe, and > "make perl_" does an aout build. This is consistent with the build > instructions in perlos2, but contradictory to the section on fork() that > Csaba quoted. Uups. And perl_ isn't part of your package if I remember that correctly. Any plans / time to build a new package and drop it at Hobbes? **= Email 26 ==========================** Date: Tue, 26 Mar 2002 17:00:28 -0800 (PST) From: James Cannon Subject: Re: Re: Building Perl.exe as a test of manhood ;-) Hi John, Maybe I should first start off with getting pdksh installed. Hobbes has one that is out of date. Which one do you recommend? TIA --- John Poltorak wrote: > On Mon, Mar 25, 2002 at 06:38:49PM -0500, Stephen > Amadei wrote: > > On Sun, 24 Mar 2002, John Poltorak wrote: > > > > > So I'd urge anyone who hasn't already done so to > build a package on OS/2. > > > Maybe try building Perl - it's a very useful > exercise, and quite > > > satisfying when you come up with a final > runnable PERL.EXE. > > > > IMHO, building Perl is a twisted intro to building > packages on OS/2. > > > > It's been three years, and I am _still_ unable to > get past DynaLoader in > > the Perl build (so I could get mod_perl to run). > > > > Of course, since the Perl build is not only C, it > is my weakness. > > Normally, when building a package, if I loose my > way, I just start > > compiling things one at a time. > > Last year, I found that building Perl really wasn't > that difficult... > > Try this shell script and see how far it gets:- > > > # !sh > > AWK=c:/usr/bin/awk.exe > export AWK > > C_INCLUDE_PATH=c:/emx/include > CPLUS_INCLUDE_PATH=c:/emx/include/cpp';'c:/emx/include > LIBRARY_PATH=c:/emx/lib > > export C_INCLUDE_PATH > export CPLUS_INCLUDE_PATH > export LIBRARY_PATH > > PATH=c:/usr/bin';'c:/emx/bin';'c:/os2 > export PATH > > test -f stable.tar.gz || wget -c > http://www.cpan.org/src/stable.tar.gz > > c:\usr\bin\mkdir -p /tmp/perl > cd /tmp/perl > tar zxf $CWD/stable.tar.gz > cd perl-5.6.1 > patch -p0 < os2\diff.configure > Configure -des -D prefix=c:/usr/lib/perl 2>&1 | tee > configure.log > make 2>&1 | tee make.log > make test 2>&1 | tee test.log > make install > > What seems to be crucial is having the correct utils > in the path. It > appears that having the wrong version of TR can trip > you up. You probably > also need to have PDKSH's sh.exe in \usr\bin or > \bin. I have it in both > just to be sure. > > > ----Steve > > Stephen Amadei > > > -- > John > > > ===== Sincerely, James Cannon Using OS/2 Warp in the beautiful Wine Country of Northern California! __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ **= Email 27 ==========================** Date: Tue, 26 Mar 2002 18:21:43 -0500 From: Thomas Dickey Subject: Re: PERL required to build NCURSES? On Tue, Mar 26, 2002 at 08:26:11PM +0000, John Poltorak wrote: > > Is PERL required to build NCURSES? no. > I'm trying to put together a build environment from scratch and one of the > first things I want to build is NCURSES. Before I can do that I need > to install a specific version of Autoconf, which I can now do fairly > easily, but I've just noticed that Autoscan is not built since PERL is not > found. Does NCURSES or even TIN need Autoscan or PERL to build properly? no. I consider it bad design practice to add dependencies on tools such as Perl which are not part of the standard development suite. (It's ok to deliver Perl scripts that can supply add-on functionality). > It's difficult working out what needs to be installed first - a kind of > chicken and egg situation... > > > -- > John > > -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 28 ==========================** Date: Tue, 26 Mar 2002 18:45:55 +0000 From: John Poltorak Subject: Re: Amending $PATH via called script On Wed, Mar 27, 2002 at 01:42:18AM +0900, Jun Sawataishi wrote: > At Tue, 26 Mar 2002 15:42:53 +0000, > John Poltorak wrote: > > Is there any way to amend the path via a called script? > > I have a path /abc;/def; in script P. > > I want to be able to amend that path to /pqr;/abc;/def; by calling > > an external script R. > > Is there any way to do this? > > I can amend it within R but can't find any way to change the original > > environment. I've tried 'export PATH' but that didn't work. > You can't, I think. Child process can never change env. vars. of > parent process. > > How about use a script like this. > #!sh > #addpath.sh > PATH=`cmd.exe /c "echo %PATH%" | sed -e 's at \\\\ at / at g'` > echo "export PATH="\'"$1;$PATH"\'> tmp.tmp Thanks for the suggestion, I'd forgotten about backticks... That does give me an option albeit limited. It does allow me to change the path but I wanted something more flexible. Basically I want to create a general purpose script, but would like to cater for exceptions by running specific code inline. For instance, if I wanted to build a package called foo I would run 'buildgen foo' which run a generall purpose build routine with 'foo' as the target, but if foo required specific environment variables I would like to run something inline to set them, such as if exist foo-specific call foo-specific. Maybe I can try using something like a here document... > # SAWATAISHI Jun -- John **= Email 29 ==========================** Date: Tue, 26 Mar 2002 20:26:11 +0000 From: John Poltorak Subject: PERL required to build NCURSES? Is PERL required to build NCURSES? I'm trying to put together a build environment from scratch and one of the first things I want to build is NCURSES. Before I can do that I need to install a specific version of Autoconf, which I can now do fairly easily, but I've just noticed that Autoscan is not built since PERL is not found. Does NCURSES or even TIN need Autoscan or PERL to build properly? It's difficult working out what needs to be installed first - a kind of chicken and egg situation... -- John **= Email 30 ==========================** Date: Tue, 26 Mar 2002 20:50:33 +0000 From: John Poltorak Subject: New BitchX There a new version of BitchX for PM at Hobbes:- http://hobbes.nmsu.edu/pub/incoming/pmbx10c19.zip -- John **= Email 31 ==========================** Date: Tue, 26 Mar 2002 20:57:17 +0000 From: John Poltorak Subject: Ogg Vorbis for Stream Audio For once the BBC is not going wholeheartedly after a Windows solution and is looking at using Ogg Vorbis for streaming audio. See:- http://support.bbc.co.uk/ogg/ Does anyone know how I can listen to any of these broadcasts? -- John **= Email 32 ==========================** Date: Tue, 26 Mar 2002 22:01:29 +0100 From: Andreas Buening Subject: Re: Re: Running ./configure Stefan Neis wrote: > > Hi, > > > >(and please don't tell me that I must never use a drive > > >letter because a) it's not Posix and b) it's much more > > >fun if the program behaves different on different drives) > > Yes, it's much more fun, if it behaves different on different > machines. :-( > If drive letters are compiled into the code, this essentially > means distributing precompiled binaries is completely useless > as they won't work anywhere else (Over here, e.g. C: is > either a FAT or an NTFS partition, depending on the version of > the DOS which I booted the last time). > So it remains to say: > - either don't use drive letters and wait for libemu to take > care of it automatically at some later point of time, i.e. the > programs behave different on different drives _for_now_ - but > no longer once they are linked against libemu instead of EMX - > but they are minimally functional _for_everyone_. > - or if you are willing to spend some more time on it, query the > environment variable UNIXROOT and prepend that to the path. > This will especially add a (configurable) drive letter. It's a > bit frustrating that this code can just be removed a bit later, > but for now it seems to be the best solution (at least to me). The way I used to solve this was to use c:/blurb as prefix and additionally $UNIXROOT/blurb in the code. In this case it doesn't matter whether c: is FAT or a ram disk as long as c: is an accessible drive. However, I admit that there is a problem if c: simply does not exist. Btw. I don't think that UNIXROOT code will have to be removed once libemu is ready for production use. Some people might still want to have Unix like shell tools they can call from a REXX script or from command line (_with_ drive letters). I wonder how do the MinGW32 people solve these problems? They don't wait for libemu (cygwin), I guess. 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 Redmond where the Shadows lie. **= Email 33 ==========================** Date: Tue, 26 Mar 2002 22:01:35 +0100 From: Andreas Buening Subject: Re: Boost. Blah. Stephen Amadei wrote: > > O.K... my fighting with ./configure has taken a back seat, as the laterest > error is... "Boost not found. Install Boost libraries. www.boost.org" > > Well, I have downloaded this thing, and it's got some kind of "portible" > make system called Jam. Well, I managed to get Jam to compile in EMX, > and it appears to work pretty well. > > Out of 712 targets needed for creation/compilation 688 worked. about 24 > die because g++ is being called. I have always compiled c++ with gcc... > what exact is the difference between gcc and g++. I made a copy of gcc > into g++, but it won't compile... something about "sorry not implemented: > namespace". ^^^^^^^^^^^^ You need a "real" C++ compiler! Those old gcc versions had a flag to turn on dummy namespaces but it didn't work well. You need at least gcc 2.95 (which you can't find on hobbes). [snip] 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 Redmond where the Shadows lie. **= Email 34 ==========================** Date: Tue, 26 Mar 2002 22:13:32 +0100 From: "Mikkel C. Simonsen" Subject: Re: Ogg Vorbis for Stream Audio John Poltorak wrote: > > For once the BBC is not going wholeheartedly after a Windows solution and > is looking at using Ogg Vorbis for streaming audio. See:- > > http://support.bbc.co.uk/ogg/ > > Does anyone know how I can listen to any of these broadcasts? Have you asked dink? Best regards, Mikkel C. Simonsen > > -- > John **= Email 35 ==========================** Date: Tue, 26 Mar 2002 23:21:36 -0500 From: Stepan Kazakov Subject: Linux API support layer driver (Freeware) LXAPI32: Linux API support layer driver (Freeware) http://www.nord-com.net/s.milcke/lxapi_en.htm -- madded. [Red Hot Chili Hackers] **= Email 36 ==========================** Date: Tue, 26 Mar 2002 23:36:56 -0500 (EST) From: Stephen Amadei Subject: Re: Boost. Battle II. On Tue, 26 Mar 2002, Henry Sobotka wrote: Thanks for the help, Henry. I think I've nearly got it... one more problem... > ftp://ftp.netlabs.org/pub/gcc/ > > You'll need the gettext from there and probably the binutils as well. Got 'em. Installed everything. > If you're building with -Zomf, be sure to follow the instructions for > weaksyms.omf. Also, if you hit a vargs-related can't-convert-x-to-y > compilation error, the fix is to move > emx\lib\gcc-lib\i386-pc-os2_emx\3.0.2\include\stdarg.h out of the way so > that the one in emx\include gets used instead. I really can't say if I am or not. Boost is just a bunch of libraries... I suppose after they get compiled into SDTS, it will all still be EMX code. But, anyway, I installed the gcc gcc/g77/gop/gpp libraries and totally upgraded my binaries (bin.new -> bin). I get a bit father now with g++, but not quite... The compile is now complaining about 'cout' and 'endl' being "undeclared in namespace 'std'" and "*blah blah* is private *blah blah* within this context". I've seen people mention these errors under gcc 2.95.3, but heard they where fixed in 3.0.x... I have a feeling I am missing an environmental variable or something, and that g++ is using the wrong files. Help! ----Steve Stephen Amadei Dandy.NET! CTO Atlantic City, NJ