From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 31 Mar 2002 04:20:53 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 180 ************************************************** Saturday 30 March 2002 Number 180 ************************************************** Subjects for today 1 Re: Re: Building Perl.exe as a test of manhood ;-) : Dave and Natalie" 2 Re: /usr/include/ncurses : Thomas Dickey 3 unixos2 check : John Poltorak 4 Re: Re: Building Perl.exe as a test of manhood ;-) : John Poltorak 5 /usr/include/ncurses : John Poltorak 6 Re: Re: Building Perl.exe as a test of manhood ;-) : Dave and Natalie" 7 Re: Gnat 3.14p OS/2 gnat.adc file broken? : Vincent Marciante 8 Re: Gnat 3.14p OS/2 gnat.adc file broken? : Thomas Dickey 9 Re: unixos2 check : Andreas Buening 10 Re: unixos2 check : John Poltorak **= Email 1 ==========================** Date: Sun, 31 Mar 2002 01:56:49 -0800 From: "Dave and Natalie" Subject: Re: Re: Building Perl.exe as a test of manhood ;-) On Thu, 28 Mar 2002 15:11:04 -0800, Dave and Natalie wrote: > >Well I rebooted, copied pdksh's sh to /usr/bin and configure ran fine. No heavy memory use, no complaints about tr.exe. >Make failed with a bunch of unresolved externals such as >e:\emx\lib\db.lib(rec_search.obj) : error L2029: 'errno' : unresolved external >e:\emx\lib\db.lib(munmap.obj) : error L2029: 'errno' : unresolved external >e:\emx\lib\db.lib(rec_seq.obj) : error L2029: 'errno' : unresolved external >... > >I'd imagine I need to update db_mt but right now I can't get thru to ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/ Well after updating db_mt I still get the same errors about unresolved externals in db.lib Dave **= Email 2 ==========================** Date: Sun, 31 Mar 2002 07:23:40 -0500 From: Thomas Dickey Subject: Re: /usr/include/ncurses On Sun, Mar 31, 2002 at 10:27:05AM +0000, John Poltorak wrote: > > Is there a configure option for installing all NCURSES headers into > /usr/include/ncurses rather than the parent directory ? --disable-overwrite -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 3 ==========================** Date: Sun, 31 Mar 2002 10:06:30 +0000 From: John Poltorak Subject: unixos2 check On Sat, Mar 30, 2002 at 05:51:37PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > On Fri, Mar 29, 2002 at 05:10:29PM +0100, Andreas Buening wrote: > > [snip] > > > > Btw. do you already have a unixos2-check script that tests > > > your build environment? > > > > Not at present, because I don't think we have established all the > > essential parts of that build environment. There are too many duplicates > > of REGEX and INTL as yet, and the behavior of various SHELLs is still > > unpredicatable. > > > > > I have some ideas how this could be implemented. > > > > Let's hear them then... > > I've written some autoconf code but I cannot upload these file > to ftp.unixos2.com/incoming (no permission) I've uploaded it to:- ftp://unixos2.com/incoming/test/unixos2-check-0_1.zip How do you suggest it should be used? As a standalone script or integrated into autoconf? BTW I think any TLA version of UnixOS/2 should be ux2 rather than uo2. That is the reference we already have in a couple of places so I think it makes sense to be consistant. I'm not sure if the UNIXROOT variable should be manadatory for builds... I'm doing quite a bit of testing at the moment and various elements of what would normally be under a single UNIXROOT drive are spread over a number of drives. Isn't it sufficient to use PATH and other existing envars to verify the environment. The unixos2 check script would probably work best with a config.site file which included things like:- export ac_executable_extensions=".exe" I would suggest that a sample config.site file was included in a subsequent release of your script. It looks like a useful check that could save many wasted hours over time. > bye, > Andreas -- John **= Email 4 ==========================** Date: Sun, 31 Mar 2002 10:14:16 +0000 From: John Poltorak Subject: Re: Re: Building Perl.exe as a test of manhood ;-) On Sun, Mar 31, 2002 at 01:56:49AM -0800, Dave and Natalie wrote: > On Thu, 28 Mar 2002 15:11:04 -0800, Dave and Natalie wrote: > > > > >Well I rebooted, copied pdksh's sh to /usr/bin and configure ran fine. No heavy memory use, no complaints about tr.exe. > >Make failed with a bunch of unresolved externals such as > >e:\emx\lib\db.lib(rec_search.obj) : error L2029: 'errno' : unresolved external > >e:\emx\lib\db.lib(munmap.obj) : error L2029: 'errno' : unresolved external > >e:\emx\lib\db.lib(rec_seq.obj) : error L2029: 'errno' : unresolved external > >... > > > >I'd imagine I need to update db_mt but right now I can't get thru to ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/ > > Well after updating db_mt I still get the same errors about unresolved externals in db.lib > Dave > Did you create a db.lib from the new db.a? -- John **= Email 5 ==========================** Date: Sun, 31 Mar 2002 10:27:05 +0000 From: John Poltorak Subject: /usr/include/ncurses Is there a configure option for installing all NCURSES headers into /usr/include/ncurses rather than the parent directory ? It seems much tidier to keep them all in a seperate directory IMV. -- John **= Email 6 ==========================** Date: Sun, 31 Mar 2002 11:20:06 -0800 From: "Dave and Natalie" Subject: Re: Re: Building Perl.exe as a test of manhood ;-) On Sun, 31 Mar 2002 10:14:16 +0000, John Poltorak wrote: >> >I'd imagine I need to update db_mt but right now I can't get thru to ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/ >> >> Well after updating db_mt I still get the same errors about unresolved externals in db.lib >> Dave >> > > >Did you create a db.lib from the new db.a? Yes, I tried. The other day I finally got around to installing GCC ver3.03 andone of the steps is to run make in /emx/lib. and /emx/lib/gcc-lib/i386-pc-os2_emx/$(gcc-version)/. Unluckily these makefiles do not work due to this line "emxomf -w -o $ at $<". My emxomf doesn't seem to support the -w parameter so I removed it, then the make ran. Do I need an updated emxomf? What is the -w parameter sopposed to do? Ok I found the updated emxomf which supports -w. Will try again. Dave **= Email 7 ==========================** Date: Sun, 31 Mar 2002 12:31:25 -0500 From: Vincent Marciante Subject: Re: Gnat 3.14p OS/2 gnat.adc file broken? Kees de LezenneCoulander wrote: > > > > I have never had a need for using gnat.adc, but I tried one > this morning, and it seemed to work OK (using Gnat 3.14p for OS/2). > If the problem has not yet solved itself, you are welcome to send > me your gnat.adc (and any small files it may require) so that I can > try it out on my system. > I'm still trying to narrow things down but I think that the problem has to do with the end of the gnat.adc file: If "--" is the last line of the file then the "syntax error" message no longer appears and it seems to work. BTW, I used the same editor to create the gnat.adc file as I use to create Ada source files. I'm installing eCS 1.0 to see if there is any difference. Vinny > > **= Email 8 ==========================** Date: Sun, 31 Mar 2002 13:06:24 -0500 From: Thomas Dickey Subject: Re: Gnat 3.14p OS/2 gnat.adc file broken? On Sun, Mar 31, 2002 at 12:31:25PM -0500, Vincent Marciante wrote: > Kees de LezenneCoulander wrote: > > > > > > > > I have never had a need for using gnat.adc, but I tried one > > this morning, and it seemed to work OK (using Gnat 3.14p for OS/2). > > If the problem has not yet solved itself, you are welcome to send > > me your gnat.adc (and any small files it may require) so that I can > > try it out on my system. > > > > I'm still trying to narrow things down but I > think that the problem has to do with the end > of the gnat.adc file: > > If "--" is the last line of the file then the > "syntax error" message no longer appears and it > seems to work. perhaps you have no trailing newline on the file (some editors do this) > BTW, I used the same editor to create the gnat.adc > file as I use to create Ada source files. > > I'm installing eCS 1.0 to see if there is any difference. > > Vinny > > > > > > -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 9 ==========================** Date: Sun, 31 Mar 2002 14:14:47 +0100 From: Andreas Buening Subject: Re: unixos2 check John Poltorak wrote: > [unixos2-check] > I've uploaded it to:- > > ftp://unixos2.com/incoming/test/unixos2-check-0_1.zip > > How do you suggest it should be used? As a standalone script or integrated > into autoconf? Currently it's more like a demo. run ./configure [ --prefix=... ]. The final version may be a simple package that produces a unixos2-check (or ux2-check if you prefer). > BTW I think any TLA version of UnixOS/2 should be ux2 rather than uo2. > That is the reference we already have in a couple of places so I think it > makes sense to be consistant. Whatever you mean. The script name won't be our main problem. > I'm not sure if the UNIXROOT variable should be manadatory for builds... The idea is to check your build environment. This means it is intended to check for existence and consistency (and bugs!) of your env. vars, installed programs, shells, header files, libraries, whatever. If you haven't set UNIXROOT then there is most likely an error in your build environment. > I'm doing quite a bit of testing at the moment and various elements of > what would normally be under a single UNIXROOT drive are spread over a > number of drives. Isn't it sufficient to use PATH and other existing > envars to verify the environment. Currently it uses the normal autoconf mechanisms to find programs (which means PATH, not UNIXROOT). > The unixos2 check script would probably work best with a config.site file > which included things like:- > > export ac_executable_extensions=".exe" If you haven't set that variable the script will terminate. > I would suggest that a sample config.site file was included in a > subsequent release of your script. It looks like a useful check that could > save many wasted hours over time. It's a "normal" autoconf script. This means it will read you config.site from $CONFIG_SITE or from your prefix dir (!). If you use it with "--prefix=x:/my_prefix" it will test exactly the same environment that would be seen by any other build script with the same prefix dir. If it says ac_executable_extensions not defined then any other autoconf script won't see this var. 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 10 ==========================** Date: Sun, 31 Mar 2002 20:08:28 +0000 From: John Poltorak Subject: Re: unixos2 check On Sun, Mar 31, 2002 at 02:14:47PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > [unixos2-check] > > > I've uploaded it to:- > > > > ftp://unixos2.com/incoming/test/unixos2-check-0_1.zip > > > > How do you suggest it should be used? As a standalone script or integrated > > into autoconf? > > Currently it's more like a demo. run ./configure [ --prefix=... ]. > The final version may be a simple package that produces > a unixos2-check (or ux2-check if you prefer). Maybe it could be incorporated into the UnixOS/2 Autoconf package so it would automatically be invoked when running Autoconf on OS/2 and would verify that the build environment was correct at run time... > > BTW I think any TLA version of UnixOS/2 should be ux2 rather than uo2. > > That is the reference we already have in a couple of places so I think it > > makes sense to be consistant. > > Whatever you mean. The script name won't be our main problem. TLA = three letter acronym... I'm suggesting that AC_UO2_PATH should AC_UX2_PATH etc... > > I'm not sure if the UNIXROOT variable should be manadatory for builds... > > > The idea is to check your build environment. This means it > is intended to check for existence and consistency (and bugs!) > of your env. vars, installed programs, shells, header files, > libraries, whatever. If you haven't set UNIXROOT then there > is most likely an error in your build environment. Not necessarily, since %UNIXROOT% shouldn't need to be set when building anything. > > > I'm doing quite a bit of testing at the moment and various elements of > > what would normally be under a single UNIXROOT drive are spread over a > > number of drives. Isn't it sufficient to use PATH and other existing > > envars to verify the environment. > > Currently it uses the normal autoconf mechanisms to find > programs (which means PATH, not UNIXROOT). > > > > The unixos2 check script would probably work best with a config.site file > > which included things like:- > > > > export ac_executable_extensions=".exe" > > If you haven't set that variable the script will terminate. I'm not sure how many people would know how to set it. By including a default config.site it may work automagically > > I would suggest that a sample config.site file was included in a > > subsequent release of your script. It looks like a useful check that could > > save many wasted hours over time. > > It's a "normal" autoconf script. This means it will read > you config.site from $CONFIG_SITE or from your prefix dir (!). Yes, but I'm suggesting that we should try devising a standard config.site file for use in the building of UnixOS/2 packages and include it as a sample with your unixos2 checker. > bye, > Andreas -- John