Weather Station

From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 4 Apr 2002 04:23:20 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 184 ************************************************** Wednesday 03 April 2002 Number 184 ************************************************** Subjects for today 1 Re: Hi folks! : Mikkel C. Simonsen" 2 unixos2.com : Ted Sikora 3 Re: ln : Ted Sikora 4 Re: Wrong OBJ format when building BZIP2 : Holger Veit 5 Re: Need some help builing GETTEXT : John Poltorak 6 Re: LX data pages : Gerhard Arnecke" 7 Re: iconv.a : Holger Veit 8 Installing Autoconf v2.53 using different shells : John Poltorak 9 Re: Wrong OBJ format when building BZIP2 : Andrew Zabolotny" 10 Re: iconv.a : Andrew Zabolotny" 11 Re: Wrong OBJ format when building BZIP2 : Andrew Zabolotny" 12 Re: Boost. Battle II. : Andrew Zabolotny" 13 Re: Wrong OBJ format when building BZIP2 : Andrew Zabolotny" 14 Re: Need some help builing GETTEXT : Andrew Zabolotny" 15 GREP build failure : John Poltorak 16 ln : John Poltorak 17 Re: Hi folks! : Mikkel C. Simonsen" 18 Re: ln : John Poltorak 19 Re: ln : csaba.raduly at sophos.com 20 Passing parameters : John Poltorak 21 Re: Passing parameters : John Poltorak 22 Building GNU Text Utils : John Poltorak 23 Re: unixos2 check : Andreas Buening 24 Re: iconv.a : Andreas Buening 25 Re: Wrong OBJ format when building BZIP2 : Andreas Buening **= Email 1 ==========================** Date: Thu, 04 Apr 2002 04:01:48 +0100 From: "Mikkel C. Simonsen" Subject: Re: Hi folks! Jack Troughton wrote: > > Hi there! > > I suddenly find myself in need of a good bind... which is the current > port right now? 8.2.4 - works very well. If you (or somebody else) need a PM zone-file editor let me know... > I downloaded the 824 port from Hobbes, but can't get on to the > unixos2.com ftp site to see what they have there... hence my asking here. There are some changes in the Bind 9 code that makes it hard to compile on OS/2 (or so I've heard...). But 8.2.4 works great. > Any comments on the ddns that's included in the new stacks? It used to be Bind 4 based - don't know about the newer versions. Best regards, Mikkel C. Simonsen > Regards, > > Jack > > (who just got ecomstation.ca and consultron.ca registered and wants to > set it up) > > -- > ------------------------------------------------------------------- > * Jack Troughton jake at jakesplace.dhs.org * > * http://jakesplace.dhs.org ftp://jakesplace.dhs.org * > * MontrＢl PQ Canada news://jakesplace.dhs.org * > ------------------------------------------------------------------- **= Email 2 ==========================** Date: Thu, 04 Apr 2002 09:02:56 -0500 From: Ted Sikora Subject: unixos2.com This is a multi-part message in MIME format. --------------A9B04F4921CA7374E8F1DE4F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The bandwidth increase is scheduled for tomorrow. Couldn't come sooner. Ftp has been at it's limit for several days now. I'll take the limit off then. I redid the site a bit using all php for a change. There's a new user pages section I added. It puts your url on unixos2.com within it's framework. Perfect for users own machines with no dns. Just put your ip/url in the script below and send it to me. We can use some XFree86 howto's etc. -- Ted Sikora tsikora at ntplx.net --------------A9B04F4921CA7374E8F1DE4F Content-Type: text/html; charset=us-ascii; name="sample.php" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sample.php" Weather Station
--------------A9B04F4921CA7374E8F1DE4F-- **= Email 3 ==========================** Date: Thu, 04 Apr 2002 09:43:23 -0500 From: Ted Sikora Subject: Re: ln John Poltorak wrote: > > Does anyone know which Slackware package includes ln ? > > -- > John fileutls.zip -- Ted Sikora tsikora at ntplx.net **= Email 4 ==========================** Date: Thu, 4 Apr 2002 09:59:50 +0200 From: Holger Veit Subject: Re: Wrong OBJ format when building BZIP2 On Wed, Apr 03, 2002 at 01:11:38PM -0500, Henry Sobotka wrote: > Holger Veit wrote: > > > > You are implying that the .o file that results from the compile is effectively > > an OMF file? This would solve certain problems with makefiles, but will cause > > severe problems when touched with the wrong linker/archivers. If true, it > > sounds to me like a very bad idea (OTOH, it would be good to abolish the > > OMF files entirely, rather use a separate conversion utility if one really > > wanted to have .obj files for some external compile. > > What's the rationale behind the statement in the EMX docs that OMF is > better for DLLs? Years ago I asked EM about it and just got a "Why would > you want to do it any other way?" reply. The only reason in favor of OMF I could imagine is that the linking process is done by the native link/link386/ilink programs, which "are supposed to know what they should produce." It turned out, though, that a synthetical LX file (one not created by link*) is works fine as well, as long as it has the correct layout and the appropriate flags set. Recent link386 versions (means: several years old meanwhile) can generate compressed ITERATED-II pages which might result in smaller binaries under certain circumstances. This is the main difference. Since link* only accept OMF as input, this could be an explanation for the historical comment in EMX docs on usage of OMF: EM probably was unsure about future directions of the executable format, so stay with the "safe" link386 - OMF, however, is Intel's standard and likely to be supported further in the future. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 5 ==========================** Date: Thu, 4 Apr 2002 10:16:25 +0000 From: John Poltorak Subject: Re: Need some help builing GETTEXT On Thu, Apr 04, 2002 at 12:52:03PM +0400, Andrew Zabolotny wrote: > On Wed, 3 Apr 2002 21:15:39 +0000, John Poltorak wrote: > > >An INTL.DLL has now mysteriously appeared within GETTEXT after hitting a > >random sequence of ketstrokes (never to be repeated) however when I view > >the file, I don't see any reference to _nl_msg_cat_cntr which is what I > >was hoping to find... > :-) The mysterious sequence in question was Ctrl+C. You got an incomplete DLL I > believe. Have you tried the latest ld.exe/emxbind.exe? I have copied all the gcc v3.0.3 bin programs over those from v2.8.1 so I assume so... One problem I have with the compile is this:- ../intl/localcharset.c:322: warning: unsigned int format, long unsigned int arg (arg 3) gcc -c -Wall -Zmt -I. -I../ -I../intl -I../src -I../lib -DHAVE_CONFIG_H -DLIBDIR=\"/usr/lib\" -DLOCALEDIR=\"/usr/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/share/locale\" -DPROJECTSDIR=\"/usr/share/gettext/projects\" -DGETTEXTJAR=\"/usr/share/gettext/gettext.jar\" -s -O2 -o out/release/intl/localename.o ../intl/localename.c gcc -c -Wall -Zmt -I. -I../ -I../intl -I../src -I../lib -DHAVE_CONFIG_H -DLIBDIR=\"/usr/lib\" -DLOCALEDIR=\"/usr/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/share/locale\" -DPROJECTSDIR=\"/usr/share/gettext/projects\" -DGETTEXTJAR=\"/usr/share/gettext/gettext.jar\" -s -O2 -o out/release/intl/osdep.o ../intl/osdep.c 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 To get it to compile I have been commenting out line 97 of intl\os2compat.c which may cause problems elsewhere. Can you suggest why I get this error? > Greetings, > _\ndy -- John **= Email 6 ==========================** Date: Thu, 04 Apr 2002 10:33:10 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: LX data pages Conc. data pages in LX - EXE format: The Object page table provides information about a logical page in an object. A logical page may be an enumerated page, a pseudo page or an iterated page The structure of the object page table in conjunction with the structure of the object table allows for efficient access of a page when a page fault occurs, while still allowing the physical page data to be located in the preload page, demand load page or iterated data page sections in the linear EXE module. The logical page entries in the Object Page Table are numbered starting from one. The Object Page Table is parallel to the Fixup Page Table as they are both indexed by the logical page number. Each Object Page Table entry has the following format: 63 32 31 16 15 0 00h PAGE DATA OFFSET DATA SIZE FLAGS Object Page Table Entry PAGE DATA OFFSET = DD Offset to the page data in the EXE file. This field, when bit shifted left by the PAGE OFFSET SHIFT from the module header, specifies the offset from the beginning of the Preload Page section of the physical page data in the EXE file that corresponds to this logical page entry. The page data may reside in the Preload Pages, Demand Load Pages or the Iterated Data Pages sections. A page might not start at the next available alignment boundary. Extra padding is acceptable between pages as long as each page starts on an alignment boundary. For example, several alignment boundarys may be skipped in order to start a frequently accessed page on a sector boundary. If the FLAGS field specifies that this is a Zero-Filled page then the PAGE DATA OFFSET field will contain a 0. If the logical page is specified as an iterated data page, as indicated by the FLAGS field, then this field specifies the offset into the Iterated Data Pages section. The logical page number (Object Page Table index), is used to index the Fixup Page Table to find any fixups associated with the logical page. DATA SIZE = DW Number of bytes of data for this page. This field specifies the actual number of bytes that represent the page in the file. If the PAGE SIZE field from the module header is greater than the value of this field and the FLAGS field indicates a Legal Physical Page, the remaining bytes are to be filled with zeros. If the FLAGS field indicates an Iterated Data Page, the iterated data records will completely fill out the remainder. FLAGS = DW Attributes specifying characteristics of this logical page. The bit definitions for this word field follow, 00h = Legal Physical Page in the module (Offset from Preload Page Section). 01h = Iterated Data Page (Offset from Iterated Data Pages Section). 02h = Invalid Page (zero). 03h = Zero Filled Page (zero). 04h = Range of Pages. 05h = Compressed Page (Offset from Preload Pages Section). Source: Linear eXecutable Module Format( Revision 8) **= Email 7 ==========================** Date: Thu, 4 Apr 2002 11:02:09 +0200 From: Holger Veit Subject: Re: iconv.a On Thu, Apr 04, 2002 at 12:39:18PM +0400, Andrew Zabolotny wrote: > On Wed, 3 Apr 2002 11:51:47 +0200, Holger Veit wrote: [...] > >The point is that such source code relies on an implicit assumption that the > >variables are correctly initialized (usually with 0) because when the data > >segment is loaded, it will have some initial value pattern. But such an > >implicit assumption is a Bad Thing(tm); so the code is defective in some way. > Not true. Data segments are guaranteed to be zero-filled at startup (and in LX > format there is almost no difference between initialized and uninitialized data > - both are marked as "data" pages). And this is so in any decent operating > system. Alas I don't remember where I have read this (about zero filling), > perhaps in cp.inf or in the docs on the LX format. The code is generally broken - we talk about porting here. There may be a guarantee that the LX loader on OS/2 initializes the section with zeroes, but will it be the case as well on Linux, FreeBSD, DOS, CrayOS, whatever? That the code might work on OS/, because it zeroes the region, *is* exactly the implicit assumption which is nowhere specified in the C language. I have analyzed and fixed an unknown number of programs which behaved differently on different systems exactly because the original writer tested it on some platform where it happened to work, but which *sometimes* failed on other platforms - the original writer has literally written code to work during the right phase of moon or during sunny weather. This happens more often than you dare to believe. This *is* broken code. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 8 ==========================** Date: Thu, 4 Apr 2002 12:23:29 +0000 From: John Poltorak Subject: Installing Autoconf v2.53 using different shells I've just been comparing BASH and PDKSH when installing Autoconf v2.53 and found that it fails to install properly when using PDKSH. Has anyone else found this? The problems seem to stem from:- autom4te.: cannot open /usr/local/share/autoconf/autom4te.cfg: No such file or directory at /unixos2/workdir/autoconf-2.53/bin/autom4te. line 428 but no such error msg occurs when BASH is used. Autoconf is available here:- ftp://ftp.gnu.org/pub/gnu/autoconf/autoconf-2.53.tar.gz -- John **= Email 9 ==========================** Date: Thu, 04 Apr 2002 12:34:31 +0400 From: "Andrew Zabolotny" Subject: Re: Wrong OBJ format when building BZIP2 On Wed, 3 Apr 2002 09:43:41 +0000, John Poltorak wrote: >So does this no longer work? >CFLAGS=-Wall -Winline -O3 -fomit-frame-pointer -fno-strength-reduce -Zomf >-Zmtd $(BIGFILES) >blocksort.obj: blocksort.c > at cat words0 > $(CC) $(CFLAGS) -c blocksort.c The simplest way to fix your case is to add "-o $ at " to CFLAGS, e.g: CFLAGS=-Wall -Winline -O3 -fomit-frame-pointer -fno-strength-reduce -Zomf -Zmtd $(BIGFILES) -o $ at Greetings, _\ndy **= Email 10 ==========================** Date: Thu, 04 Apr 2002 12:39:18 +0400 From: "Andrew Zabolotny" Subject: Re: iconv.a On Wed, 3 Apr 2002 11:51:47 +0200, Holger Veit wrote: >As said, this typically happens when you declare variables in a DLL segment, >but don't initialize them with a default value. Exactly. Old emxbind's were unable to export DLL symbols from the .bss segment. I've fixed it and now it does. >The point is that such source code relies on an implicit assumption that the >variables are correctly initialized (usually with 0) because when the data >segment is loaded, it will have some initial value pattern. But such an >implicit assumption is a Bad Thing(tm); so the code is defective in some way. Not true. Data segments are guaranteed to be zero-filled at startup (and in LX format there is almost no difference between initialized and uninitialized data - both are marked as "data" pages). And this is so in any decent operating system. Alas I don't remember where I have read this (about zero filling), perhaps in cp.inf or in the docs on the LX format. Greetings, _\ndy **= Email 11 ==========================** Date: Thu, 04 Apr 2002 12:42:35 +0400 From: "Andrew Zabolotny" Subject: Re: Wrong OBJ format when building BZIP2 On Wed, 3 Apr 2002 10:29:06 +0000, John Poltorak wrote: >I added '-o $ at ' in CFLAGS and this worked OK, although the binaries are >now linked with GCC303M which becomes a required DLL and the EXEs are >slightly bigger than before. RTFM (doc/os2usage): --------- cut If you want to use -Zcrtdll and not depend on gcc29027.dll (par example) you should link with libgcc by using -lgcc (or -lgpp for C++ programs with exceptions). From version 2.95.2 the libgcc library is provided in two flavours: single-threaded (e.g. gcc2952s.dll) and multithreaded (gcc2952m.dll). --------- cut Greetings, _\ndy **= Email 12 ==========================** Date: Thu, 04 Apr 2002 12:43:30 +0400 From: "Andrew Zabolotny" Subject: Re: Boost. Battle II. On Wed, 3 Apr 2002 15:48:40 +0100, csaba.raduly at sophos.com wrote: >>I noticed the GCC V.3 libraries put a lot of files in g++-v3 that >>look like .h files, but they have no extension. What's with that? >STL (standard template library) most likely >:-(whoever had the idea of no extensions should be beaten)-: Agree. Any volunteers? ;-) Greetings, _\ndy **= Email 13 ==========================** Date: Thu, 04 Apr 2002 12:50:37 +0400 From: "Andrew Zabolotny" Subject: Re: Wrong OBJ format when building BZIP2 On Wed, 03 Apr 2002 13:11:38 -0500, Henry Sobotka wrote: >What's the rationale behind the statement in the EMX docs that OMF is >better for DLLs? Years ago I asked EM about it and just got a "Why would >you want to do it any other way?" reply. :-) The reason is that ld/emxbind have (had) several limits. First, it used to add the damn 32MB heap segment to every DLL, and DLLs don't need a heap segment. Second, it weren't able to export .bss symbols. Third, it was *very* slow on exporting lots of entries (such as in qt.dll - it worked about five minutes on ~ 17000 exports!). Fourth, emxbind adds the unneedingly large stub (which looks for EMX.EXE under DOS). Maybe there are some other limits, but I haven't observed them yet, thus I presume they are of minor importance. The tools from the latest gcc 3.0.3 fixes first three limitations above, and "lxlite /c:minstub" fixes the fourth one. Thus you can relax and safely build DLLs from a.out files now. Greetings, _\ndy **= Email 14 ==========================** Date: Thu, 04 Apr 2002 12:52:03 +0400 From: "Andrew Zabolotny" Subject: Re: Need some help builing GETTEXT On Wed, 3 Apr 2002 21:15:39 +0000, John Poltorak wrote: >An INTL.DLL has now mysteriously appeared within GETTEXT after hitting a >random sequence of ketstrokes (never to be repeated) however when I view >the file, I don't see any reference to _nl_msg_cat_cntr which is what I >was hoping to find... :-) The mysterious sequence in question was Ctrl+C. You got an incomplete DLL I believe. Have you tried the latest ld.exe/emxbind.exe? Greetings, _\ndy **= Email 15 ==========================** Date: Thu, 4 Apr 2002 14:51:06 +0000 From: John Poltorak Subject: GREP build failure When trying to build GREP v2.5 the compile fails in the same module as GETTEXT - os2compat.c. gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" -DIN_LIBINTL -DHAVE_CONFIG_H -I.. -I. -I../intl -g -O2 osdep.c In file included from osdep.c:20: os2compat.c:52: parse error before "char" os2compat.c: In function `os2_initialize': os2compat.c:62: `_os2_libdir' undeclared (first use in this function) os2compat.c:62: (Each undeclared identifier is reported only once os2compat.c:62: for each function it appears in.) os2compat.c:107: warning: passing arg 1 of `strcpy' discards qualifiers from pointer target type make[1]: *** [osdep.o] Error 1 What's wrong here? -- John **= Email 16 ==========================** Date: Thu, 4 Apr 2002 15:18:41 +0000 From: John Poltorak Subject: ln Does anyone know which Slackware package includes ln ? -- John **= Email 17 ==========================** Date: Thu, 04 Apr 2002 15:28:52 +0100 From: "Mikkel C. Simonsen" Subject: Re: Hi folks! Jack Troughton wrote: > > > If you (or somebody else) need a PM zone-file editor let me know... > > Sure... what's a zone file editor? It creates the domain files, like the one below: $TTL 1d ; minimum TTL at SOA ns1.sirocco.dk. hostmaster.sirocco.dk. ( 2002040401 ; serienr 1d ; slave refresh 1h ; slave retry 4w ; slave expire 1h ; negativ TTL ) test.dk. NS ns1.sirocco.dk. test.dk. NS ns2.sirocco.dk. test.dk. A 212.242.69.175 www.test.dk. CNAME test.dk. test.dk. MX 10 post.sirocco.dk. test.dk. MX 20 mx2.sirocco.dk. (it's a work of fiction - the domain is not mine). > I've got to crash course on how name > servers work... > > Ok, so the hobbes server is good then. Guess I got to go read up on how > it works so I can set it up. If you use the editor, all you have to do is type-in the names and addresses of your name servers in the config file, and start adding domains. The editor comes with a named.conf file for bind. I just have to package it up later today... > > It used to be Bind 4 based - don't know about the newer versions. > > AFAIK, it still is... was wondering if that mattered a great deal or > not. You're always told to switch to Bind 8 ASAP, but I'm not sure if there are any real problems with Bind 4. > It does do the dynamic name stuff in conjunction with the dhcp > server, which I thought might be useful in the future. Right now, > though, I just need to get a couple of name servers running... as well > as getting a second IP from my provider to put the backup server on. You don't have to run the secondary server yourself - you can just use somebody elses for that. Best regards, Mikkel C. Simonsen > >>(who just got ecomstation.ca and consultron.ca registered and wants to > >>set it up) > > -- > ------------------------------------------------------------------- > * Jack Troughton jake at jakesplace.dhs.org * > * http://jakesplace.dhs.org ftp://jakesplace.dhs.org * > * Montr饌l PQ Canada news://jakesplace.dhs.org * > ------------------------------------------------------------------- **= Email 18 ==========================** Date: Thu, 4 Apr 2002 16:02:43 +0000 From: John Poltorak Subject: Re: ln On Thu, Apr 04, 2002 at 09:43:23AM -0500, Ted Sikora wrote: > John Poltorak wrote: > > > > Does anyone know which Slackware package includes ln ? > > > > -- > > John > > fileutls.zip I guess we should include this ln.cmd in the UnixOS/2 version:-... at echo off cp %1 %2 Does that seem OK? BTW the GNU File Utils include:- chgrp chmod chown cp dd df dircolors du ginstall ln ls mkdir mkfifo mknod mv rm rmdir shred sync touch Some of these are missing from the OS/2 port, although the latest is v4.1 but we are only at v3.16. Is anyone working on a new port? > -- > Ted Sikora -- John **= Email 19 ==========================** Date: Thu, 4 Apr 2002 16:11:34 +0100 From: csaba.raduly at sophos.com Subject: Re: ln On 04/04/2002 17:02:43 John Poltorak wrote: > >I guess we should include this ln.cmd in the UnixOS/2 version:-... > > at echo off >cp %1 %2 > > >Does that seem OK? > That'll fail for "ln -s foo bar" You need REXX with PARSE ARG The easiest workaround is to "cp cp.exe ln.exe" :-) (but cp -s fails under OS/2) -- Csaba R疆uly, 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 20 ==========================** Date: Thu, 4 Apr 2002 16:34:13 +0000 From: John Poltorak Subject: Passing parameters Can someone explain the problem here when I try passing parameters to configure? :- >cat parms grep;grep-2.5;;;--without-included-regex --without-included-gettext;. --------------------------------- IFS=';' read p1 ARCHIVE CFLAGS LDFLAGS PARMS SRC < parms echo PARMS $PARMS configure $PARMS ------------------------------------------ configure: error: invalid package name: included-regex --without-included-gettext -- John **= Email 21 ==========================** Date: Thu, 4 Apr 2002 20:46:58 +0000 From: John Poltorak Subject: Re: Passing parameters On Thu, Apr 04, 2002 at 04:34:13PM +0000, John Poltorak wrote: > > Can someone explain the problem here when I try passing parameters to > configure? :- > > > > >cat parms > grep;grep-2.5;;;--without-included-regex --without-included-gettext;. > > > --------------------------------- > IFS=';' > read p1 ARCHIVE CFLAGS LDFLAGS PARMS SRC < parms > > echo PARMS $PARMS > > configure $PARMS > ------------------------------------------ > > > configure: error: invalid package name: included-regex --without-included-gettext After some experimentation, it appears that IFS is the culprit here. Don't ask me why it makes a difference, but if I set IFS to ' ' after the input line has been parsed, it works as I would expect. I'd be interested in an explanation, if anyone has one... -- John **= Email 22 ==========================** Date: Thu, 4 Apr 2002 21:05:55 +0000 From: John Poltorak Subject: Building GNU Text Utils There was an updated port of the GNU Text Utils last December which removed a lot of the old redundant code from previous ports. Is it possible to build it using Autoconf v2.53? I'd like to try rebuilding it with gcc v3.0.3 and don't want to re-install an older version of Autoconf unless I have to. -- John **= Email 23 ==========================** Date: Thu, 04 Apr 2002 21:49:34 +0100 From: Andreas Buening Subject: Re: unixos2 check John Poltorak wrote: > > 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... No, definitely not. a) You don't want a complete system check if you install any mini package b) the script may become loooong on the long term which means slooow. c) The idea is that you run this script only once to make your build environment "compatible". After that you don't need it. [snip] > > > 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. Okay, a warning may be a better reaction, but if you don't have UNIXROOT it's likely that you've missed something. [snip] > > > 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 The script tests how a "real" configure script would see your environment, not how it should see it. Therefore if you don't have CONFIG_SITE and there's no config.site in your prefix tree then there's no config.site to load. > > > 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. Yes, if you have one. ;-) 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 24 ==========================** Date: Thu, 04 Apr 2002 21:49:42 +0100 From: Andreas Buening Subject: Re: iconv.a Holger Veit wrote: [_nl_msg_cat_cntr] To close this endless thread I've looked into the gettext sources. gettext 0.10.35 had a "int _nl_msg_cat_cntr = 0;" statement which seems to have been removed later. At least gettext 0.10.39 and above simply use "int _nl_msg_cat_cntr;" I don't know why. However, I had no problems to compile gettext 0.10.39 with "emxexp -u" and gcc 2.95, so emxbind can't be the only reason for this. 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 25 ==========================** Date: Thu, 04 Apr 2002 21:49:45 +0100 From: Andreas Buening Subject: Re: Wrong OBJ format when building BZIP2 Andrew Zabolotny wrote: > > On Wed, 3 Apr 2002 08:25:57 +0000, John Poltorak wrote: > > >I get OBJ files created with a .o extension. > >It has built correctly in the past. Could the difference be accounted for > >by my use of gcc 3.0.3 instead of 2.8.1? > Exactly. At some point I've decided to drop off the patches that made gcc > generate .o or .obj files depending on whether the -Zomf switch is given or not. > This was caused by a major architectural change to the gcc preprocessor in gcc > 3.0 and I've decided to drop these dirty patches altogether. If you want .obj > files you have to explicitely say "-o file.obj". 8-O Oh, no, please don't! Have you ever thought about how many Makefiles you've broken with this? I don't even know whether some of my own stuff relies on this. Using .c.obj: $(CC) $(CFLAGS) -c $< is one really natural thing if you know which flags you use. -Zomf is none of those -fno-template-align-funny-stuff options that nobody(*) really uses and that you can remove without serious trouble. (*) nobody I've ever heard of. 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.