Date: Thu, 30 Jun 2005 00:05:18 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 571 ************************************************** Wednesday 29 June 2005 Number 571 ************************************************** Subjects for today 1 GCC 3.3.5 / LIBC 0.6 Beta 5 : Knut St. Osmundsen" 2 Re: The OS/2 and eCS Ecosystem : billn 1 Re: Warpstock 2005 : Lewis G Rosenthal 2 Re: The OS/2 and eCS Ecosystem : Dave Yeo" 3 Re: Warpstock 2005 : Lewis G Rosenthal 3 Re: Warpstock 2005 : John Poltorak 4 Re: The OS/2 and eCS Ecosystem : John Poltorak **= Email 1 ==========================** Date: Tue, 28 Jun 2005 18:24:56 +0200 From: "Knut St. Osmundsen" Subject: GCC 3.3.5 / LIBC 0.6 Beta 5 Hi, a new build is finally available from the netlabs ftp: ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-beta5-doc.zip (37KB) ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-beta5.zip (everything 36MB) As usual there are a lot of changes, additions and fixes. See the release notes quoted below and the ChangeLog.LIBC which is found in both the above zip files. The TODO list for LIBC v0.6 is pretty short now and the larger bit is about bugfixing. So, please take it for a run and post bug reports on the support forums. Patches should be sent me directly or to the gcc at netlabs.org mailing list (if that still works). Here are the release notes: GCC v3.3.5 / LIBC v0.6 - Beta 5: -------------------------------- Thanks to Lorne, Froloff, nickk and Andy for sending me patches, debugging problems and/or testing fixes. New features: o Added support for __declspec(dllexport), _Export and __declspec(dllimport), the latter being a stub. This also included adding N_EXP to the a.out format. o Lot's of math stuff, mostly untested. o Optimized zeroing of new file space in ftruncate and chsize with knowlegde about the filesystem. HPFS, JFS and FAT will do the zeroing for us. o Support for unlocked stdio, with both BSD and GNU extensions implemented. o Execute .cmd, .bat, .btm and hash-bang scripts. o Respect single quotes in argument handling (sed craze). o Ported fts.h and the BSD implementation. o Ported BSD sysctl. (Does not include the tcpip v4.1 sysctl() bits yet.) o Ported the FreeBSD implementation of SysV semaphores and shared memory. o Env.var. LIBC_THREAD_MIN_STACK_SIZE can be used to specify the minimum stack size for new threads. The default minimum is 4096 bytes. o Ported (lib)intl from glibc. o New gcc arguments -Zargs-wild and -Zargs-resp. o New functions (might not be 100% correct): __bindtextdomain(), __dcgettext(), __dcigettext(), __dcngettext(), __dgettext(), __dngettext(), __gettext(), __gettext_extract_plural(), __gettext_free_exp(), __gettextparse(), _nl_make_l10nflist(), __ngettext(), __textdomain(), _nl_locale_name(), on_exit(), nanosleep(), wmemcpy(), wmemchr(), wmemcmp(), wmemmove(), wmemset(), gethrtime(), _nl_expand_alias(), _nl_explode_name(), _nl_normalize_codeset(), __fbufsize(), __fpending(), getpriority(), setpriority(), nice(), sysctl(), sysctlbyname(), sysctlnametomib(), fchmod(), _chdir_os2(), fts_children(), fts_close(), fts_get_clientptr(), fts_get_stream(), fts_open(), fts_read(), fts_set(), fts_set_clientptr(), mkfifo(), futimes(), _getenv_int(), _getenv_long(), _getenv_longlong(), ftok(), semctl(), semget(), semop(), shmat(), shmctl(), shmdt(), shmget(), acosf(), acosh(), acoshf(), asinf(), asinh(), asinhf(), atan2f(), atanf(), atanh(), atanhf(), cabs(), cabsf(), cbrtf(), ceilf(), cimag(), cimagf(), cimagl(), conj(), conjf(), conjl(), cosf(), coshf(), creal(), crealf(), creall(), erf(), erfc(), erfcf(), erff(), exp2(), exp2f(), expf(), expm1(), expm1f(), truncf(), fabsf(), fdim(), fdimf(), fdiml(), fegetenv(), feholdexcept(), feraiseexcept(), fesetexceptflag(), feupdateenv(), floorf(), fma(), fmaf(), fmal(), fmax(), fmaxf(), fmaxl(), fmin(), fminf(), fminl(), fmodf(), frexpf(), hypotf(), ilogb(), ilogbf(), ilogbl(), ldexpf(), lgamma(), lgammaf(), llrint(), llrintf(), llround(), llroundf(), llroundl(), log10f(), log1p(), log1pf(), logb(), logbf(), logf(), lrint(), lrintf(), lround(), lroundf(), lroundl(), modff(), nearbyint(), nearbyintf(), nexttoward(), nexttowardf(), powf(), remainder(), remainderf(), remquo(), remquof(), rintf(), round(), roundf(), roundl(), scalbf(), scalbln(), scalblnf(), scalblnl(), scalbn(), scalbnf(), scalbnl(), signgam(), sinf(), sinhf(), sqrtf(), tanf(), tanhf(), tgamma(), drem(), dremf(), finite(), finitef(), gamma(), gammaf(), gammaf_r(), gamma_r(), j0(), j0f(), j1(), j1f(), jn(), jnf(), lgammaf_r(), lgamma_r(), scalb(), significand(), significandf(), powl(), y0(), y0f(), y1(), y1f(), yn(), ynf(), arc4random(), arc4random_addrandom(), arc4random_stir(), _mktemp(), mkdtemp(), mkstemps(), clearerr_unlocked(), feof_unlocked(), ferror_unlocked(), fgetc_unlocked(), fileno_unlocked(), flockfile(), ftrylockfile(), funlockfile(), getchar_unlocked(), getc_unlocked(), putchar_unlocked(), fputc_unlocked(), putc_unlocked(), fputs_unlocked(), puts_unlocked() and fread_unlocked(). Removed features: o smallcnv is gone. o old weak symbol handling in emxomf is gone. Bug fixes: o Numerous bugfixes in libc, see ChangeLog.LIBC for details. o Fixed problems with receiving signals during fork(). o Fixed bug in timer backend if the system had no exiting timers. Kudos to Froloff for noticing this. Known problems: o Static linking not possible - will be fixed. o Job control will only be applied to thread 1 in a process. This won't change. o Missing some process group interfaces required for job control. They'll show up soon. o The HLL debug info isn't working 100% correctly. Todos before LIBC06.DLL: 0. Make my way through the glibc testsuite. 1. New select() from Brian (aka nuke). 2. Missing job pgid functions. Enjoy! Kind Regards, knut PS. I hope this messages doesn't show up twice. My apologies if it does. **= Email 2 ==========================** Date: Tue, 28 Jun 2005 13:18:48 -0700 From: billn Subject: Re: The OS/2 and eCS Ecosystem Well, I'm going to give it a try with the new GCC 3.3.5b5. I've downloaded it, but am short on time now. I'll let you know. BillN Dave Yeo wrote: > > On Sun, 26 Jun 2005 13:24:17 -0700, billn wrote: > > > > >When you first used these tools, did it take you an hour? Or much > >longer? From your expert view, it's easy. From my (and others) POV, it > >is very complex, and not too well documented. > > > >Your outline does not include all the little details that are needed to > >make a working system. > > * Which version of the compiler and libraries for what use? > > * Installed on which drive or drives? > > * Which unzip? > > * Which utilities are necessary and which are useful? > > * "The rest can be done as needed." The rest of what? > > > > > > The problem is as Andy said there is a lot of weird interdependencies and different > projects need differrent tools. As an example I have 6 versions of GCC here. > 2.81, 2.95.3, 3.0.3, 3.2.1 all installed into the e:\EMX tree with simple batch files to make > whichever dominant, > 3.2.2. and 3.3.5 installed in I:\gcc322 and I:\usr for 3.3.5 using Knuts gccenv.cmd to setup > whichever Innotek_libc version. > Then I have Johns UX2BS setup on G: with another 2.81, F:\usr has most of my tools > installed. > I have XFree86 4.4 installed in f:\usr\X11R6 and XFree863.3.6 installed in f:\XFree86 and > an experimental Innotek_libc partial build of XFree 4.4 in I:\usr\X11R6(.bak) and have to > move this one around as my Mozilla build enviroment is also on I: and it finds > /usr/X11R6 and pulls in a bunch of stuff. > Lots of these are also symlinked to X: which is a TVFS drive and the symlinks can be > changed depending on required enviroment. > An example of a tool that we need a few different versions of is autoconf. Newer ports in > general use the newest 2.5.x versions and work pretty well out of the box thanks to > cygwin adding support for Windows but some projects eg Mozilla need 2.13 which > doesn't work out of the box to well so we need an OS/2 port installed. Both autoconfs > are named autoconf and use a similar setup so I have to juggle the %PATH% > depending on which version of autoconf I need. It gets quite complicated juggling > different %PATH%, LIBPATH, %C_INCLUDE_PATH% etc paths. > It is very complicated and I still have a few conflicts, notably to do with iconv. > The way I started was with a simple setup (the basic EMX setup) which has grown over > the years as I needed to add things. > Another consideration is that EMX and Innotek_libc are incompatible when it comes to > libraries and DLLs so need a couple of trees, then all GCC libs are incompatible to one > degree or another when dealing with C++. > Most of these problems also exist on Linux and even with proper distrubations there > are the same problems. On my Debian partition there are also a couple of autoconfs > and GCCs. Same thing, one project will only build with the newest GCC and another, eg > the Kernel needs an older GCC. The only advantages on Linux are better support for > symlinks and longer library (DLL) names. > Another problem I keep stumbling into on Linux is there seems to be a couple of sets of > the networking includes which cause conflict. > The wikki at http://www.edm2.com/index.php/Porting seems a good place to start and > I'm hoping to find time to add to the wikki and hopefully others will too and eventually it > will morph into a good set of instructions combining all our knowledge but it is still going > to take effort as we all have different ways of doing things around here. > Back to the car analogy, This is like the state cars were in 100 yrs ago, you couldn't > just hop in your car and drive to the store. You had to be a mechanic, an oil refinery, > and a road builder. > Dave, who is willing to give any help I can to help you setup a build enviroment, but is > always short on time **= Email 1 ==========================** Date: Tue, 28 Jun 2005 19:17:31 -0400 From: Lewis G Rosenthal Subject: Re: Warpstock 2005 On 06/27/2005 03:23 am, Steven Levine thus wrote : > In <20050626104116-52905-7 at 2rosenthals.com>, on 06/26/05 > at 10:41 AM, lgrosenthal at 2rosenthals.com said: > > >> I installed a White Box Enterprise Linux server from two CD's onto a >> spare Compaq Deskpro PIII/933 system, and racked it. I purchased a >> license from Sputnik, Inc (www.sputnik.com) for their captive portal >> software, and ran a Red Carpet install on that box, following simple >> directions (a dozen steps?). >> > > I expected you to say it was easy. These are folks selling commercial > software. I has to install relatively easily or all things being equal > they will be out of business sooner or later. > > Quite true. In fact, it's interesting to note how many adopters of the Sputnik software have little or no Unix/Linux experience whatsoever. Sputnik's scripting is quite elegant, and maintaining the system via Red Carpet is very simple and straightforward. I agree that for commercial apps, the packaging is an extremely important factor. >> This properly installed and configured >> Apache, Jabber, and Postgres, and automagically updated a few other >> things on the WBEL box. Total install time (after the OS) was >> approximately a half hour of my time, and an hour of machine time >> (downloads, etc.). >> > > You did well. > > Hey, I try...sometimes, you just live right, too!! >> Warpstock SF. I signed on as a beta tester, assuring me a steep discount >> on my first round of licenses and on my subsequent purchases (IOW, I made >> an investment with this company, because they were using tried and true, >> standard technologies, and I wanted something which would set up "out of >> the box" and NOT run on a Windows platform, as I wanted stability). >> > > Just wondering. Were they a venture funded outfit or just folks that > managed to go from garage shop to successful business? > > I think they had some venture capital behind them, though not a tremendous amount. They're looking to go public, but not much has been happening on that front in recent months. >> certificate issue), however, I erroneously left the temporary box up and >> running - and patched into the LAN with an identical IP address (ouch!!) >> - which caused the Cisco router in front of it to have a heck of a time >> directing traffic through the NAT to the correct box. Another case of a >> little bit of knowledge being a dangerous thing... ;-) >> > > I've heard of NIC vendors shipping out NICs with indentical MACs. Another > interesting failure mode. > > Yep. Been there; done that. It's especially nice when 3Com tells you that situations such as this are "impossible." >> same philosophy I see applied to what we're discussing: if there were a >> closer to out-of-box build environment, people with a modicum of skills >> could invest their time porting instead of setting up the build >> environment. >> > > That is another of those cases where I would rather be wrong that right, > but I just don't see thse kinds of build environments happening to the > level you would like to see in OS/2. That said, if one was willing to > invest 4 hours or so installing an gcc 2.8.x environment using John's > ux2bs, they would be able to build the older apps. > > Another half day or so following the cookbook at > > http://www.mozilla.org/ports/os2/gccsetup.html > > and they would have an almost current gcc build environment. > > Another hour or so installing Watcom and they would have that too. > > Another 30 minutes or so installing gcc 3.3.5 and they would have to too. > > By then they would be able to write several scripts to prepare an > evironment for each of these. > > With this, they would be ready to build some of currently interesting > apps. > > Until they ran across a dependency which was not yet installed, or worse yet, not yet built on OS/2. Then, one must drop back and punt, sidestepping to either hunt down a recent build of said dependency or build it oneself. That's not the fault of the OS/2 community, and it's not a shortcoming of any OS/2 environment (I run into it on Linux all the time). It's just d-mn frustrating, particularly for those of us who don't keep abreast of everything new coming out in this area. on Linux, I find myself googling all over the place, going to freshmeat, rpmfind, SuSE forums, etc. A "packaged" build system with the ability to auto-update with newer versions of various tools would make my life easier. And I know that merely stating this won't make it happen! You are absolutely right: if *I* feel the need for this, then *I* should put it together. Maybe in 2006. 2005 is getting rather crowded right now... ;-) >> Troubleshooting, without the basic knowledge of the underlying platform, >> is almost an exercise in futility, as it leads to stabbing in the dark to >> hit upon what "might" be the cause (and you have reminded me of that fact >> on more than one occasion, my friend!). >> > > One does not need to be a domain expert, but one does need to have a > certain level of common sense knowledge. Remind me the tell you about the > programmer with an EE degree that seems to be having problems converting > from an ISA serial card to a PCI serial card on a DOS-based control > system. > > Tell me that one at Warpstock. :-) >> (other things that would be nice are a native port of OpenOffice, less M$ >> OSes in my clients' offices, cooler weather in the summer, less snow in >> the winter - well, for those of us here in the northeast, at least! - and >> so on). >> > > We have snow here on the left coast. I just need to drive to where it > happens to be. It's not going to just come to me. ;-) > > Poignant, and well taken. >> Anyway, you haven't answered the underlying question of this thread, and >> that is, will you be presenting at Warpstock this year? Inquiring minds >> want to know!! :-) A trap troubleshooting session (as opposed to a "cr-p >> shooting session," that is)? >> > > I'm considering my options. > > Lunch or dinner? What can I do to sweeten the pot? >> Perhaps a build environment session? >> > > Probably not. > > :-( >> Apache? >> > > Contrary to what some might think, I don't know very much about Apache. > ;-) > > Now stop that!! Actually, you know quite a bit about the interaction of Apache and the operating system, which quite often, becomes the crux of its problems. And stop being so modest, anyway. ;-) >> Oh, and you conveniently side-stepped my last inquiry regarding that >> AirPrime driver. You have my curiousity piqued. ;-) >> > > I may have missed it. This weekend turned into a medical event here and > I've spent most of Saturday and Sunday caring for my better half in the > ECU and the ICU. Hopefully, she will be OK to come home sometime Monday. > She's a bit allergic to hospitals so she not all that happy about being > there. I'm sorry to hear that, though heartened to hear that she's coming home (or has, by this point). I hope she gets on her feet soon. > I'll try to track down the message. If I don't find it, I ask you > to repost. Like I mentioned, I just did the code. Mark did all the hard > work, which is why I recommended you ask him for the details. > > No problem. I can follow up with him. You've got more important things to attend. ATB -- Lewis ------------------------------------------------------------ Lewis G Rosenthal, CNA, CLE Rosenthal & Rosenthal, LLC Accountants / Network Consultants New York / Northern Virginia www.2rosenthals.com eComStation Consultants www.ecomstation.com Novell Users International www.novell.com/linux/truth Warpstock 2005 - Hershey, Pennsylvania, October 6-9, 2005 www.warpstock.org ------------------------------------------------------------ **= Email 2 ==========================** Date: Tue, 28 Jun 2005 19:41:41 -0800 From: "Dave Yeo" Subject: Re: The OS/2 and eCS Ecosystem On Tue, 28 Jun 2005 13:18:48 -0700, billn wrote: >Well, I'm going to give it a try with the new GCC 3.3.5b5. I've >downloaded it, but am short on time now. I'll let you know. I'd suggest going to www.mozilla.org/ports/os2/gccsetup.html for a starting list of utilities. But install in /usr rather then /moztools. Johns build system is another place to start Dave **= Email 3 ==========================** Date: Tue, 28 Jun 2005 19:23:07 -0400 From: Lewis G Rosenthal Subject: Re: Warpstock 2005 Brief reply...back OT, actually... On 06/27/2005 05:31 am, John Poltorak thus wrote : > On Mon, Jun 27, 2005 at 12:23:11AM -0700, Steven Levine wrote: > >> I'm considering my options. >> >>> Perhaps a build environment session? >>> >> Probably not. >> > > Maybe someone could show what UX2BS can do... I'm still quite please that > it can build something as complex as Perl so effortlessly, but it would be > nice to be able to do the same with every other Unix app too. > How about *you*, John? Could we entice you to come to Warpstock in Hershey this year?? I'd love to kick around that idea for an OS/2-based AP, too, despite my initial reluctance (let's just say you've had me thinking on this for a while). -- Lewis ------------------------------------------------------------ Lewis G Rosenthal, CNA, CLE Rosenthal & Rosenthal, LLC Accountants / Network Consultants New York / Northern Virginia www.2rosenthals.com eComStation Consultants www.ecomstation.com Novell Users International www.novell.com/linux/truth Warpstock 2005 - Hershey, Pennsylvania, October 6-9, 2005 www.warpstock.org ------------------------------------------------------------ **= Email 3 ==========================** Date: Wed, 29 Jun 2005 11:23:01 +0100 From: John Poltorak Subject: Re: Warpstock 2005 On Tue, Jun 28, 2005 at 07:23:07PM -0400, Lewis G Rosenthal wrote: > Brief reply...back OT, actually... > > On 06/27/2005 05:31 am, John Poltorak thus wrote : > > On Mon, Jun 27, 2005 at 12:23:11AM -0700, Steven Levine wrote: > > > > >> I'm considering my options. > >> > >>> Perhaps a build environment session? > >>> > >> Probably not. > >> > > > > Maybe someone could show what UX2BS can do... I'm still quite please that > > it can build something as complex as Perl so effortlessly, but it would be > > nice to be able to do the same with every other Unix app too. > > > How about *you*, John? Could we entice you to come to Warpstock in > Hershey this year?? Nope! > I'd love to kick around that idea for an OS/2-based > AP, too, despite my initial reluctance (let's just say you've had me > thinking on this for a while). I don't know if you have ever tried UX2BS, but the principle of it is really neat. Maybe you could demonstrate how a novice could build something quite complex like Perl without any effort at all and without reading hundreds of READMEs which explain how to set up the required environment... The basic problem with UX2BSis that it isn't yet robust to be able to parcel up and provide to other people as a build environment. It isn't far away though and could be made more useful with some further input from a few people. > > -- > Lewis > ------------------------------------------------------------ > Lewis G Rosenthal, CNA, CLE > Rosenthal & Rosenthal, LLC > Accountants / Network Consultants > New York / Northern Virginia www.2rosenthals.com > eComStation Consultants www.ecomstation.com > Novell Users International www.novell.com/linux/truth > > Warpstock 2005 - Hershey, > Pennsylvania, October 6-9, 2005 www.warpstock.org > ------------------------------------------------------------ -- John **= Email 4 ==========================** Date: Wed, 29 Jun 2005 12:36:35 +0100 From: John Poltorak Subject: Re: The OS/2 and eCS Ecosystem On Tue, Jun 28, 2005 at 07:41:41PM -0800, Dave Yeo wrote: > On Tue, 28 Jun 2005 13:18:48 -0700, billn wrote: > > >Well, I'm going to give it a try with the new GCC 3.3.5b5. I've > >downloaded it, but am short on time now. I'll let you know. > > I'd suggest going to www.mozilla.org/ports/os2/gccsetup.html for a starting list of utilities. But install in /usr rather then /moztools. > Johns build system is another place to start Actually, I'm in the process of trying to restructure UX2BS so that it looks a little more straightforward to use and update. It will consist of only two top level directories - one (lib) for the generic UX2BS build scripts and sundry lists, and the other (apps) will contain one subdirectory for every app supported so that all variables and exception handling for that app can be held together rather than being dispersed over five or six directories as at present. Of course some apps will be built without exception handling if they build straight out of the box without the need for any OS/2 fixes at all - it does sometimes happen... > Dave > -- John